go默认只生成当前系统可执行文件，因其静态链接绑定宿主机goos/goarch；跨平台需显式设置goos、goarch及cgo_enabled=0，并规避cgo依赖。
Go 本身没有传统意义上的“跨平台包管理器”（比如 Python 的 pip + virtualenv 或 Node.js 的 npm + nvm），go mod 管理的是依赖版本，不是运行时环境；真正影响跨平台部署的是构建目标和依赖的二进制兼容性。
为什么 go build 默认只生成当前系统的可执行文件
Go 编译是静态链接，默认绑定宿主机的 GOOS/GOARCH。比如在 macOS 上直接 go build，输出的是 darwin/amd64 可执行文件，无法在 Linux 服务器上运行。
- 必须显式设置
GOOS和GOARCH环境变量才能交叉编译 - 某些依赖（如含
cgo的包）会破坏跨平台能力——一旦启用cgo，就必须有对应平台的 C 工具链 -
CGO_ENABLED=0是实现纯静态、跨平台二进制的关键开关（禁用 C 调用，放弃部分系统功能但换来可移植性）
如何安全地交叉编译出 Linux/Windows 可执行文件
以构建 Linux x64 版本为例，在 macOS 或 Windows 上执行：
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o myapp-linux main.go
常见组合：
立即学习“go语言免费学习笔记（深入）”；
- Linux 服务端：
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 - Windows 客户端：
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 - Raspberry Pi：
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 - 注意：
GOARM=7仅在GOARCH=arm时生效，且已逐渐被arm64取代
哪些依赖会让跨平台构建失败
只要代码或其间接依赖中出现以下情况，CGO_ENABLED=0 就会报错：
- 调用
net.LookupHost等依赖系统 DNS 解析逻辑的函数（底层走 libc） - 使用
os/user获取用户信息（依赖getpwuid等 C 函数） - 引入
github.com/mattn/go-sqlite3、github.com/godror/godror等含 cgo 的驱动 - 解决方案：用纯 Go 替代品，例如
dns.google.com做 DNS 查询、golang.org/x/sys/unix替代部分os/user行为、SQLite 用mattn/go-sqlite3的sqlite3_no_cgotag（需加-tags sqlite3_no_cgo）
CI/CD 中自动化多平台构建的最小实践
GitHub Actions 示例片段（不依赖 Docker，纯 Go action）：
jobs:
build:
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
go-version: ['1.22']
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v4
with:
go-version: ${{ matrix.go-version }}
- name: Build for linux/amd64
env:
CGO_ENABLED: 0
GOOS: linux
GOARCH: amd64
run: go build -o dist/myapp-linux .
- name: Upload artifact
uses: actions/upload-artifact@v3
with:
name: myapp-linux
path: dist/myapp-linux
关键点：不要试图在一个 job 里构建所有平台，而应利用 matrix 分发到不同 OS runner；每个 runner 设置对应 GOOS/GOARCH，并统一关掉 cgo。
最常被忽略的一点：本地开发时 go run 正常，不代表 go build 后能跨平台运行——务必在 CI 或干净容器里验证最终产物是否真能启动，尤其注意日志里有没有 exec format error 或 no such file or directory（后者常因动态链接缺失，即没关 cgo）。
