Go的写屏障用于GC并发标记阶段及时感知堆上对象指针字段的修改，避免漏标；它仅在_GCmark阶段生效，且只拦截堆对象的指针字段写入，通过缓冲区批处理将新指针加入标记队列。
Go 的写屏障不是用来“防止写入”的，而是让 GC 在对象被修改时能及时感知指针变化，避免漏标。它只在 GC 的并发标记阶段启用，且仅对堆上对象的指针字段写入生效。
写屏障触发的两个必要条件
写屏障不会对所有写操作生效，必须同时满足：
- 写入目标是
heap上分配的对象（栈上对象、全局变量、常量、uintptr类型等不触发） - 写入的是指针类型字段（例如
*T、map[K]V、slice、interface{}等含指针的结构体字段） - 当前 GC 处于
GCphase == _GCmark阶段（即并发标记中），否则写屏障函数直接 return
典型漏标场景：A → B，B 已被标记为存活，此时 A 被 GC 扫描过，但随后 A.field = C（新指针），若无写屏障，C 就永远不会被标记——这就是写屏障要拦截并重新标记 C 的原因。
gcWriteBarrier 实际干了什么
Go 运行时（runtime）在编译期对符合条件的指针写入插入调用，底层是汇编实现的 gcWriteBarrier 函数。它核心做两件事：
立即学习“go语言免费学习笔记（深入）”；
- 把被写入的新指针值（如
C）加入当前 P 的writeBarrierBuf缓冲区（大小固定，约 512 项） - 当缓冲区满或当前 M 即将调度时，触发
wbBufFlush，将这批指针批量插入到全局标记队列work.markrootNext或灰色对象队列中
注意：不是每写一次就发一次标记任务，而是批处理，降低原子操作和锁竞争开销。这也是为什么写屏障本身性能损耗可控（实测通常
为什么 unsafe.Pointer 和 uintptr 不触发写屏障
因为 Go 明确将它们视为“非类型化指针”，编译器无法静态判断其是否指向堆对象，也无法保证运行时语义安全。例如：
var p *int = new(int) var up unsafe.Pointer = unsafe.Pointer(p) *(*uintptr)(up) = uintptr(unsafe.Pointer(new(int))) // ❌ 不触发写屏障，且极可能造成漏标或 crash
这类操作绕过类型系统，GC 完全不可见。真实项目中若用 unsafe 手动管理对象生命周期，必须配合 runtime.KeepAlive 或手动调用 runtime.gcStart 前确保引用可达，否则极易触发静默内存错误。
开启写屏障后仍漏标的常见原因
写屏障只是并发标记的基础设施，不是银弹。以下情况仍会导致漏标：
- 写屏障未启用：GC 阶段不是
_GCmark（比如还在 sweep 阶段） - 写入源是栈对象：如
local := &obj; global.ptr = local，local 在栈上，写屏障不拦截，但该栈帧返回后global.ptr就悬空 - 编译器优化绕过：某些内联或 SSA 优化可能合并/省略写操作，导致屏障丢失（极少见，但 Go 1.20+ 对此做了更多校验）
- CGO 边界：Go 代码写入 C 内存块中的指针字段，C 侧修改不会触发 Go 写屏障
真正难调试的漏标问题，往往藏在栈逃逸分析边界、CGO 交互、或 unsafe 强转里——这时候得结合 GODEBUG=gctrace=1 和 runtime.ReadMemStats 观察标记进度与对象存活率，而不是只盯着写屏障开关。
