M1/M2芯片Go编译失败主因是架构不匹配、cgo交叉编译问题及网络校验干扰；需安装arm64版Go、禁用cgo或升级至Go 1.21+、使用-go mod=vendor离线构建。
编译报错 cannot execute binary file: Exec format error
这是最典型的 M1/M2 芯片 Go 编译失败现象，本质是二进制架构不匹配：你在 arm64 环境下运行了 amd64 编译的工具（比如旧版 go 二进制、交叉编译生成的 amd64 可执行文件），或反向操作。
检查当前 Go 安装架构：
file $(which go)
输出含 arm64 才对；若显示 x86_64，说明你装的是 Intel 版 Go，必须重装。
- 从官网下载页面明确选
go1.xx.x-darwin-arm64.pkg（不是-darwin-amd64） - 卸载旧版：
rm -rf /usr/local/go，再安装新包 - 确认
PATH没有残留旧路径（比如 Homebrew 的brew install go默认仍可能装 amd64，建议用brew install go --cask或直接官网包）
GOOS=linux GOARCH=amd64 go build 在 M1 上失败
这不是 M1 本身的问题，而是 Go 的交叉编译默认依赖本地 CGO_ENABLED 和系统头文件。当你在 macOS/arm64 上交叉编译 Linux/amd64，cgo 若开启，会尝试调用本地 clang，但 clang 不支持为非本机目标生成 C 代码（尤其涉及 syscall 或 net 包时）。
立即学习“go语言免费学习笔记（深入）”；
- 绝大多数纯 Go 项目应关闭 cgo：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build - 若必须启用 cgo（如用了
net包的某些 DNS 功能、或调用 C 库），需确保安装对应目标平台的 C 工具链（如x86_64-linux-gnu-gcc），但这在 macOS 上极难配齐，不推荐 - 验证是否真需要 cgo：运行
go list -f '{{.CgoFiles}}' .，空列表即可安全关掉
依赖里有 cgo 且无法禁用，编译卡在 undefined reference to `getrandom'
这是 M1 上常见于使用 github.com/mattn/go-sqlite3 或 golang.org/x/sys/unix 等包的报错。根本原因是 Go 的 unix 包在 macOS/arm64 上尚未完全覆盖 Linux syscall 的模拟逻辑，而某些 cgo 依赖会间接触发它。
- 升级 Go 到 1.21+（1.20.5+ 也有部分修复），官方已合并对
getrandom等 syscall 的 fallback 处理 - 临时绕过：设环境变量
GODEBUG=asyncpreemptoff=1（仅调试用，不解决根本） - 更稳妥做法：改用纯 Go 实现的替代库，例如用
modernc.org/sqlite替代mattn/go-sqlite3
Go mod vendor 后编译仍拉取远程依赖
M1/M2 本身不影响 vendor 行为，但容易误判——你以为 vendor 成功了，其实 go build 仍去拉 sum.golang.org 校验，而国内网络常导致超时或返回错误，看起来像“编译失败”。
- 确认 vendor 是否生效：
go build -v输出中不应出现Fetching或Downloading - 强制离线构建：
go build -mod=vendor -v（注意必须带-mod=vendor） - 若仍失败，检查
go env GOSUMDB，设为off或国内镜像（如sum.golang.google.cn）
真正麻烦的从来不是芯片架构，而是混用不同架构的工具链、没意识到 cgo 在交叉编译里的隐式依赖、以及把网络问题误认为平台问题。
