Go多平台构建产物管理需分离环境与产物并按平台归档：二进制命名用{name}_{GOOS}_{GOARCH}格式，目录结构为dist/{GOOS}/{GOARCH}/，默认禁用CGO，归档含SHA256SUMS校验文件，确保可复现、可审计。
Go 多平台构建的产物管理，核心在于「分离构建环境与目标产物」+「按平台归档可复现、可验证的二进制」。直接在宿主机上交叉编译再手动打包，极易因环境差异、CGO 依赖或路径污染导致产物不一致——这不是配置问题，是流程缺陷。
go build -o 生成的文件名必须带平台标识
跨平台构建时，go build 输出的二进制不能都叫 server 或 app，否则 Windows/macOS/Linux 产物会相互覆盖，CI 流水线无法并行或回溯。
- 推荐命名格式：
{name}_{GOOS}_{GOARCH}，例如api_linux_amd64、cli_darwin_arm64、worker_windows_386.exe - Windows 上建议加
.exe后缀（即使不强制执行，也利于识别），Linux/macOS 不加 - 构建命令示例：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o api_linux_arm64 . - 若用 Makefile 或 GitHub Actions，可用变量自动拼接，避免硬编码
归档目录结构要反映平台维度，而非随意扁平化
把所有产物扔进 dist/ 目录下一级，看似简单，实则破坏可追溯性。下游部署脚本、镜像构建或 QA 验证时，无法快速定位某平台某架构的最新包。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐结构：
dist/{GOOS}/{GOARCH}/，例如：dist/linux/amd64/api、dist/windows/386/cli.exe - 每个子目录内只放该平台产物 + 对应的
SHA256SUMS文件（含校验和与时间戳） - 避免在归档中混入调试符号（
-ldflags="-s -w"）、源码或go.mod—— 这些属于构建上下文，不是交付物 - 如需支持多版本归档（如 v1.2.0、v1.2.1），顶层再加
dist/v1.2.0/，不要靠文件名后缀区分
CGO_ENABLED=0 不是万能开关，但它是归档可信的前提
启用 CGO（CGO_ENABLED=1）意味着二进制可能动态链接 libc、openssl 等系统库，不同 Linux 发行版甚至不同内核版本都可能运行失败。归档这类产物，等于埋下环境兼容雷。
立即学习“go语言免费学习笔记（深入）”；
- 除非明确需要 C 库功能（如 SQLite 的 CGO 驱动、某些硬件绑定），否则默认设为
0 - 若必须启用 CGO，归档时必须同步记录构建镜像标签（如
golang:1.21-bookworm）和系统库版本（ldd --version、openssl version） -
file api_linux_amd64可快速确认是否静态链接：输出含statically linked才安全；若含dynamic，说明仍依赖外部 so - CI 中建议加一步校验：
ldd api_linux_amd64 || echo "static ok"，失败即中断归档
真正难的不是生成多个二进制，而是让每次 git tag v1.2.0 触发的归档结果完全可复现、可审计、可一键下载指定平台包——这要求构建脚本里没有隐式环境变量、没有本地缓存干扰、也没有手动干预环节。归档目录即发布清单，它不该是构建后的整理动作，而应是构建流程的自然终点。
