Go可跨平台编译但需关CGO_ENABLED、正确设置GOOS/GOARCH、加-ldflags="-s -w"；GOOS须为linux/darwin/windows，GOARCH依目标CPU选，组合须由go tool dist list验证，Windows需.exe后缀。
直接结论：Go 无需安装多套 SDK 就能跨平台编译，但必须关掉 CGO_ENABLED、用对 GOOS/GOARCH、加 -ldflags="-s -w" 剥离符号表——否则生成的二进制可能在目标机器上跑不起来，或体积翻倍。
GOOS 和 GOARCH 怎么选才不踩坑
选错组合会导致编译成功但运行失败，比如在 macOS M1 上直接 go build 得到的是 darwin/arm64，想部署到 x86_64 Linux 服务器却忘了改 GOARCH，结果得到一个无法执行的文件。
-
GOOS必须严格匹配目标系统内核名：linux（不是ubuntu或centos）、darwin（不是macos）、windows（注意不是win） -
GOARCH要看 CPU 架构，不是看开发机型号：M1/M2 是arm64，但多数云服务器仍是amd64；老旧 ARM 设备可能需要arm（32 位），不是arm64 - 不确定支持哪些组合？运行
go tool dist list，它输出的每一行都是合法的GOOS/GOARCH对，例如linux/amd64、linux/arm64、windows/386 - Windows 目标必须加
.exe后缀，否则双击打不开；Linux/macOS 不需要后缀，加了反而奇怪
为什么一定要设 CGO_ENABLED=0
默认情况下 CGO_ENABLED=1，Go 会尝试链接系统 C 库（如 libc）。一旦开启，交叉编译就大概率失败，或生成带动态依赖的二进制——放到目标机器上直接报 no such file or directory（找不到 libpthread.so 等）。
- 绝大多数纯 Go 项目完全不需要 CGO，关掉它才能获得真正静态、可移植的二进制
- 只有用了
net包的 DNS 解析（非netgo实现）、调用 C 函数（// #include）、或依赖 cgo 的第三方库（如某些 SQLite 封装）时才必须开 CGO - 如果必须开 CGO，就得在目标平台装对应交叉工具链（如
gcc-arm-linux-gnueabihf），复杂度陡增，不推荐 - 命令写法要完整：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app main.go，顺序无关，但缺一不可
-ldflags="-s -w" 剥离符号表的实际效果
这两个标志合起来能砍掉 20%–40% 的二进制体积，更重要的是消除调试信息泄露风险。但它们也带来真实代价：崩溃时堆栈里看不到函数名和行号，pprof 分析也变困难。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
-s：移除符号表（Symbol Table），nm、objdump查不到函数名，dlv调试器无法加载源码映射 -
-w：禁用 DWARF 调试信息，gdb失效，pprof只能显示地址而非函数名 - 生产环境建议始终加上；CI 构建可分两路：一路带调试信息用于内部诊断（不发布），一路加
-s -w用于分发 - 额外建议加
-trimpath：去掉编译路径信息，避免暴露本地开发路径（如/home/alice/project）
本地构建脚本怎么写才可靠
手动敲一遍命令容易漏参数、拼错变量。写脚本不是为了炫技，而是确保每次构建都走同一套逻辑，尤其当你要同时出 linux/amd64、linux/arm64、windows/amd64 三个版本时。
- 脚本开头固定设置：
set -euo pipefail，让任何错误立刻中断，避免静默失败 - 每个构建循环里显式写出
CGO_ENABLED=0，别指望环境变量继承 —— shell 子进程不一定继承父进程的导出变量 - 输出文件名包含平台标识，例如
app-linux-amd64、app-windows-amd64.exe，避免覆盖 - 别用
go build -a（强制重编所有依赖）：它破坏构建缓存，显著拖慢速度；除非你确认某个依赖被污染，否则不用
最常被忽略的点是：剥离符号表后，panic 堆栈只剩地址，查问题得靠日志+监控补全上下文；而关掉 CGO 后，os/user.LookupId 这类函数在某些精简镜像（如 scratch）里会返回空用户名——这不是 bug，是设计使然，得提前在代码里兜底处理。
