Go编译器执行go build时真实经历词法分析、语法分析、类型检查、SSA生成与优化、目标代码生成及静态链接五阶段；逃逸分析、SSA优化和目标架构适配最影响代码行为与性能。
Go 开发环境不用“搭建”——装好 go 命令，GOROOT 和 GOPATH（或启用 module 模式）就自动就位。所谓“底层编译原理”，不是玄学，而是你每次执行 go build 时真实发生的 5 个确定阶段，其中逃逸分析、SSA 优化、目标架构适配这三步最常影响你的代码行为和性能。
go install 后直接能用，但要注意 GOPROXY 和 GO111MODULE
从官网下载二进制包或用包管理器安装后，运行 go version 能看到输出即表示基础可用。真正影响日常开发的是这两个配置：
-
GO111MODULE=on（推荐强制开启）：让项目默认使用 Go modules，避免GOPATH混乱；关闭它会导致go get总往$GOPATH/src写，且无法正确解析相对路径依赖 -
GOPROXY=https://proxy.golang.org,direct（国内建议换成https://goproxy.cn）：否则go mod download可能卡在golang.org/x/...上，错误信息通常是Get "https://proxy.golang.org/...": dial tcp: i/o timeout
验证方式：新建空目录，执行 go mod init example.com/hello，再 go list -m all 不报错即通。
go build 的实际执行链：不是黑盒，是五个可观察阶段
go build 表面是一条命令，背后调用的是 go tool compile → go tool link，中间穿插类型检查、SSA 生成、逃逸分析等。你可以用这些参数窥探内部：
立即学习“go语言免费学习笔记（深入）”；
-
go build -gcflags="-S" main.go：输出汇编（注意不是最终机器码，是 plan9 asm 风格），看变量是否被分配到堆上 -
go build -gcflags="-m -l" main.go：显示逃逸分析结果，./main.go:5:2: moved to heap: x表示局部变量x逃逸了 -
go tool compile -S main.go：跳过链接，只做编译前端，适合调试 AST 或 SSA 中间态
关键点：逃逸分析发生在编译期，不是运行时；它决定变量是栈分配还是堆分配，直接影响 GC 压力。比如返回局部切片的底层数组指针，必然触发逃逸。
交叉编译必须设对 GOOS/GOARCH，但 CGO_ENABLED 是隐藏开关
编译 Linux ARM64 二进制，只需：
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 .
但一旦代码里用了 cgo（比如调 net.LookupIP 或 os/user），上面命令会失败，报错类似：
# runtime/cgo<br>exec: "gcc": executable file not found in $PATH
原因：CGO 默认启用，而交叉编译时 host 的 gcc 无法生成 target 平台的 C 对象。解决方式只有两个：
- 禁用 cgo：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app .（推荐，生成纯静态二进制） - 启用 cgo 并指定交叉工具链：
CC=aarch64-linux-gnu-gcc CGO_ENABLED=1 GOOS=linux GOARCH=arm64 go build -o app .，前提是你已安装aarch64-linux-gnu-gcc
注意：CGO_ENABLED=0 会让部分标准库回退到纯 Go 实现（如 net 包用 pure Go DNS 解析），功能一致但行为略有差异（比如不读取 /etc/nsswitch.conf）。
逃逸分析不是优化选项，是内存安全的硬约束
很多人以为加 -gcflags="-l"（禁用内联）就能“避免逃逸”，其实不能。逃逸分析独立于优化开关，它的依据只有两点：变量地址是否被函数外持有、是否被闭包捕获。
- 常见逃逸场景：
return &x、append(s, v)时底层数组扩容、闭包中引用外部局部变量 - 不逃逸的写法：
return x（值拷贝）、make([]int, 0, 10)预分配避免扩容、用sync.Pool复用对象 - 别信“加了 -ldflags=-s 就能减小体积”——它只 strip 符号表，不影响逃逸或内存布局
真正影响堆分配的，永远是代码结构本身，而不是编译参数。看不准？就用 -gcflags="-m" 实锤。
