goos和goarch是go原生支持的交叉编译核心变量，配合cgo_enabled=0可生成静态链接二进制，适配多平台；-ldflags "-s -w"精简体积并提升安全性，但影响pprof调试。
GOOS 和 GOARCH 是 Go 交叉编译最核心的两个环境变量，不需要额外工具链，Go 原生就支持。只要本地装了 Go（1.16+ 更稳），就能直接生成 Linux、Windows、macOS、ARM64 等平台的二进制文件。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
为什么 CGO_ENABLED=0 经常被强调
默认开启 CGO_ENABLED=1 时，Go 会链接系统 C 库（如 glibc），这会导致：
- 编译出的二进制在目标服务器上运行时报 not found（比如 libpthread.so.0）
- 在 Alpine 镜像或精简版 Linux 上直接崩溃
- GOOS=linux GOARCH=amd64 编出来的程序，在 CentOS 可能跑得动，但在 musl libc 的 Alpine 就挂掉
设为 CGO_ENABLED=0 后，Go 用纯 Go 实现的标准库替代 C 调用（例如 DNS 解析走纯 Go 的 net/lookup），生成完全静态链接的二进制，扔到任意 Linux 发行版都能跑。
常见组合写法（推荐一行敲完）：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64 main.go
GOOS=linux 下不同 GOARCH 的实际兼容场景
不是所有 GOARCH 都能在通用服务器上直接跑：
- amd64：x86_64 CPU，绝大多数云服务器（阿里云、AWS EC2 x86 实例）
- arm64：AWS Graviton、华为鲲鹏、树莓派 4/5、Mac M 系列芯片（但注意 macOS 用 GOOS=darwin）
- 386：已基本淘汰，仅用于老旧 i386 设备；现代编译器对它的优化弱，不建议新项目用
- riscv64：国内部分信创环境（如 OpenEuler RISC-V 版），需 Go 1.21+ 支持，且依赖内核和工具链配套
验证是否真能跑：上传后别急着启动，先执行 file myapp 看架构，再 ldd myapp —— 如果提示 not a dynamic executable，说明是静态链接成功了。
编译命令里加 -ldflags "-s -w" 的真实作用
这两个 flag 不是“锦上添花”，而是生产部署的刚需：
- -s：去掉符号表（symbol table），防止逆向分析关键函数名、变量名
- -w：去掉 DWARF 调试信息，避免泄露源码路径、行号、变量类型等
两者合用通常让二进制体积减少 15%–25%，尤其对含大量依赖的 Web 服务（如 Gin + GORM）效果明显。
注意：加了之后，pprof 堆栈会丢失函数名和行号，线上排查性能问题时需权衡；调试阶段可临时去掉。
示例完整命令：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o ./bin/app main.go
跨平台编译容易被忽略的三个细节
很多人卡在看似“编译成功”但上线就失败，往往栽在这几点：
- 配置文件路径硬编码成 ./conf/config.yaml，但部署时放在 /etc/myapp/config.yaml，程序启动找不到——建议用 flag 或环境变量传入配置路径
- 日志写死到 ./logs/，而生产环境没这个目录、也没写权限，导致 panic —— 启动前检查并创建目录，或改用 systemd 的 StandardOutput=journal 直接走日志服务
- 代码里调用 os.Executable() 获取当前路径，结果在 systemd service 里返回的是 /usr/bin/myapp（软链目标），而非你期望的 /data/app/myapp —— 改用 filepath.Dir(os.Args[0]) 更可靠，但要注意 symlink 场景下仍需 filepath.EvalSymlinks
这些都不是编译问题，但会让“一次编译、到处运行”的承诺在落地时打折扣。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
