因为go run调用的是PATH中优先匹配的go二进制，而非你新编译的$GOPATH/src/github.com/golang/go/bin/go；需显式指定路径或临时调整PATH才能生效。
为什么 go run 用的不是你刚改的 Go 源码？
当你修改了 $GOPATH/src/github.com/golang/go 下的编译器源码并运行 ./src/make.sh，生成的新 go 二进制默认放在 $GOPATH/src/github.com/golang/go/bin/go。但直接敲 go run main.go 调用的仍是系统 PATH 中的旧版本（比如通过包管理器安装的），不是你刚编译出来的。
必须显式用绝对路径调用才生效：
$/path/to/your/go/bin/go run main.go
常见错误现象：改了语法解析逻辑，但 go run 行为完全没变——八成是没切对二进制。
- 检查当前
go路径：which go和go version -
make.sh不会自动覆盖系统go，也不会修改PATH - 临时切换可执行
export PATH="/your/go/bin:$PATH"，但注意别污染日常开发环境
go build -x 输出里反复出现 asm、compile、link 是什么顺序？
Go 编译器（gc）实际是分阶段流水线作业：parse → typecheck → SSA → codegen → link，但 -x 日志里看到的命令名是历史遗留命名，并不严格对应阶段。例如：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
compile实际涵盖 AST 解析、类型检查、SSA 构建与优化 -
asm并非汇编器，而是把 SSA 转成目标平台机器码（如amd64指令） -
link阶段做符号解析、重定位、最终打包成 ELF/Mach-O/PE
真正影响性能的关键点在 SSA 优化层级（如 -gcflags="-l" 关闭内联会跳过大量 SSA pass），而不是 asm 这个名字暗示的“汇编阶段”。
cgo 启用后编译慢，且 go build -x 显示一堆 gcc 调用
cgo 开启时，Go 不再纯用自身工具链；每个含 import "C" 的文件都会触发 C 编译流程：gcc -c 编译 C 文件 → gcc -shared 或静态链接 → 最终由 Go linker 合并。这导致：
- 每次构建都重新跑 C 编译，无增量缓存（除非手动加
-ldflags="-s -w"减少调试信息） - 交叉编译时若未配对目标平台的
CC（如arm-linux-gnueabihf-gcc），会 fallback 到 hostgcc并报错 -
CGO_ENABLED=0可彻底禁用 cgo，但依赖net、os/user等包时会退化为纯 Go 实现（功能受限）
验证是否真走 cgo：go list -f '{{.CgoFiles}}' .，空列表说明没触发 C 流程。
交叉编译生成的二进制在目标机上 panic: runtime/cgo: pthread_create failed
这不是 Go 代码问题，而是目标系统资源不足或 libc 不兼容。典型场景：
- ARM 嵌入式设备内存太小，无法分配新线程栈（默认 2MB）→ 改用
runtime.GOMAXPROCS(1)+ 减少 goroutine 数量 - 目标系统用的是 musl libc（如 Alpine），但编译时没设
CGO_ENABLED=0或没用gcc-musl工具链 → 必须匹配 libc 类型 - 静态链接未生效：确认
#cgo LDFLAGS: -static且目标平台支持（Windows 不支持完全静态）
最容易被忽略的一点：即使 GOOS=linux GOARCH=arm64，若没配 CC 和 CGO_CFLAGS，cgo 仍会尝试调用 host 的 gcc，导致生成的二进制动态链接 host libc，一跑就挂。
