Go 1.22 服务 GC assist 恶化、P99 毛刺频率加速：GOGC 与 GOMEMLIMIT 联动调整时，谁影响 STW、谁影响 assist，线上怎么定「最优组合」？

背景

Go 1.22.7 无状态订单查询 API，K8s 部署（K8s 1.28.9 / containerd 1.7.13 / cgroup v2 / 内核 5.15.0-91），Pod spec memory.request=4Gi / memory.limit=4Gi（request=limit 避免 QoS 降级），节点 16C64G。单实例 goroutine 稳在 1500~2000，QPS 约 6000，主要开销在 JSON 编解码 + MySQL 查询（database/sql + go-sql-driver/mysql，MaxOpenConns=200）。

目前 GOGC 用默认 100，没设 GOMEMLIMIT。

现象

• P50 稳定在 23ms，但 P99 间歇性飙到 150~400ms，且频率在恶化：上周平均 5 分钟一次，这周变成 1~2 分钟一次；
• GODEBUG=gctrace=1 日志里能看到 assist 时间从 2ms 涨到 30~80ms，t=xxx s gc N @X.XXMB X% Xms Y% 中 X%（GC 占比）从 5%~8% 爬到 12%~15%；
• 毛刺出现时 HeapAlloc 峰值在 1.8~2.2Gi，而稳态 HeapAlloc 约 900Mi；
• 怀疑是分配速率过高导致 GC 跟不上（assist 恶化 → 业务 goroutine 被迫帮 GC → P99 毛刺），但还没验证。

已尝试的排查

1. go tool pprof http://localhost:6060/debug/pprof/profile?seconds=60：CPU profile 里 GC assist 占比约 15%~22%，top 分配热点是 JSON 编解码（encoding/json Marshal/Unmarshal）和 map 扩容；
2. GODEBUG=gctrace=1：确认 assist 在恶化（如上），不是 STW 本身变长（STW 基本稳定在 0.3~1.2ms）；
3. 试过 GOGC=200：P99 毛刺频率降了一半（约 3~4 分钟一次），但 HeapAlloc 峰值涨到 3.2Gi，离 limit 只剩 800Mi，不敢再调大；
4. 试过 GOMEMLIMIT=3500Mi（GOGC 保持 100）：效果不明显，assist 还是 20~60ms，不确定 GOMEMLIMIT 到底有没有生效。

期望得到的答案形态

1. 机制层面：GOGC 和 GOMEMLIMIT 各自影响 GC 的哪个阶段？GOGC 影响的是 GC 频率（trigger = heap × (1+GOGC/100)），GOMEMLIMIT 影响的是 GC 紧急程度（接近 limit 时 GC 更激进）——但两者叠加时，assist 和 STW 分别受谁主导？有没有人用数据验证过这个理解？
2. 调参策略：在「HeapAlloc 峰值已经 2.2Gi、limit 只有 4Gi」的约束下，GOGC 和 GOMEMLIMIT 的联动组合怎么定？是先调 GOMEMLIMIT 留 headroom 再降 GOGC？还是反过来？有没有人踩过「两个参数同时调、效果互相抵消」的坑？
3. 验证方法：怎么量化「assist 恶化」和「STW 变长」对 P99 的各自贡献？有没有可复现的压测方法（比如用 testing.B + benchstat 或自写压测脚本）能把 GC 调参的效果隔离出来？
4. 代码侧：除了 GOGC/GOMEMLIMIT，JSON 编解码的分配热点有没有低成本的优化方案（jsoniter / encoding/v2 / 预分配 buffer）？社区里有没有人实测过替换 encoding/json 后 GC assist 的改善幅度？

社区里已有《Go 服务 p99 间歇性 GC 毛刺：GOGC 调大 vs heap ballast vs 代码侧少分配，线上到底怎么选？》(id=683) 讨论过 GOGC vs ballast vs 少分配的选择，以及《Go 服务 limit=4Gi 却 OOMKilled：GOMEMLIMIT 是软提示》(id=2250) 讲过 GOMEMLIMIT 的内存预算。我的场景更具体：assist 在恶化、毛刺频率在加速，这暗示分配速率可能超过了 GC 的吞吐能力，单纯调大 GOGC 可能只是把堆撑大而不是解决根因。想看看大家有没有针对「assist 恶化 + 毛刺加速」这个组合的实战经验。