Go无法生成同时支持AMD64和ARM64的单二进制文件，因其不支持fat binary；GOARCH仅接受单值，必须为各架构单独构建，且需显式设置CGO_ENABLED=0、GOOS和GOARCH以确保静态链接与架构匹配。
Go 无法生成一个同时支持 AMD64 和 ARM64 的单二进制文件——它压根不支持 fat binary，必须为每个架构单独构建。
GOARCH=amd64 和 GOARCH=arm64 是互斥的
你不能写 GOARCH=amd64,arm64，go build 会直接报错：unknown architecture “amd64,arm64”。GOARCH 只接受单值，这是 Go 工具链的硬性限制。背后原因是 Go 输出的是标准 ELF（Linux）、Mach-O（macOS）或 PE（Windows）格式，这些格式本身不支持多架构嵌套；Apple 的 universal binary 是 Mach-O 的私有扩展，Go 官方未实现，Linux/Windows 更无对应机制。
常见错误操作包括：
- 在 CI 脚本里漏掉
GOOS，只设GOARCH=arm64→ 默认按darwin构建，拿到 Linux 机器上必然报exec format error - 误以为
arm64和aarch64可混用：Linux 内核和uname -m输出aarch64，但 Go 只认arm64；反过来，用GOARCH=aarch64会触发编译失败 - 在树莓派 4 上用
GOARCH=arm GOARM=7→ 生成的是 32 位二进制，而树莓派 4 默认跑 64 位内核，拒绝加载
交叉编译时如何确认目标平台是否匹配
最可靠的方式是登录目标机器，运行 file ./your-binary，看输出里的关键字段：
立即学习“go语言免费学习笔记（深入）”；
- 含
ELF 64-bit LSB executable, x86-64→ 对应GOOS=linux GOARCH=amd64 - 含
ELF 64-bit LSB executable, ARM aarch64→ 对应GOOS=linux GOARCH=arm64 - 含
Mach-O 64-bit executable arm64→ 对应GOOS=darwin GOARCH=arm64
别依赖 uname -m 单独判断：有些 ARM 设备（如部分国产服务器）可能返回 arm64 或 aarch64，但 Go 编译器只接受 arm64；也别靠文件权限排查——chmod +x 解决不了架构错配。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
CGO_ENABLED=0 不是可选项，而是必需项
只要你的程序用到 net、os/user、os/exec 等包，且没显式关掉 cgo，Go 就可能隐式启用它，导致链接系统 libc 或其他动态库。一旦开启，交叉编译出的二进制就不再是纯静态链接，极大概率在目标机器上因缺少对应库或 ABI 不兼容而崩溃。
正确做法是始终加上：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o ./dist/app-linux-arm64 .
例外情况极少，比如你明确需要调用某个 ARM64 平台特有的 C 库，此时必须在对应架构机器上编译，放弃交叉编译。
CI/CD 中批量构建的最小可行脚本
不要用循环拼接变量，容易漏环境重置。推荐显式逐条调用，路径统一、命名清晰：
#!/bin/bash mkdir -p ./dist CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o ./dist/app-linux-amd64 . CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o ./dist/app-linux-arm64 . CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o ./dist/app-macos-amd64 . CGO_ENABLED=0 GOOS=darwin GOARCH=arm64 go build -o ./dist/app-macos-arm64 . CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o ./dist/app-win64.exe .
注意 Windows 输出必须带 .exe 后缀，否则双击无响应；./dist/ 是隔离产物的最低成本方式，避免污染源码树。
真正容易被忽略的点是：哪怕你只面向 Linux，也要区分 amd64 和 arm64 的运行时行为——比如内存序模型、原子指令基线、非对齐访问容忍度。这些差异不会在编译时报错，却可能在高并发或边界条件下突然暴露。
