跑了个 Benchmark：聊聊 Go 微服务通信选 REST、gRPC 还是 Connect-RPC

最近给组里重构内网 RPC 做选型，顺便用 ghz 和 k6 压了一轮（8C 16G 机器，并发 500，简单的 UserInfo 查询，payload 约 500B）：

• 原生 gRPC (HTTP/2 + Proto): ~8.2w QPS, p99 5.4ms, 内存占用极稳
• Connect-RPC (H2 + Proto): ~7.9w QPS, p99 5.8ms
• Connect-RPC (H1.1 + JSON): ~4.1w QPS, p99 11.8ms
• REST (Gin + Sonic JSON): ~4.3w QPS, p99 11.2ms

观点很直给：

1. 性能上，Connect 跑 H2 + Proto 几乎贴着原生 gRPC 跑，损耗完全在可接受范围内。
2. 开发体验上，原生 gRPC 的 Go 代码生成工具链有多反人类大家心里有数；而 connect-go 生成的代码清爽太多，底层直接兼容标准库 net/http，写 middleware 极其顺手，开发环境还能直接用 curl 调 JSON 协议 debug。

现在内网核心链路我们还是留了原生 gRPC，但给前端和边缘服务的接口我极想推 Connect-RPC。

想问下大家，有团队已经在生产大面积落地 Connect-RPC 了吗？在配合 Envoy 网关或者 OpenTelemetry 链路追踪的时候，有没有踩过什么恶心的暗坑？