gRPC 命令行客户端 grpcurl

要解决的具体问题

gRPC 接口的调试经常比 REST 更麻烦：请求是 HTTP/2 上的 protobuf 帧，客户端通常要先按 proto 生成 stub，或者打开一个 GUI 才能发起调用。排查线上问题时，你往往只想要一条可复制、可进日志、能放进脚本的命令，而不是重新编译客户端。

核心能力与工作方式

• 按服务端反射或 proto 文件解析接口：没有现成 client 时，可以用 reflection 拿到 service/method，也可以加载本地 schema。
• 覆盖常见调用形态：支持 unary calls 和 streaming，能处理请求/响应是流式的场景。
• 处理真实部署约束：支持 TLS 与 metadata headers，适合对接启用加密或需要鉴权/追踪头的 gRPC 服务。
• 工作流很直接：指向目标 endpoint，先解析服务定义，再发起调用并观察返回或错误；输出便于在终端和 CI 日志里核对。

适用边界与注意点

• 服务端必须开启 reflection；没开的话需要准备正确的 proto 文件与导入路径，否则方法名和字段无法解析。
• Docker 只是运行载体之一，上游明确提醒存在使用坑，应按上游文档核对命令与镜像行为。
• 访问 TLS 服务时要处理证书校验、私有 CA 或代理场景；metadata headers 可能包含 token，注意不要写进公开日志。
• 它解决的是命令行可调用性，不替代正式 SDK、契约测试或端到端测试。