HTTP RESTful适合对外暴露API、需浏览器/移动端/第三方调用、强调可读性与调试便利的场景；gRPC更适合内部微服务间高性能、强类型、多语言通信。
HTTP RESTful 适合什么场景
当你的服务需要被浏览器、移动端、第三方系统广泛调用，或要求可读性高、调试方便、能直接用 curl 或 Postman 测试时，HTTP RESTful 是更自然的选择。它天然兼容防火墙、CDN、反向代理（如 Nginx），且状态码、Header、JSON 格式都是开发者共识。
常见踩坑点：Content-Type 忘设为 application/json 导致前端收不到数据；未处理 OPTIONS 预检请求导致跨域失败；用 http.Error 返回非标准错误体，让客户端难以解析。
- Go 标准库
net/http足够轻量，无需额外框架也能快速搭出可用接口 - 路径设计建议遵循 REST 约定：资源用复数名词（
/users），操作用 HTTP 方法（GET /users/123获取，PUT /users/123更新） - 若需 OpenAPI 文档，推荐搭配
swag工具自动生成，避免手写 YAML 同步不一致
gRPC 更适合哪些情况
当你在内部微服务之间通信，追求高性能、强类型、多语言互通，且能接受二进制协议和额外工具链时，gRPC 是更优解。它基于 HTTP/2，支持流式传输（server-streaming、client-streaming、bidi-streaming），序列化用 Protocol Buffers，天生防字段错位。
典型问题：grpc-go 默认不启用 TLS，明文传输内网虽常见但有风险；客户端未设置超时（context.WithTimeout），导致请求卡死；Proto 文件中字段未加 json_name 注解，导致 JSON 映射不匹配（如 user_id → userId）。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
protoc+protoc-gen-go生成 Go 代码，版本要与google.golang.org/grpc兼容（例如 v1.60+ 对应 protoc-gen-go v1.32+） - HTTP/2 的连接复用特性意味着单个
*grpc.ClientConn应复用，而非每次请求新建 - 若需对外暴露 gRPC 接口，得配
grpc-gateway做 HTTP/JSON 转发，否则浏览器无法直连
性能与开发体验的实际差距
纯吞吐量上，gRPC 在千级 QPS 以上通常比 JSON over HTTP 快 2–5 倍，主要来自 Protocol Buffers 序列化开销低、HTTP/2 头部压缩、连接复用。但这个差距在多数业务系统里并不构成瓶颈——数据库 IO、缓存延迟、业务逻辑复杂度才是真正的瓶颈点。
真正影响落地的是开发与协作成本：curl http://localhost:8080/api/v1/users 和 grpcurl -plaintext localhost:9090 list 的调试门槛完全不同；前端团队几乎无法直接消费 gRPC，而 REST 可以零成本对接；CI/CD 中 Proto 文件变更需同步生成、校验、升级，比改一个 JSON Schema 重得多。
- 压测时注意：gRPC 的
Unary模式接近 REST 性能，但流式模式在长连接场景下优势明显（如实时日志推送） - Go 中
http.Server默认无连接池，而grpc.ClientConn内置连接管理，误用http.Client不设Transport.MaxIdleConns反而可能拖慢 REST - 如果团队已有成熟 REST 监控体系（如 Prometheus + Gin middleware），迁移到 gRPC 需重写指标采集逻辑
混合使用是常见且合理的方案
很多生产系统采用「对外 REST，对内 gRPC」的分层设计：外部 API 网关统一接收 HTTP 请求，做鉴权、限流、日志后，转成 gRPC 调用下游服务。这种架构既保留开放性，又享受内部通信效率。
关键细节：grpc-gateway 默认将 gRPC 错误码映射为 HTTP 状态码（如 codes.NotFound → 404），但自定义错误需实现 status.FromError 解析；若用 echo 或 gin 做网关，需手动透传 gRPC 元数据（如 authorization Header 到 metadata.MD）。
- 不要为了“技术先进”强行全量切 gRPC，尤其当 80% 接口是 CRUD 且调用方多样时
- Proto 定义要早于代码编写，字段命名用小写下划线（
created_at），并加json_name保证兼容性 - Go 中同时启动 HTTP 和 gRPC 服务时，注意端口冲突和健康检查路径区分（如
/healthzvs/health）
协议选型不是非此即彼的决定，而是看清楚谁在调用、怎么调试、出问题时谁能快速定位——这些往往比理论吞吐量更重要。
