go 编译生成的可执行文件中并不直接包含独立的 gc 代码，而是静态链接了 go 运行时（runtime），其中集成了并发、三色标记-清除式的垃圾回收器，随程序启动自动运行。
go 编译生成的可执行文件中并不直接包含独立的 gc 代码，而是静态链接了 go 运行时（runtime），其中集成了并发、三色标记-清除式的垃圾回收器，随程序启动自动运行。
Go 的垃圾回收器（GC）并非以“插件”或外部库形式存在，也不是在编译期动态注入的独立模块；它本质上是 Go 运行时（Go runtime）的核心子系统之一，与调度器（GMP）、内存分配器（mheap/mcache）、栈管理等深度耦合。当你执行 go build 编译一个 Go 程序时，编译器（gc）会将你的源码编译为机器码，并在链接阶段静态链接 Go 标准运行时（libruntime.a 及相关对象），最终生成一个自包含的、无需外部 Go 环境依赖的二进制文件。
这意味着：
✅ go run main.go 实际上是 go build -o /tmp/xxx main.go && /tmp/xxx && rm /tmp/xxx 的封装——它同样生成并运行一个含完整 runtime 的临时二进制，GC 随之启用；
✅ go build -o app main.go 产出的 app 可执行文件已内嵌 runtime 和 GC，无需 Go SDK、GOROOT 或任何运行时环境即可独立运行；
❌ 你不会在二进制中找到名为 gc.c 或 markphase.s 的独立函数段——GC 逻辑被编译为汇编/机器码，与 runtime 其他部分融合部署，通过 runtime.gcStart() 等内部函数触发。
例如，一个最简程序：
package main
import "fmt"
func main() {
s := make([]int, 1000000) // 分配大块堆内存
fmt.Println(len(s))
// 此处 s 在函数返回后变为不可达，GC 将在合适时机回收
}编译后执行 ./app，其内存生命周期完全由内建 runtime 管理：分配走 mallocgc，回收由后台 gcpacer 和 gcBgMarkWorker goroutine 协同完成，全程无用户干预。
⚠️ 注意事项：
- Go 1.22+ 默认启用 非分代、并发、低延迟的三色标记-清除 GC（无 STW 全停顿，仅微秒级辅助暂停）；
- GC 行为可通过环境变量调优，如 GOGC=50（触发阈值设为上次堆大小的 50%）或 GODEBUG=gctrace=1 查看每次 GC 日志；
- 静态链接 runtime 导致二进制体积偏大（典型 Hello World ≈ 2 MB），这是为消除依赖、保障 GC 语义一致性所作的明确权衡；
- 无法在编译后剥离 GC——若需极致体积（如嵌入式场景），需考虑 TinyGo（不兼容标准 runtime，使用不同 GC 策略）。
总结来说，Go 的 GC 不是“附加组件”，而是 runtime 的原生能力。它被深度编译进每一个 go build 输出的二进制中，与你的业务逻辑共享同一地址空间和调度上下文，真正实现“开箱即用”的自动内存管理。
