三色标记并非直接为对象赋颜色字段，而是通过mbitmap位图与gcWork队列协同维护逻辑状态：白色表示尚未确认可达，灰色表示已入队但子引用未扫完，黑色表示其闭包在本轮GC中已完全覆盖。
三色标记不是给对象“染色”，状态由位图和队列协同推演
你不会在 Go 源码里找到 obj.color 字段，也不会调用 markWhite() 这类函数。所谓“三色”，是运行时通过 mbitmap（堆位图）和 gcWork 队列共同维护的一种逻辑视图：白色 = 尚未确认可达；灰色 = 已入队、子引用未扫完；黑色 = 本轮 GC 中其闭包已完全覆盖。
常见误解是认为新分配的 &struct{} 会被立刻标灰——实际它仍是白色，哪怕刚被栈变量引用。只有根对象（goroutine 栈帧、全局变量、寄存器）在 STW 的 root marking 阶段被强制标灰并入队。中间大量对象根本不会被访问到，只要没被根路径连上，它始终白着，直到被回收。
关键点在于：黑色对象的字段指针在本轮 GC 中**不再被重新扫描**。所以一旦出现 A.field = &B（A 已黑，B 是新白对象），就必须靠写屏障拦截并标灰 B，否则 B 永远漏标。
混合写屏障只对堆上指针写入生效，且不可禁用
writebarrierptr 是编译器自动插入的汇编桩，不是你能调用的函数。它只在以下场景触发：
立即学习“go语言免费学习笔记（深入）”；
- 结构体字段赋值：
obj.field = &other - 切片元素赋值：
slice[i] = &other - map 赋值（value 是指针类型）：
m[key] = &other - 接口赋值（底层指向堆对象）：
var i interface{} = &other
它不拦截：
- 栈上变量之间赋值（如
a = b） -
string底层数组、[]byte、int等非指针类型 -
unsafe.Pointer绕过类型系统——这类操作完全逃逸写屏障保护
性能影响真实存在：混合写屏障在并发标记期高频执行，带来可观 CPU 开销。Go 编译器会通过静态分析生成 gcmask 位图，跳过无指针区域（如纯数值结构体），但无法绕过屏障本身。
STW 只发生在两个原子切片，但必须发生
很多人看 go tool trace 里“GC pause”曲线很短，就以为 GC 没停顿——其实 STW 严格限定在两处：
-
root marking：暂停所有 goroutine，遍历当前所有栈帧和全局变量，把根对象标灰 -
mark termination：标记主循环结束后再停一次，清空灰色队列残余 + **重扫所有 goroutine 栈**（因栈小且变更快，重扫比插屏障更高效）
这两个 STW 阶段加起来通常压至百微秒级，但它们是硬性前提。没有第一次 STW，根对象就无法统一入场；没有第二次，栈上新产生的指针引用就可能漏标。
注意：栈重扫不是“再跑一遍写屏障”，而是直接扫描当前栈帧内容。这也是为什么混合写屏障不作用于栈——它用更轻量的重扫替代了栈上屏障开销。
写屏障伪逻辑等价于 shade(old) + shade(ptr)，缺一不可
最致命竞态是：Mutator 把黑色对象 A 的字段从指向白色 C 改为指向白色 B，而 GC 已扫完 A —— B 再无机会被标记，直接误回收。混合写屏障解决这个的关键，在于同时做两件事：
- 若旧指针非 nil，调用
shade(old)：防止 C 因失去 A 引用而提前变白被回收（比如 C 还被其他路径引用） - 无论新旧，只要
ptr != nil，调用shade(ptr)：确保 B 被标灰，后续能被扫描到
这也就是为什么叫“混合”——它既保留插入屏障（拉新入队），又引入删除屏障（保旧不死）。单独任一种都无法满足强三色不变式。而这个逻辑，由编译器在编译期静态插入，你无法关闭或替换。
真正容易被忽略的是：写屏障的触发条件依赖 gcPhase == _GCmark，也就是说，它只在标记阶段生效。清扫阶段、idle 阶段、甚至标记前的内存分配，都不走这套逻辑。理解这点，才能看清 GC 各阶段的真实行为边界。
