Go GC 的 STW 仅发生在标记开始前和标记终止后两个极短节点，自1.8起栈扫描已并发化，实测总时长通常为100–300μs；写屏障按堆/栈位置分场景启用，辅助GC会隐式拖慢分配延迟。
Go GC 的 STW 阶段到底停在哪几个点
Go 的 STW 并非全程卡死，只在两个极短的关键节点发生：标记开始前（mark termination）和标记终止后（mark termination）。从 Go 1.8 起，栈扫描已移入并发阶段，不再需要 STW 扫描；而写屏障启用后，堆上对象的引用变更能被实时捕获，进一步压缩 STW 时间。实测中，一次典型 GC 的 STW 总时长通常压在 100–300μs 区间，远低于早期版本的毫秒级停顿。
常见误判是把“标记阶段耗时”当成 STW——其实那段时间 goroutine 照常跑。真正要盯的是 pprof 中 runtime.gcMarkTermination 的执行时间，它才是影响响应延迟的硬指标。
写屏障不是开关，而是分场景启用的机制
写屏障（write barrier）在 Go 里不是全局 on/off 的功能，它的启用策略依赖于当前 GC 阶段和对象位置：
- 堆上指针写操作：始终触发写屏障（Go 1.8+ 混合写屏障）
- 栈上变量赋值：不触发写屏障，但会在标记终止阶段做一次快速栈重扫描（
scanstack） - 逃逸到堆的局部变量：其指针写仍走堆路径，受屏障保护
这意味着：如果你看到 GC 标记漏对象，大概率不是写屏障失效，而是栈未及时重扫（比如 goroutine 长时间阻塞在系统调用中，错过扫描时机），此时需检查是否触发了 forcegc 或存在长时间运行的 Cgo 调用。
立即学习“go语言免费学习笔记（深入）”；
辅助 GC（mutator assist）怎么悄悄拖慢你的代码
当分配速率远超 GC 处理能力时，Go 运行时会启动辅助 GC：让正在分配内存的 goroutine 主动帮 GC 做一部分标记工作。这本身不增加 STW，但会显著拉高单次分配的延迟——尤其是 make([]byte, N) 这类大 slice 分配，可能突然卡住几微秒到几十微秒。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
判断是否触发辅助 GC 的信号包括：
-
GODEBUG=gctrace=1输出中出现assist:字样 -
runtime.ReadMemStats中NextGC与HeapAlloc差值持续缩小（HeapAlloc > NextGC * 0.9是高危信号） - pprof CPU profile 里
runtime.gcAssistAlloc占比异常升高
辅助 GC 不是你能关掉的功能，但可以通过降低分配压力来规避：比如复用 sync.Pool 中的 buffer，或把高频小对象合并为结构体字段而非独立分配。
并发标记线程数不是越多越好
Go 默认根据 P 的数量（即 GOMAXPROCS）动态调整并发标记 worker 数，上限为 runtime.GOMAXPROCS(0)。手动设高并不总有益：
- 在低核设备（如 2–4 核嵌入式板）上，开 4 个标记 worker 可能导致 CPU 抢占加剧，反而拖慢用户 goroutine
- 标记 worker 本身要消耗栈和调度开销，worker 数 > 8 后收益急剧下降
- 若程序大量使用
unsafe.Pointer或绕过类型系统的操作，过多并发标记线程可能放大写屏障竞争，引发 false sharing
真实优化建议是：先用 go tool trace 观察 GC/Mark/Worker 的活跃分布，再结合 GOGC 调整节奏，而不是盲目加 worker 数。很多线上服务在 GOMAXPROCS=4 下把 GOGC=50 配合 sync.Pool，比默认配置更稳。
真正难控的从来不是 GC 停顿本身，而是辅助 GC 引发的分配抖动、写屏障对缓存行的干扰、以及混合写屏障下栈重扫的时机不确定性——这些细节在压测中才暴露，日常日志根本看不出。
