Go程序编译经历词法分析、语法解析、类型检查、中间代码生成、SSA优化、目标代码生成和链接，全程内存流水线完成，输出静态链接二进制；go run每次重新编译不缓存，而go build复用$GOCACHE；main执行前先运行runtime初始化及各包init函数。
Go程序从源码到可执行文件经历了哪些阶段
Go编译不是简单的“翻译成机器码”，而是包含词法分析、语法解析、类型检查、中间代码生成、SSA优化、目标代码生成和链接等完整流程。整个过程由go build驱动，但不生成传统意义上的“.o”中间文件——所有步骤都在内存中流水线完成，最终直接输出静态链接的二进制。
关键点在于：Go默认静态链接（包括libc的等效实现），所以生成的二进制不依赖系统glibc，也不需要CGO_ENABLED=0来强制纯Go模式（除非你明确用了C代码）。这解释了为什么一个简单main.go在Linux上编译出的文件能在另一台没装Go的机器上直接运行。
为什么go run main.go比go build慢，且不能复用
go run本质是先调用go build -o生成临时二进制，再执行它，最后删除临时文件。它不会缓存编译结果，每次执行都重走全流程；而go build会利用构建缓存（$GOCACHE），对未变更的包跳过重新编译。
- 反复修改后测试，用
go build && ./myapp比go run更省时间 -
go run无法传入-ldflags等链接期参数（比如注入版本号），因为临时路径不可控 - 调试时
go run -gcflags="all=-N -l"可禁用优化便于gdb，但生产环境必须用go build
main函数执行前发生了什么：runtime初始化细节
Go二进制启动后，并不直接跳转到你的main.main。而是先执行由链接器插入的rt0_go（架构相关）→ runtime·asmcgocall → runtime·schedinit，完成以下动作：
立即学习“go语言免费学习笔记（深入）”；
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 设置goroutine调度器（
m0,g0,g初始栈分配） - 初始化内存分配器（mheap, mcentral, mcache）和垃圾收集器（GC状态机注册）
- 运行
init()函数：按包依赖顺序，每个包的init在main前执行一次
这意味着：全局变量初始化、sync.Once注册、甚至http.HandleFunc这类注册调用，都发生在main入口之前——这也是为什么某些“未显式调用却生效”的逻辑实际在这里埋下伏笔。
交叉编译为什么能直接指定目标平台
Go工具链自带多平台支持，无需额外安装交叉编译器。只要设置GOOS和GOARCH，go build就会切换目标平台的汇编器和链接器：
-
GOOS=windows GOARCH=amd64 go build -o app.exe main.go→ 生成Windows PE文件 -
GOOS=linux GOARCH=arm64 go build main.go→ 输出aarch64 ELF，可在树莓派4上直接运行
注意：cgo会破坏这种纯净性——一旦启用，就必须有对应平台的C交叉工具链（如aarch64-linux-gnu-gcc），否则报错exec: "aarch64-linux-gnu-gcc": executable file not found。纯Go项目才能真正“一键跨平台”。
最易被忽略的是构建缓存失效条件：除了源码变更，go.mod内容、Go版本升级、GOOS/GOARCH切换都会让缓存失效。频繁切平台开发时，go clean -cache有时比等待缓存重建更快。
