默认HTTP Server高并发卡顿主因是未配置ReadTimeout/WriteTimeout致goroutine堆积、DefaultTransport连接池过小（MaxIdleConnsPerHost=2）、高频堆分配触发GC压力；应使用golang.org/x/sync/semaphore精确控并发，sync.Pool复用固定尺寸byte切片，并绕过框架中间件实现流式AES-GCM加密。
为什么默认 HTTP Server 在高并发下会卡住
不是 Goroutine 不够快，而是默认配置没扛住连接和内存压力。典型现象是 P95 延迟突然跳升、runtime.mallocgc 占 CPU 热点超 30%、too many open files 报错频发。根本原因有三个：http.Server 没设 ReadTimeout/WriteTimeout，导致慢连接长期占着 goroutine；http.DefaultTransport 的 MaxIdleConnsPerHost 默认为 2，10 个并发请求就排队等复用连接；每次 handler 里 json.Unmarshal 或 make([]byte, 4096) 都逃逸到堆，触发锁竞争型分配。
怎么用 semaphore 精确控制业务并发数
别在 for 循环外放 sem.Acquire，也别用 chan struct{} 手写信号量——它不支持上下文取消，超时后许可永远不释放。直接用 golang.org/x/sync/semaphore：
-
sem := semaphore.NewWeighted(100)初始化，数值不是拍脑袋定的，得压测：看 P95 延迟拐点 + GC pause 稳定区间 - 必须在
client.Do()或 DB 查询前调sem.Acquire(ctx, 1)，且ctx要带超时，否则 Acquire 阻塞会导致整个信号量池死锁 -
defer sem.Release(1)放在函数最开头，确保 panic、error return、正常结束都释放 - 别把
Acquire放在解析大 body 之后——恶意请求先耗光 buffer 再卡住信号量，限流就失效了
sync.Pool 复用 byte 切片的三个铁律
sync.Pool 不是缓存，是“复用+延迟释放”，乱用反而加重 GC。满足以下三点才能安全复用：
- 尺寸必须固定：
make([]byte, 8192)可以，make([]byte, rand.Intn(1024))不行——尺寸混乱会让 mcache 跨 span class，命中率暴跌 - 归还前必须清空：
buf = buf[:0]，否则下次Get()拿到的是上个请求残留的 token 或用户 ID - 必须全局单例：日志 buffer（4KB）和 JSON buffer（32KB）不能混用同一池，否则污染缓存局部性
验证是否逃逸：用 go build -gcflags="-m -l" 编译，看到 escapes to heap 就得重构。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
加密响应为什么不能走框架中间件
Gin/Echo/Fiber 的中间件默认把整个响应体塞进内存再 write，而 AES-GCM 加密要求 nonce 唯一、认证标签（16 字节）必须最后追加——你没法边读原始数据边加密边发包。强行在 handler 里 gcm.Seal 整体加密，会 OOM。
- 必须绕过框架封装，自定义
ResponseWriter：第一次Write时写 header + nonce，后续所有Write转发给aesgcm.EncryptWriter -
Gin用c.Writer类型断言替换；Echo用c.Response().Writer；Fiber直接操作c.Context.Response().BodyWriter() - 务必禁用
gzip.Middleware——先压缩再加密可接受，反过来会破坏 GCM 认证 -
Content-Length要手动 +16，GCM 输出比原文长 16 字节
nonce 生成别用 rand.Reader，高并发下太慢；改用 counter 模式 + atomic.AddUint64，快 10 倍以上。
