GC扫描压力陡增主因是短期对象暴增致标记阶段对象图急剧膨胀，而非堆总量大；需控分配、压峰值、避毛刺，sync.Pool须重置状态，GOMEMLIMIT比GOGC更稳，验证看PauseQuantiles[6]及mark termination尖峰。
为什么 GC 扫描压力在高并发下会陡增
不是堆总量大，而是短期对象暴增导致标记阶段要扫描的对象图急剧膨胀。每次 HTTP handler 中 json.Unmarshal 到 map[string]interface{}、反复 make([]byte, n)、或结构体字段含 *sync.Mutex，都会让逃逸分析失败，把本该栈分配的对象钉死在堆上。这些对象虽存活时间短，但 GC 还没来得及清扫，下一波请求又塞进来——标记器被迫反复遍历大量“刚死未扫”的节点，gctrace=1 里 scanned 字节数逐轮上涨就是典型信号。
sync.Pool 复用时必须重置状态，否则等于喂垃圾给 GC
很多人以为 sync.Pool 拿到对象就直接能用，其实它完全不管理内容。比如从池中取 *bytes.Buffer，不调 b.Reset() 就写入，上次残留的字节还在底层数组里，GC 会认为这部分内存仍被引用，无法回收。
-
Get后必须手动清空所有可变字段：buf.Reset()、slice = slice[:0]、map = nil（再make） - 自定义结构体的
New函数必须返回全新实例，不能复用全局变量或带副作用（如打开文件） -
Put前确保对象已脱离所有 goroutine 作用域：没传进 channel、没被闭包捕获、没作为返回值传出 - 禁止在
defer里无条件Put——异步 callback 或 goroutine 启动后才 defer，极易use-after-free
预分配 + 栈逃逸控制比 Pool 更优先
复用是补救，不分配才是根本。Go 编译器靠逃逸分析决定分配位置，go build -gcflags="-m -l" 是必跑命令。高频路径里常见错误：
- 用
make([]byte, 1024)而非make([]byte, 0, 1024)：前者多初始化 1024 字节零值，全算活跃对象 - HTTP body 读取用
bytes.Buffer.String()再strings.Split()：额外生成字符串副本和子串头，两倍堆开销 - JSON 解析不用
json.RawMessage延迟解析，一上来就Unmarshal到泛型map，每个 key/value 都是新堆对象 - 闭包捕获大切片或 map：整个栈帧被拖上堆，比你想象中更容易发生
GOMEMLIMIT 比 GOGC 更可控，但设错反而放大毛刺
GOGC=100 是默认值，但它只响应“堆增长比例”，流量突增时容易堆积大量垃圾，单次 STW 被拉长。而 GOMEMLIMIT（Go 1.19+）直接锚定内存上限，更稳。
- 设为容器内存 limit 的 85%～90%，例如容器 4GB →
GOMEMLIMIT=3600000000 - 禁止运行中反复修改
GOGC：它只影响下一次触发阈值，频繁变更会导致 GC 周期紊乱 - 验证优化效果看
debug.ReadGCStats().PauseQuantiles[6]（P99 停顿），不是平均值 - 若
gctrace显示mark termination阶段出现尖峰，说明对象图太深，得回查结构体指针字段是否过多、是否用了context.Context作字段
真实压测中，最常被忽略的是：goroutine 泛滥本身就会推高扫描压力——每个卡在 select{} 或 http.Transport 等待中的 goroutine，都在堆上钉着 net/http.http2ClientConn、bytes.Buffer 等实例。别只盯着 GC 参数，先用 pprof /debug/pprof/goroutine?debug=2 看看有没有上万条 chan receive。
