gRPC 更合适因内网高并发低延迟场景下，其 HTTP/ 2 多路复用避免队头阻塞，Protobuf 序列化体积小、解析快，QPS 提升 3–5 倍、延迟降 40%~60%，Go 生态支持完善；HTTP 不可替代因需兼容浏览器 / 第三方调用、中间件集成及调试便利。
内部服务间通信，优先选 gRPC（RPC）；对外暴露 API 或需 浏览器/ 第三方直接调用时，必须用 HTTP。
为什么 gRPC 在 Go 微服务内部通信中更合适
Go 的微服务通常部署在内网、高并发、低延迟敏感的场景下。gRPC 基于 HTTP/2 + Protobuf，天然适配这些需求：
-
net/http默认走 HTTP/1.1，每个请求需排队或依赖连接池，http.Client的Transport.MaxIdleConnsPerHost稍不注意就成瓶颈 -
gRPC复用单个 TCP 连接，支持多路复用——100 个并发调用不会新建 100 个 TCP 连接，也不会因某次慢响应阻塞后续请求（无队头阻塞） -
Protobuf序列化后体积只有 JSON 的约 35%，反序列化耗时约 30%；实测 QPS 提升 3–5 倍，平均延迟下降 40%~60% - Go 生态对 gRPC 支持极好：
google.golang.org/grpc是官方维护，protoc-gen-go自动生成强类型 client/server，编译期就能捕获字段名错误
HTTP 什么时候不可替代
不是“HTTP 不好”，而是它解决的问题不同：
- 前端 页面、移动端 App、第三方系统要直接调用你的服务？必须用
http.ServeMux+ RESTful 接口，否则对方得写 gRPC stub、处理 TLS 双向认证、解析二进制流——没人愿意 - 需要被 Nginx、CDN、API 网关（如 Kong、AWS API Gateway）统一鉴权、限流、缓存？HTTP 的
Authorization、Cache-Control、ETag等头部是标准契约，gRPC 的metadata不被这些中间件原生识别 - 调试和灰度验证：你不会想用
grpcurl给产品同学演示接口，而curl -X POST http://localhost:8080/api/user一行命令就能跑通
别踩这些 Go 实操坑
选型之后，落地才是关键。很多团队翻车不在协议本身，而在细节配置：
立即学习“go 语言免费学习笔记（深入）”；
- 用
gRPC却没启用KeepAlive：默认空闲 2 小时才断连，内网长连接突然中断导致rpc error: code = Unavailable desc = transport is closing—— 必须显式配置keepalive.EnforcementPolicy和keepalive.ServerParameters - 混用
http.Handler和grpc.Server共享 端口 却不区分路径：gRPC 走/helloworld.Greeter/SayHello这种路径，若用http.Handle("/", ……)拦截所有请求，会把 gRPC 流量吞掉，返回404或乱码 - 误以为
net/rpc是 gRPC 替代品：Go 原生net/rpc基于gob编码 ，仅限 Go 语言，不支持流、超时传播、拦截器，且已多年无重大更新；它不是微服务级 RPC，只适合单机多进程小 工具 通信 - HTTP 服务盲目加
gzip：JSON 小包压缩收益低，反而增加 CPU 开销；gRPC 内置 HPACK 头部压缩，无需额外处理
真正难的不是选 HTTP 还是 gRPC，而是同一套微服务里如何让两者共存：比如用 gRPC 做服务间调用，再用 grpc-gateway 自动生成反向代理，把 gRPC 接口自动映射成 RESTful HTTP 接口——这样既保性能，又不失开放性。这个边界一旦模糊，调试成本和部署复杂度就会指数上升。
