Go 的三色标记法对应 white、grey、black 三种核心状态：white 表示未标记，grey 表示已发现但子对象未扫描，black 表示已完全扫描；black 对象若遇新指针写入且写屏障失效，仍可能漏标。
Go 的 GC 不是“开箱即用就绝对安全”的黑盒——三色标记法一旦遇到写屏障缺失、栈未扫描或对象跨代误判，就会漏标，直接导致程序崩溃或内存泄漏。它不是理论模型，而是 runtime 中每毫秒都在执行的真实逻辑。
三色标记法在 Go runtime 中对应哪几个核心状态
Go 1.5 引入并发标记后，对象颜色不再靠字段模拟，而是复用 mspan 的 gcmarkBits 位图 + 全局 workbuf 队列协同维护：
-
white：初始全白；标记阶段结束仍为白的对象会被回收 -
grey：已发现但子对象尚未扫描（位于workbuf或本地标记队列） -
black：已完全扫描，且其所有可达子对象也均为black或grey
注意：black 并不表示“永远安全”——若此时有新指针写入，而写屏障未拦截，该对象可能被漏标。这也是为什么 Go 必须在 STW 阶段做 stack re-scan 和 finalizer scan。
为什么 Go 的写屏障只在赋值时触发，而不是读取时
写屏障的唯一目标是防止 grey → white 的引用丢失，即：当一个黑色对象新增指向白色对象的指针时，必须确保该白色对象被重新标记为 grey。读操作不会创建新引用路径，因此无需干预。
立即学习“go语言免费学习笔记（深入）”；
- Go 使用的是混合写屏障（hybrid write barrier），自 1.10 起默认启用，结合了 Dijkstra 和 Yuasa 的优点
- 典型触发点：
*slot = new_obj，其中slot指向已标记为black的对象字段 - 若关闭写屏障（如通过
GODEBUG=gctrace=1,gcpacertrace=1观察），GC 会退回到 STW 标记，吞吐量骤降
栈对象为何必须在 STW 阶段重新扫描
goroutine 栈是动态增长/收缩的，且运行时无法保证所有 goroutine 都处于安全点（safe-point）。即使启用了写屏障，栈上临时变量仍可能持有白色对象引用，而这些引用在并发标记期间可能已被覆盖或丢弃。
- STW 的
mark termination阶段会暂停所有 G，并逐个扫描每个G.stack的活跃帧 - 扫描范围包括：
sp到stackbase之间的所有指针字（按uintptr对齐检查） - 遗漏栈扫描 = 漏标高发区，尤其常见于闭包捕获、defer 参数、chan send/receive 临时缓冲场景
如何验证你的对象是否被正确标记（不依赖 pprof）
最直接的方式是观察 GC 日志中的 scanned 和 reclaimed 数值变化趋势，再结合 runtime.ReadMemStats 中的 NextGC 与 HeapAlloc 差值判断标记完整性：
go run -gcflags="-m -l" main.go # 查看逃逸分析，确认对象是否真的分配在堆上 GODEBUG=gctrace=1 ./yourapp # 观察每轮 GC 的 "scanned" 是否持续增长而非突降
更底层的方法是用 runtime/debug.SetGCPercent(-1) 手动触发 GC 后，立即调用 runtime.GC()，再检查 memstats.PauseTotalNs 是否异常拉长——这往往意味着标记队列积压或栈扫描阻塞。
真正难调试的从来不是算法本身，而是写屏障没生效（比如 cgo 调用绕过 runtime）、或者对象被 unsafe.Pointer 隐藏导致标记器根本看不到它。这些地方没有日志，也没有警告，只有静默的悬垂指针。
