结论：高并发接口不是靠堆goroutine实现的，而是靠「控制并发量+避免阻塞+快速失败」三层设计；必须硬限制goroutine数量，用ants.pool或chan struct{}信号量（如sem := make(chan struct{}, 100)）卡死在cpu核心数×5～10范围内，所有下游调用须套context.withtimeout并defer cancel，共享状态优先用sync.map或原子操作，严防goroutine泄漏。
直接说结论：高并发接口不是靠堆 goroutine 实现的，而是靠「控制并发量 + 避免阻塞 + 快速失败」三层设计。盲目每请求起一个 go，不出三天就 OOM 或调度雪崩。
goroutine 数量必须硬限制，不能靠“轻量”放任自流
很多人误以为 goroutine 开销小就能无限创建，但实测中，单机每秒 5000 请求若全起 goroutine，调度器会卡住、GC 频繁、内存暴涨——尤其当业务逻辑含阻塞 IO 或未设超时。
- 用
ants.Pool或带缓冲 channel 做信号量（比如sem := make(chan struct{}, 100)），把并发数卡死在 CPU 核心数 × 5～10 范围内 - 别在 HTTP handler 里直接
go handle()，先过池子；池子初始化要早于服务启动，避免 runtime panic - 注意
ants.NewPool的第二个参数是ants.WithNonblocking(true)还是 false：true 会丢任务，false 会阻塞提交，选哪个取决于你的 SLA——支付类接口建议 false + 降级兜底，日志类建议 true
所有下游调用必须套 context.WithTimeout
没加 context 的数据库查询、HTTP 调用、RPC 请求，就是定时炸弹。一个慢查询拖住整个 goroutine，池子里的 worker 全被占满，新请求进来直接排队或失败。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个外部依赖调用前，必须从 request context 派生新 context：
ctx, cancel := context.WithTimeout(c.Request.Context(), 800*time.Millisecond) - cancel 一定要 defer 调用，否则泄漏；如果下游返回
context.DeadlineExceeded，立刻返回http.StatusGatewayTimeout，别重试 - gin 中不要用
c.Request.Context()直接传给 long-running goroutine，要用context.WithCancel派生并手动管理生命周期
共享状态优先用 sync.Map 或原子操作，别一上来就 sync.Mutex
高频读写场景下，sync.Mutex 锁整个结构体，会成为瓶颈。比如用户会话缓存、计数器、开关配置，读远多于写。
-
sync.Map适合 key 不固定、读多写少的缓存（如 token → user_id 映射），但注意它不支持遍历，也不保证迭代一致性 - 简单计数器用
atomic.Int64，比 mutex 快 3～5 倍；字符串拼接用strings.Builder，别用+ - 真要锁，粒度越小越好：只锁字段，不锁整个 struct；写完立刻 unlock，别包一大段逻辑
最容易被忽略的点是：goroutine 泄漏往往发生在 channel 关闭不及时、context 未监听 done、或 defer cancel 忘写。压测时看 pprof/goroutine，如果数量持续上涨，基本就是这三类问题之一。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
