响应速度上不去八成源于网络等待、内存抖动或goroutine调度卡点；需显式配置http客户端超时与连接池参数，禁用default client，避免标准json序列化，严防goroutine泄漏。
响应速度上不去，八成不是CPU瓶颈，而是网络等待、内存抖动或goroutine调度卡点——先别急着改算法，从这三处下手最见效。
HTTP客户端没设超时和连接池参数
默认http.DefaultClient在微服务调用中极易拖慢响应：DNS解析慢、TLS握手卡住、空闲连接不回收，都会让请求挂住几秒。现象是P95延迟毛刺明显，日志却无报错。
-
Timeout必须显式设值（如3 * time.Second），否则依赖系统默认（可能30秒） -
MaxIdleConns和MaxIdleConnsPerHost要限制（如都设为100），不然连接池无限膨胀，内存涨+调度开销大 - 复用
http.Client实例，禁止每次请求都&http.Client{}新建 -
IdleConnTimeout建议设为30–90秒，太短频繁重连，太长积压无效连接
JSON序列化还在用标准库encoding/json
标准库encoding/json在struct字段多、嵌套深时反射开销大，高频小payload场景下，序列化/反序列化能占单次调用耗时15%–40%。
- 换
json-iterator/go或goccy/go-json，性能通常是标准库的3～5倍 - 避免
map[string]interface{}，它强制反射且无法静态编译优化 - 对简单结构体，手写
MarshalJSON方法并复用bytes.Buffer，能减少30%+分配次数 - 若用gRPC，直接切到
Protocol Buffers，序列化体积小、解析快、有强schema约束
goroutine泄漏或无节制创建
goroutine泄漏不会立刻打满CPU，但会缓慢推高内存、拖慢调度器——表现为goroutine数持续上涨、GC pause变长、响应毛刺增多。
- 所有
go func() { ... }()必须配对defer wg.Done()，尤其注意error early return路径里是否遗漏 - HTTP handler里启动的goroutine，必须监听
req.Context().Done()，否则请求取消后协程还在跑 - 带缓冲channel的
for range接收容易卡死，改用select+default或显式退出条件 - 用
/debug/pprof/goroutine?debug=2看调用栈，重点排查状态为chan receive或select的长期阻塞协程
真正卡住响应的，往往不是某一行代码慢，而是几十毫秒的连接等待、几百次的小对象分配、或者几百个“活着但啥也不干”的goroutine在后台排队——这些点不盯紧，加再多CPU也白搭。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
