goos和goarch必须同时显式设置，缺一不可；仅设其一将沿用宿主机架构或导致构建约束不匹配，cgo_enabled=0是跨平台部署默认前提，否则易因动态链接失败。
GOOS/GOARCH 必须成对设置，单设一个等于白设
只改 GOOS=linux 而不指定 GOARCH，Go 会沿用当前宿主机的架构（比如你 Mac M1 上默认是 arm64），但你可能想要的是 amd64 —— 这种隐式继承容易导致编译出错或二进制跑在目标机器上直接段错误。
常见错误现象：build constraints exclude all Go files，往往是因为代码里写了 // +build linux，但你只设了 GOOS=windows，没设 GOARCH，结果 Go 拿宿主机架构去匹配构建标签，发现全不满足。
- 安全写法永远用
env GOOS=xxx GOARCH=yyy go build，避免污染当前 shell 环境 - Mac M1 编译 Linux amd64：必须显式写
GOARCH=amd64，不能依赖默认 - ARM 架构注意额外变量：
GOARM=7（对应 ARMv7）或GOARM=8（ARMv8），GOARCH=arm64则不用
CGO_ENABLED=0 不是可选项，而是跨平台部署的默认前提
只要你的程序没调用 C 库（比如 SQLite、OpenSSL、某些图像处理库），就该默认关掉 cgo。否则生成的二进制会动态链接 libc，在 Alpine 容器或嵌入式设备上直接报 standard_init_linux.go:228: exec user process caused: no such file or directory。
开启 cgo 后，GOOS=linux GOARCH=arm64 编译失败并报 exec: "aarch64-linux-gnu-gcc": executable file not found，说明你缺交叉 C 工具链——这不是 Go 的问题，是你要自己配好整个 toolchain。
- 纯 Go 项目一律用
CGO_ENABLED=0，静态链接，体积稍大但部署零依赖 - 必须用 cgo 时，Linux/macOS 可用
xgo镜像；Windows 下几乎没法本地配齐所有 cross-gcc -
CGO_ENABLED=0会影响net.InterfaceAddrs()在某些旧系统上的行为（比如返回空），需实测验证
Windows 编译命令语法和其他平台不兼容
Mac/Linux 用 GOOS=windows go build 没问题，但在 Windows CMD 里这么写会报错：环境变量赋值语法不同，= 前后不能有空格，且必须分步 SET。
PowerShell 更麻烦：$env:GOOS="windows" 设置后，后续 go build 不会自动读取，除非你用 cmd /c "set GOOS=windows && set GOARCH=amd64 && go build -o app.exe" 包一层。
- CMD 正确写法：
SET CGO_ENABLED=0 && SET GOOS=windows && SET GOARCH=amd64 && go build -o myapp.exe - PowerShell 推荐直接用
env：前提是装了 WSL 或 Git Bash，否则老老实实用 CMD - 生成的
.exe文件默认无图标、无 manifest，这不是编译问题，是资源文件没嵌入——Go 原生不支持，得靠第三方工具如go-winres
文件路径和系统行为差异藏在标准库里，但不用手动处理
很多人担心 os.Open("config.yaml") 在 Windows 和 Linux 上路径分隔符不同，其实完全不必操心：os 和 path/filepath 包已自动适配。真正要留神的是硬编码路径、syscall 直接调用、或第三方库未做平台抽象的地方。
比如 syscall.Exec 在 Windows 上参数含义完全不同，net.InterfaceAddrs() 在 Windows 上可能返回 IPv6 地址而 Linux 返回 IPv4 —— 这些不是编译问题，是运行时逻辑要兜底。
- 路径拼接一律用
filepath.Join("dir", "sub", "file.txt")，别用"dir/sub/file.txt" - 临时目录用
os.TempDir()，别写死/tmp或C:\Temp - 检测平台行为差异时，优先查 Go 官方文档中各函数的 “Platform compatibility” 小节，而不是凭经验猜
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
