确认真·arm64版go的唯一可信证据是go version输出含darwin/arm64；同时arch应返回arm64，go env goarch和goos须分别为arm64和darwin，file $(which go)需显示arm64。
怎么确认你装的是真·ARM64版Go？
不是“能跑就行”，而是必须看到 darwin/arm64 ——这是唯一可信证据。Rosetta 2能硬转译 darwin/amd64 版Go，但它会让 go build 输出的二进制仍是x86架构，运行时可能崩在 bad CPU type in executable，且性能打折。
- 执行
go version，输出必须含darwin/arm64（如go version go1.23.3 darwin/arm64） - 执行
arch，终端应输出arm64；若为amd64，说明你在 Rosetta 下运行，需退出终端重开（或检查 iTerm2 是否勾选了“使用 Rosetta”） - 执行
go env GOARCH和go env GOOS，应分别返回arm64和darwin
Homebrew安装Go为何有时会装错？
Homebrew 默认行为在 Apple Silicon 上已适配，但旧缓存、残留 Intel 版本或未清理的 brew tap 可能导致它悄悄拉下 amd64 包——尤其当你之前装过 Intel 版 Go 或用过 brew install --cask golang 这类非标准方式。
- 装前先清旧：
brew uninstall go && brew cleanup - 装时加
--build-from-source强制编译（不推荐日常用，但可排除二进制包污染） - 装完立刻验证：
file $(which go)应显示Mach-O 64-bit executable arm64，而非x86_64 - 别信页面自动推荐：官网下载页有时默认推
amd64，务必手动点选darwin-arm64.pkg
CGO_ENABLED=1 时为什么程序一运行就崩溃？
Go 编译器不会检查 C 依赖是否匹配 ARM64，直到运行时才报 dyld: Library not loaded: ... Reason: no suitable image found 或直接 bad CPU type。这是因为 Homebrew 默认把库装到 /opt/homebrew/lib（arm64），但如果你曾用 Rosetta 装过 brew install sqlite3，它实际装的是 x86_64 版，路径却是同一个。
- 确认 C 库架构：
file /opt/homebrew/lib/libsqlite3.dylib必须含arm64 - 重装所有 CGO 依赖前，先退出 Rosetta：
arch -arm64 brew uninstall sqlite3 && arch -arm64 brew install sqlite3 - 编译时显式指定：
CGO_ENABLED=1 GOOS=darwin GOARCH=arm64 go build（避免环境变量被继承污染） - 临时禁用 CGO 测试是否是它的问题：
CGO_ENABLED=0 go build
交叉编译 Universal Binary 真有必要吗？
除非你明确要分发给 Intel Mac 用户，否则不用。M1/M2 原生 Go 编译出的 darwin/arm64 二进制，在 Apple Silicon 上启动更快、内存更省、并发调度更稳——尤其是 runtime.NumCPU() 返回真实核心数（比如 8 或 10），而 Rosetta 下常返回 4，影响 goroutine 调度策略。
立即学习“go语言免费学习笔记（深入）”；
- 通用二进制（Universal）本质是两个架构二进制拼接，体积翻倍，且 macOS 14+ 已开始弱化对
lipo的支持 - 若真要兼容，优先用
GOOS=darwin GOARCH=arm64 go build -o app-arm64+GOOS=darwin GOARCH=amd64 go build -o app-amd64，再lipo -create -output app app-arm64 app-amd64 - 注意：
go run不支持交叉，只能go build后执行
最容易被忽略的是：go install 生成的命令行工具，默认就是当前机器架构，但如果你在项目里用了 //go:build cgo 或 #cgo 指令，哪怕没显式设 CGO_ENABLED=1，Go 1.21+ 也会自动启用 CGO——此时 C 库架构错误照样 runtime 崩溃，而且毫无警告。
