写入请求必须削峰，因瞬时高并发会打满数据库连接池、引发waiting for connection排队及事务锁竞争，加机器无法缓解该IO瓶颈；需用ants协程池缓冲、Header降级与DB连接池配平协同控压。
直接用 go 启动协程处理写入请求，大概率在流量突增时崩掉——不是 Gin 不行，而是没做请求缓冲和并发节流。
为什么写入请求必须削峰，而不是靠加机器硬扛
大并发写入（比如临床 ePRO 系统凌晨 8 点万级患者集中提交）会瞬间打满数据库连接池、触发 MySQL 的 waiting for connection 排队，甚至让 HTTP 客户端卡在 net/http.(*persistConn).roundTrip。这时候加机器没用，因为瓶颈不在 CPU，而在连接等待和事务锁竞争。
- 不做削峰时，
sql.DB.SetMaxOpenConns和SetMaxIdleConns配置再合理也救不了瞬时毛刺 - Gin 的
gin.Context是复用的，但 handler 里直接go writeDB(req)会导致 goroutine 泛滥，OOM 风险极高 - 前端重试 + 后端无缓冲 = 请求雪崩，错误日志里全是
context deadline exceeded，但真实问题是连接耗尽
用 ants 协程池做写入任务缓冲
把写入逻辑从 handler 中剥离，扔进有容量限制的协程池，是目前最轻量、可落地的削峰方案。ants 框架默认 recover panic、支持超时、能优雅关闭，比手写 channel+WaitGroup 更稳。
- 初始化池子时设合理上限：比如
ants.NewPool(20)，对应 DB 的MaxOpenConns=20，避免池子比 DB 还“贪” - handler 里只做校验和入池：
_ = pool.Submit(func() { saveToDB(req) })，立刻返回 202 Accepted，不等 DB 结果 - 别用
pool.SubmitFunc带返回值——写入失败本就不该同步反馈给用户，异步落库 + 补偿任务更合适 - 务必调用
pool.Release()，否则进程退出时 worker goroutine 不释放，K8s liveness probe 会反复失败
结合 Gin Context 实现请求级降级与熔断
光缓冲不够，得让部分请求“知趣地退一步”。Header 静默降级在这里很实用：当后端写入压力高时，iOS 客户端可接受“已收到”而不强求落库成功，Web 管理后台则必须走主路径。
立即学习“go语言免费学习笔记（深入）”；
- 中间件提前读取
X-Client-Type和X-Defer-Level，塞进c.Request.Context()，别存在全局 map 里 - service 层判断：
if clientType == "ios" && deferLevel == "low" { return cacheOnlySave(req) } - 别在中间件里查 Redis 开关——goroutine 复用下阻塞操作会卡住整条请求链；开关状态应由独立 goroutine 定期拉取并缓存到内存
- 响应码仍用 200，body 里加
"degraded": true字段，前端按需提示“数据稍后同步”，不触发错误监控
数据库层必须配平连接池与事务粒度
削峰效果好不好，最终卡在 DB 层。Gin 只是入口，真正吞吐瓶颈在 sql.DB 怎么用。
-
SetMaxOpenConns不要设成 1000，建议先设为 50～100，再根据SHOW STATUS LIKE 'Threads_connected'观察实际占用 -
SetMaxIdleConns设为和MaxOpenConns相同值，避免频繁建连/断连开销 - 写入逻辑尽量拆小：单次提交不要超过 100 条记录，避免长事务锁表；用
INSERT ... ON DUPLICATE KEY UPDATE替代先查后插 - 所有 DB 调用必须带 context：用
db.ExecContext(c.Request.Context(), ...)，确保超时能中断，不拖垮整个池子
削峰不是把请求藏起来，而是让系统在过载时依然可控——协程池控并发数，Header 控降级策略，DB 连接池控资源水位。三者漏一，压测时都可能突然崩掉。
