go 编译生成的可执行文件中内嵌了运行时（runtime），而垃圾回收器（gc）正是该 runtime 的核心组件之一，并非独立代码模块，也无需外部依赖。
go 编译生成的可执行文件中内嵌了运行时（runtime），而垃圾回收器（gc）正是该 runtime 的核心组件之一，并非独立代码模块，也无需外部依赖。
Go 的垃圾回收器并非以“独立库”或“插件”形式存在，也不会在编译阶段被当作普通用户代码一样静态链接为孤立的目标文件。相反，它深度集成于 Go 的运行时系统（Go runtime）之中——这是一个用 C 和汇编编写的轻量级系统层，随 Go 源码一同维护，并在每次构建时自动链接进最终二进制。
当你执行 go build 生成可执行文件时，Go 工具链会将你的 Go 代码编译为机器码，并与标准 Go runtime（含调度器、内存分配器、栈管理、panic/recover 机制及 并发标记-清除式 GC）静态链接。这意味着：
✅ GC 逻辑完全内置于二进制中；
✅ 启动时由 runtime 自动初始化并周期性触发（基于堆增长速率、GOGC 环境变量等）；
✅ 不依赖操作系统或外部运行时环境（如 JVM 或 .NET CLR）；
❌ 你无法在编译后剥离 GC —— 它是 runtime 不可分割的一部分。
例如，一个最简程序：
package main
import "fmt"
func main() {
fmt.Println("Hello, World")
}执行 go build -o hello main.go 后生成的 hello 文件（Linux x86_64 下通常约 2–3 MB）即已包含完整 runtime 和 GC 实现。可通过 strings hello | grep -i gc 或 go tool objdump -s "runtime.gc" hello 查看相关符号（需调试信息未被 strip）。
⚠️ 注意事项：
- go run 本质是 go build + 临时执行，因此同样加载完整 runtime 和 GC；
- Go 1.22+ 引入了更激进的栈收缩与低延迟 GC 优化（如异步抢占、软堆上限），但其部署方式不变；
- 若需极致体积控制（如嵌入式场景），可启用 CGO_ENABLED=0 并使用 upx 压缩，但 GC 仍不可移除；
- GC 行为可通过 GODEBUG=gctrace=1 或 runtime/debug.SetGCPercent() 动态调整，但底层实现始终由内置 runtime 承载。
简言之：Go 的 GC 不是“附加组件”，而是 runtime 的原生能力——编译即固化，启动即就绪，这是 Go 实现“单二进制分发”与“开箱即用并发内存安全”的基石设计。
