go 编译生成的可执行文件并非“裸代码”，而是静态链接了包含垃圾回收器（gc）、调度器、反射系统等核心功能的 go 运行时（runtime），因此 gc 在运行时自动启用，无需外部依赖或额外配置。
go 编译生成的可执行文件并非“裸代码”，而是静态链接了包含垃圾回收器（gc）、调度器、反射系统等核心功能的 go 运行时（runtime），因此 gc 在运行时自动启用，无需外部依赖或额外配置。
Go 的垃圾回收器是其运行时系统（Go runtime）不可分割的一部分。与 C 或 Rust 等语言不同，Go 不依赖操作系统或虚拟机提供内存管理；相反，它在编译阶段就将精简、高度优化的 runtime（含并发标记-清除 GC）静态链接进最终二进制文件中。
这意味着：
- ✅ go build 生成的可执行文件是自包含的（self-contained），直接运行即可触发 GC；
- ✅ go run main.go 本质是先调用 go build 生成临时二进制，再执行——因此同样使用同一套内嵌 runtime 和 GC；
- ❌ 不存在“单独编译 GC 模块”或“运行时动态加载 GC”的机制；GC 逻辑已深度集成于 runtime 的调度循环中（如 runtime.gcStart、runtime.markroot 等函数）。
例如，一个最简程序：
package main
import "fmt"
func main() {
data := make([]byte, 10<<20) // 分配 10MB
fmt.Printf("Allocated %d bytes\n", len(data))
// 此处 data 将在函数返回后成为 GC 候选对象
}编译后（go build -o hello main.go），该二进制（Linux x86_64 下通常约 2–3 MB）已包含完整 runtime：GC 启动由 runtime 自动触发（基于堆增长阈值、后台强制周期等策略），开发者无需手动调用 runtime.GC()（除非调试或特殊场景）。
⚠️ 注意事项：
- Go 1.22+ 默认启用 Pacer 驱动的增量式 GC，大幅降低 STW（Stop-The-World）时间，但底层仍依赖编译进 binary 的 runtime 实现；
- 使用 -ldflags="-s -w" 可剥离调试符号减小体积，但无法移除 runtime 或 GC——它们是执行必需的基础设施；
- CGO 启用时，runtime 仍主导 Go 部分内存管理，C 分配的内存需手动管理（C.free），不受 Go GC 影响。
简言之：Go 的 GC 不是“附加组件”，而是与 goroutine 调度器、网络轮询器 并列的 runtime 核心服务——它被编译进每一个 Go 二进制，随进程启动而就绪，全程自动、透明、高效。
