编译 go 源码前须确认三要点：一、系统已装 git≥2.18、gcc/clang 和 gawk，清空 goroot 环境变量及旧 go 安装目录；二、工作路径不含空格、中文或符号；三、goroot_bootstrap 必须指向完整、可用且版本合规（≥1.4 且 ≤ 目标版本）的二进制 go。
Go 源码编译前必须确认的三个检查点
直接从源码构建 Go，不是“下载解压就能用”，稍有疏忽就会卡在 make.bash 或报 cannot find package "unsafe"。关键不在步骤多，而在前置条件是否干净。
- 确保系统已安装
git（版本 ≥ 2.18），gcc（或clang）和gawk—— macOS 上xcode-select --install不够，还得装命令行工具完整版 - 删除所有已存在的
GOROOT环境变量；若之前装过二进制版 Go，务必清空/usr/local/go或自定义路径，否则src/make.bash会误读旧包路径 - 工作目录不能是
~/go或任何含空格、中文、符号的路径 ——src/all.bash在解析GOROOT_BOOTSTRAP时对路径敏感，常见报错cannot exec /path/to/go/bin/go: no such file or directory多源于此
用什么版本的 bootstrap Go 编译新 Go
Go 源码本身不能靠自己启动，必须依赖一个已有的 Go 工具链（即 GOROOT_BOOTSTRAP）。这个“引导版”不是随便找一个就行，它有硬性约束。
- 官方要求：bootstrap Go 版本必须 ≤ 目标源码版本，且 ≥ Go 1.4（因为 1.4 是最后一个用 C 写的编译器，之后全用 Go 自举）
- 推荐做法：从 go.dev/dl 下载比目标源码低一到两个小版本的二进制包（例如编译
go/src基于go1.22.0分支，就用go1.21.6作 bootstrap） - 别用系统包管理器装的 Go（如
apt install golang或brew install go）—— 它们常删减了src和pkg，导致make.bash找不到runtime包
执行 make.bash 时最常失败的两种情况
src/make.bash 看似只是一条命令，但背后触发的是整个标准库重编译流程。失败往往不报具体错误行，只停在某个包上。
- 现象：
--- FAIL: TestXXX (0.00s)后直接退出，没提示哪错 —— 这通常是测试环境缺失，比如没装tzdata（Linux）或系统时区数据库损坏（macOS），临时解决：加export GODEBUG=asyncpreemptoff=1再试 - 现象：
building go_bootstrap failed或卡在runtime包 —— 检查GOROOT_BOOTSTRAP是否指向一个可执行的go（运行$GOROOT_BOOTSTRAP/bin/go version应输出有效版本），并且该go能正常运行go list std - 别跳过
./all.bash直接跑make.bash—— 前者会先做跨平台构建检查和基础测试，能提前暴露GOOS/GOARCH不匹配问题
编译成功后仍不能直接用的配置陷阱
即使 make.bash 输出 All tests passed.，新生成的 go 二进制也不一定 ready for use。
立即学习“go语言免费学习笔记（深入）”；
-
GOROOT必须显式设为源码根目录（即含src/、bin/的那个目录），不能设成src/子目录，否则go env GOROOT会返回错误路径，进而导致go get找不到cmd/go -
PATH中新go的位置必须在旧版本之前（用which go验证），否则go build表面成功，实际调用的仍是系统旧版，尤其影响cgo行为 - 别依赖
go install来装工具（如gopls）—— 源码编译版默认不带cmd/外的工具，需手动进src/cmd/gopls运行go build
真正麻烦的从来不是编译那十几分钟，而是编译完发现 go mod download 报 unknown revision，结果查半天是 GOROOT 指向了 git 工作区未 clean 的分支。源码安装这事，信不过任何“自动推断”。
