压测崩溃主因是http.DefaultClient未配置Transport参数导致连接爆炸，须设MaxIdleConns、MaxConnsPerHost、IdleConnTimeout；高频读应改用sync.RWMutex；日志须用zerolog/zap并带trace_id；中间件需缓存、复用、优化顺序。
为什么 http.DefaultClient 在压测时突然崩掉
因为没设限的默认 transport 会让每个请求都新建 tcp 连接，连接数指数级上涨，dns 解析卡住，超时堆积——这不是代码写错了，是根本没配置。
必须替换掉全局 http.DefaultClient，至少设置三项：
-
MaxIdleConns = 100：限制整个 client 可保持的空闲连接总数 -
MaxConnsPerHost = 50：防止单个下游服务被打爆 -
IdleConnTimeout = 30 * time.Second：避免长连闲置耗尽 fd
所有 HTTP 调用必须带 context.Context，否则上游已超时返回，底层 goroutine 还在等响应，造成泄漏。别复用一个 client 对所有下游服务，按域名/用途分 client，各自配 timeout 和 retry。
sync.Mutex 为什么一上压测就变瓶颈
高频读场景（比如每请求查一次计数器、配置快照）用 sync.Mutex，等于把所有读请求串行化，QPS 直接腰斩。
读多写少，就该换 sync.RWMutex：读走 RUnlock/RLock，允许多 goroutine 并发读；写仍独占。
立即学习“go语言免费学习笔记（深入）”；
更进一步，频繁分配小对象（如 map[string]interface{}、HTTP header 缓冲区），直接上 sync.Pool 复用。别自己写“池管理器”，Go 原生 sync.Pool 已针对 P-local 缓存和逃逸分析做过深度优化。
切忌在 handler 里裸写 visits[r.RemoteAddr]++，哪怕加了锁，panic 也可能导致锁未释放——应封装成带 recover 的原子操作函数。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
日志打太多反而拖垮服务
每请求都调 log.Printf("req: %s, status: %d", r.URL.Path, statusCode)，字符串拼接 + 系统调用 + 磁盘 I/O，CPU 吃得比业务逻辑还凶，而且日志没法被 Loki 或 ELK 正确解析。
禁用标准 log 包，用 zerolog 或 zap；初始化时启用缓冲：zerolog.NewConsoleWriter(zerolog.ConsoleWriterConfig{Buffered: true})。
每请求注入唯一 trace_id，通过中间件写入 context，并在所有日志中自动携带：logger.With().Str("trace_id", getTraceID(r)).Str("path", r.URL.Path).Int("status", statusCode).Send()。
Gin 中间件性能掉 30% 的真实原因
不是框架慢，是中间件写法不对：token 解析、JSON 反序列化、map 初始化这些操作，在每个请求里重复做，GC 压力陡增。
鉴权中间件要缓存 token 解析结果，Redis 存有效期内 claims，解析耗时从 2ms 降到 0.3ms；用 sync.Pool 复用 JSON 解析器实例，避免每次 new struct。
路由匹配也影响性能：动态路径参数（如 /user/:id）在复杂路由树下正则匹配开销大。优先用 Gin 的 RouterGroupRadixMiddleware 启用 Radix 树优化，或拆分静态前缀分组预编译。
最易忽略的是中间件顺序：日志中间件放在最外层，但若它内部调用了未设超时的 http.Client，整个链路就不可控——所有下游调用必须自带 context 和超时。
