优先用gRPC而非HTTP：内网高并发低延迟场景下，gRPC基于HTTP/2多路复用和Protobuf序列化，QPS提升3–5倍、延迟降40%~60%；但需注意TLS、超时、Proto注解、连接复用、keepalive配置及HTTP/gRPC端口混用陷阱。
内部微服务通信，优先用 gRPC 而不是 HTTP
Go 微服务部署在内网、高并发、低延迟敏感时，gRPC 是更自然的选择。它基于 HTTP/2 多路复用，100 个并发请求不会新建 100 个 TCP 连接，也不会因某次慢响应阻塞后续调用（无队头阻塞）；Protobuf 序列化后体积约是 JSON 的 35%，反序列化耗时约 30%。实测 QPS 提升 3–5 倍，平均延迟下降 40%~60%。
但要注意：grpc-go 默认不启用 TLS，明文传输有风险；客户端必须用 context.WithTimeout 设置超时，否则请求可能永久卡住；Proto 字段没加 json_name 注解（如 user_id → userId），会导致 JSON 映射失败。
- 单个
*grpc.ClientConn必须复用，不要每次请求都grpc.Dial - 务必显式配置
keepalive.EnforcementPolicy，避免空闲 2 小时后连接突然断开报transport is closing - 若混用
http.ServeMux和grpc.Server在同一端口，别用http.Handle("/", ...)拦截所有路径，否则会吞掉/helloworld.Greeter/SayHello这类 gRPC 流量
对外暴露 API，必须用 HTTP RESTful
浏览器、iOS/Android App、第三方系统要直接调用你的服务？net/http + RESTful 是唯一现实选项。前端不可能写 gRPC stub、处理双向 TLS、解析二进制流；API 网关（Kong、AWS API Gateway）、Nginx、CDN 也只认 Authorization、Cache-Control 等标准 HTTP 头，不识别 gRPC 的 metadata。
Go 标准库 net/http 足够轻量，不用框架也能快速搭出可用接口。路径设计建议遵循 REST 约定：/users（复数名词）、GET /users/123（获取）、PUT /users/123（更新）。
立即学习“go语言免费学习笔记（深入）”；
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
- 忘设
Content-Type: application/json→ 前端收不到数据 - 没处理
OPTIONS预检请求 → 跨域失败 - 用
http.Error返回非标准错误体 → 客户端难解析（推荐统一返回{ "code": 400, "message": "xxx" }） - 需 OpenAPI 文档？用
swag init自动生成，别手写 YAML 同步不一致
别把 net/rpc 当 gRPC 用
net/rpc 是 Go 原生包，基于 gob 编码，仅限 Go 语言，不支持流、超时传播、拦截器，多年无重大更新。它适合单机多进程小工具通信，不是微服务级 RPC。
常见错误：用 rpc.DialHTTP 连自定义服务器却报 404 Not Found，本质是服务端没把 RPC handler 正确挂到 HTTP 路径上——rpc.Register 后必须显式调用 http.Handle("/rpc", http.DefaultServeMux) 或类似逻辑，否则 http.Serve 不知道该把请求交给谁。
-
net/rpc和gRPC完全无关，不能互相替代 - 若项目已用
net/rpc且只是内部简单调用，可继续用；但新微服务架构请直接上gRPC - 想调试方便又想要 RPC 效率？考虑
Twirp：用 Protobuf 定义，但走 HTTP/1.1，curl直连、Nginx 可代理，适合纯 Go 项目中的轻量通信
性能差距真没你想的那么关键
gRPC 比 JSON over HTTP 快 2–5 倍，但这只是纯网络和序列化层的数字。真实业务中，数据库 IO、缓存延迟、复杂业务逻辑才是瓶颈点。真正影响落地的是开发与协作成本：
-
curl http://localhost:8080/api/v1/usersvsgrpcurl -plaintext localhost:9090 list—— 调试门槛完全不同 - 前端团队几乎无法直接消费 gRPC，而 REST 可以零成本对接
- Proto 文件变更需同步生成、校验、升级，比改一个 JSON Schema 重得多
- CI/CD 中若没做 Proto 兼容性检查（如
buf check breaking），一次字段重命名就能让下游服务 panic
选型不是比参数，而是看谁扛得住上线后第一周的联调、灰度和紧急 hotfix —— 那时候没人关心 RT 降了 50ms，只关心能不能用一行 curl 快速验证问题是不是出在你这。
