必须显式用-o指定带平台标识的构建路径，如bin/linux/amd64/myapp，否则产物命名失控、覆盖混乱、CI不可靠；GOOS/GOARCH须每次构建时显式传入，禁止依赖环境变量默认值或全局export。
Go 多平台构建产物不能靠手动挪动或硬编码路径管理，必须由 go build 的输出控制逻辑 + 明确的目录约定共同约束，否则 CI/CD、本地多目标测试、版本归档都会出问题。
为什么不能把构建产物扔进 bin/ 就完事
看似合理，但实际踩坑频繁：CI 脚本里 cp bin/myapp-linux-amd64 这种写法会因构建环境（GOOS/GOARCH）不同而失效；本地开发时反复 go build -o bin/app 会覆盖前一次产物，导致无法并行验证 Windows 和 macOS 版本；更严重的是，bin/ 若被 .gitignore 忽略，就没人知道哪些产物是“已验证可发布的”。
- 构建产物名称必须携带平台标识，例如
myapp-linux-arm64、myapp-windows-amd64.exe，不能只叫myapp -
bin/目录应按平台分层，如bin/linux/amd64/、bin/windows/386/，而非扁平堆放 - 构建命令中必须显式用
-o指定路径，避免依赖当前目录名推导（go build默认输出名不可控）
GOOS 和 GOARCH 必须在构建时显式传入
别依赖宿主机环境变量默认值。Mac 上不设 GOOS=windows 就永远编译不出 .exe；Linux CI 节点若没清空环境，可能意外继承了上一个 job 的 GOARCH 值。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：
GOOS=linux GOARCH=arm64 go build -o bin/linux/arm64/myapp . - Windows 下需加
.exe后缀：GOOS=windows GOARCH=amd64 go build -o bin/windows/amd64/myapp.exe . - 交叉编译前先确认目标平台是否被支持：
go tool dist list | grep linux - 不要在
Makefile或脚本里 export 全局GOOS——它会影响后续所有go命令（比如go test也会尝试交叉编译）
如何让 bin/ 目录结构可预测且可清理
靠人手删 bin/ 下某几个文件不可靠，尤其当团队多人共用同一工作区时。必须用机器可读、可重复的方式定义“哪些算构建产物”。
立即学习“go语言免费学习笔记（深入）”；
- 统一使用
bin/$(GOOS)/$(GOARCH)/为子目录模板，确保路径与构建参数严格对应 - 添加 Makefile 目标：
make clean-bin应执行rm -rf bin/*/*，而不是rm -rf bin（避免误删bin/scripts/这类手动维护的脚本） - CI 流水线中，每次构建前先
mkdir -p bin/$(GOOS)/$(GOARCH)，避免因目录不存在导致go build -o失败 - 如果项目含多个
cmd/子命令（如cmd/server、cmd/cli），产物路径应体现命令名：bin/linux/amd64/server、bin/linux/amd64/cli
最易被忽略的一点：构建产物目录结构和 go.mod 中的模块路径无关，但和 cmd/ 下每个 main.go 的包导入路径强相关——如果你把 cmd/cli/main.go 的包名写成 package main（应该如此），那它的构建行为就只取决于你执行 go build 时所在的目录和 -o 参数，其他任何地方的配置都影响不了它。
