goroutine泄漏比创建慢更致命，因未回收的协程持续占用栈内存并阻塞调度器，表现为pprof中goroutine数持续上涨、状态多为select或IO wait；必须绑定context.Context并在select中监听ctx.Done()，上线前用go tool trace验证生命周期收敛。
goroutine泄漏比创建慢更致命
很多人盯着“怎么开更多goroutine”，却忽略了一个更隐蔽的问题：goroutine没被回收。一旦协程里有阻塞操作（比如未设超时的http.Client.Do、死循环里没检查ctx.Done()），它就会一直挂在那里，不释放栈内存、不退出调度队列。
- 现象：pprof 的
/debug/pprof/goroutine?debug=2显示数量持续上涨，且多数状态为select或IO wait - 典型错误写法：
go func() { time.Sleep(10 * time.Second) }()—— 没上下文、没退出机制、没日志追踪 - 正确做法：所有长期运行的 goroutine 必须绑定
context.Context，并在select中监听ctx.Done() - 上线前必做：用
go tool trace抓 30 秒运行轨迹，观察 goroutine 生命周期是否收敛
sync.Pool不是万能缓存，只适合短生命周期对象
sync.Pool 的设计目标很明确：复用“每次请求新建、用完即弃”的临时对象，比如 bytes.Buffer、json.Decoder、自定义结构体指针。它不适用于跨请求持久化、带状态或需强一致性的对象。
- 误用场景：把数据库连接、HTTP client、带锁的结构体放进 Pool —— 可能导致连接复用错乱、TLS session 复用失败、竞态访问
- 有效指标：GC 周期中堆分配次数（
gc/allocs）下降 30%+，且 pprof 的heap_inuse曲线更平滑 - 初始化建议：在
init()或服务启动时预热 Pool，例如bufPool.Put(&bytes.Buffer{})放一个实例，避免首次请求冷启动抖动 - 注意逃逸：如果 Pool 里对象本身会逃逸（比如返回了内部字段指针），那复用反而加重 GC 压力
HTTP handler里别直接调json.Marshal
标准库 json.Marshal 默认会做反射 + 动态类型判断，对高频小结构体（如 {ID int, Name string}）开销明显。尤其在 P99 延迟敏感路径上，它可能吃掉 10–20μs —— 这在微秒级优化阶段不能忽略。
- 替代方案优先级：手动拼接（仅限极简固定结构）→
encoding/json预生成MarshalJSON方法 → 第三方库如easyjson或ffjson（已过时）→go-json（零反射，支持泛型） - 验证方式：用
benchstat对比json.Marshal和go-json在相同 payload 下的B/op和ns/op - 坑点：
go-json不兼容某些嵌套 interface{} 场景，若业务大量依赖动态 JSON 构建，强行替换反而引入 panic 风险
ETag不是可选功能，是轮询类接口的底线
对每 30 秒轮询一次的 API（如设备状态、订单进度），不加 ETag 就等于默认放弃 90%+ 的带宽和服务器 CPU。客户端已有数据，你却仍查 DB、序列化、压缩、发响应体 —— 整条链路都在空转。
- 生成策略要稳定：别用
time.Now().UnixNano()，用数据本身的变更标识，比如UpdatedAt.Unix()+ID拼接后哈希 - 务必校验
If-None-Match：Gin/echo 等框架不会自动处理，得自己读 header、比对、调c.Status(304) - 注意中间件干扰：某些日志中间件或 CORS 中间件可能篡改 response header，导致 ETag 被覆盖或丢失
- 实测收益：某库存查询接口开启 ETag 后，P99 延迟从 86ms 降至 12ms，出口流量下降 92%
真正卡住 Go 微服务性能的，往往不是“怎么更快”，而是“怎么不白干”——重复查库、重复序列化、重复启协程、重复分配内存。这些动作在单次请求里微不足道，但在 QPS 过万时，就是压垮 CPU 和 GC 的最后一根稻草。
