go run 并非直接解释执行，而是先编译生成临时可执行文件再运行，因此会短暂出现两个进程：一个是 go 工具进程（负责编译），另一个是当前程序的独立子进程（命名通常为源文件名去扩展名），其内存占用较大是因 Go 运行时、堆预留及未立即归还 OS 的内存管理策略所致。
`go run` 并非直接解释执行，而是先编译生成临时可执行文件再运行，因此会短暂出现两个进程：一个是 `go` 工具进程（负责编译），另一个是当前程序的独立子进程（命名通常为源文件名去扩展名），其内存占用较大是因 go 运行时、堆预留及未立即归还 os 的内存管理策略所致。
当你执行 go run myfile.go 时，Go 工具链实际完成的是一个两阶段过程：
-
编译阶段：
go命令调用编译器将myfile.go编译为一个临时的、平台原生的可执行二进制文件（例如 Linux 下位于/tmp/go-build*/xxx/exe/a.out）； -
执行阶段：
go进程fork + exec启动该二进制文件作为独立子进程——这个子进程就是你看到的“名字像myfile”的进程（实际是go run内部通过-toolexec或临时路径推导出的显示名，htop/ps中常以 basename 呈现）。
✅ 正确理解：
-
go进程（约 5MB）是 Go SDK 工具本身，负责解析、编译、链接； -
myfile进程（约 36MB）是你的程序真正运行的实例，它是一个完整、自包含的 Go 应用程序——自带运行时（runtime）、垃圾收集器（GC）、调度器（GMP 模型）、网络轮询器、信号处理等全部基础设施。
⚠️ 关键误区澄清：
- ❌ 它不是“为读取 JSON 文件而额外创建的进程”，文件 I/O 由该进程内 OS 系统调用（如
read()）完成，无需跨进程； - ❌ 它不共享父
go进程的内存空间——两个进程完全隔离，符合操作系统进程定义（独立虚拟地址空间、PID/TID 不同）； - ❌ 内存大小（36MB）远超 2MB JSON 文件，是因为：
- Go 运行时默认预分配堆空间（尤其在首次 GC 前）；
-
getPages()解析后生成的结构体、字符串、切片等对象驻留在堆上； - Go 的内存分配器（mheap）向 OS 申请大块内存页（如 64KB~2MB 对齐），但不会在对象释放后立即归还 OS（除非内存压力触发
scavenge或MADV_FREE回收），这是性能优化设计（避免频繁 syscalls）。
? 验证方式（Linux/macOS）：
# 观察进程树关系（确认父子进程）
pstree -p | grep -A2 -B2 myfile
# 查看实际内存映射（RSS 36MB 是常驻物理内存，VSZ 更大）
ps -o pid,ppid,comm,rss,vsz -C myfile
# 查看 Go 运行时内存统计（需在代码中添加）
import "runtime"
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))? 替代方案（避免双进程感知）：
# 方式1：编译后手动运行（单进程，清晰可控） go build -o myapp main.go && ./myapp # 方式2：使用 go run -exec 自定义执行器（高级场景） go run -exec "strace -f" main.go # 调试用 # 方式3：生产环境务必用 go build → 部署静态二进制
? 总结：go run 的“双进程现象”是编译型语言工具链的标准行为，而非 Bug 或异常。所谓“大内存”本质是 Go 运行时的工程权衡——以空间换时间，提升高并发场景下的分配/回收效率。开发者无需干预内存归还时机，但应通过 pprof 分析真实内存泄漏（如意外持有全局引用），而非仅凭 ps RSS 值判断问题。真正的内存优化重点在于：控制对象逃逸、复用缓冲区（sync.Pool）、避免大结构体拷贝、及时关闭资源（文件/连接）——这些才影响 GC 压力与实际驻留内存。
