Go项目生产落地需确保三件事：环境变量干净、模块依赖可复现、交叉编译不出错；须显式设置GOOS/GOARCH、禁用CGO_ENABLED=0、配好go.mod/GOPROXY，并用脚本一键构建多平台二进制。
Go 项目要真正落地到生产环境，尤其是混合部署（比如 Mac 开发、Linux 服务器运行、Windows 客户端分发），光装个 go 不行，必须搞定三件事：环境变量干净、模块依赖可复现、交叉编译不出错。其他都只是锦上添花。
GOOS/GOARCH 设置不对，build 出来根本不能跑
常见错误现象是：在 macOS 上执行 GOOS=windows go build 后生成了 myapp，双击打不开；或者扔到 Linux 服务器上提示 cannot execute binary file: Exec format error。
- 必须显式指定
GOARCH，不能只设GOOS—— 比如GOOS=linux默认用当前机器架构（M1 是arm64），但多数云服务器仍是amd64 - Windows 目标必须加
.exe后缀，否则文件没有可执行标记，系统不识别为程序 - 用
go tool dist list查当前 Go 版本能支持的所有组合，避免拼错（例如darwin/arm64对，macos/arm64错） - ARM 架构注意区分：
arm64（Apple Silicon / 新款树莓派）和arm（旧版 32 位 ARM，已基本淘汰）
CGO_ENABLED=0 不是可选项，是默认安全线
一旦代码里调用了 cgo（比如用 net 包做 DNS 查询、或引入 SQLite、OpenSSL 等 C 库），交叉编译就会失败，或生成的二进制在目标平台报 libpthread.so.0: cannot open shared object file。
- 绝大多数纯 Go 项目完全不需要
cgo，关掉它能保证静态链接、零依赖、秒启动 - 务必在每次构建时显式写
CGO_ENABLED=0，不要依赖默认值 —— 某些 CI 环境或 Docker 镜像里CGO_ENABLED可能被设为1 - 如果真要用
cgo（比如调硬件驱动），别硬扛交叉编译，直接用对应平台的 Docker 镜像构建，例如golang:1.22-alpine编 Linux 版
go.mod 和 GOPROXY 不配好，换台机器就编不过
错误现象：同一份代码，在同事的 Windows 上 go build 报 cannot find module providing package xxx；或者拉下来的依赖版本不一致，行为突变。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 所有新项目必须从
go mod init example.com/myapp开始，禁用GOPATH模式 -
GO111MODULE=on要全局启用（Linux/macOS 写进~/.zshrc，Windows 用setx GO111MODULE on /m） - 国内开发必须配
GOPROXY=https://goproxy.cn,direct，否则go get会卡死或超时 -
go.sum必须提交到 Git，它是校验依赖完整性的唯一依据，删了它等于放弃可复现性
一键构建多平台二进制，别手敲 6 遍命令
手动写 6 条 GOOS=xxx GOARCH=yyy go build 容易漏、难维护，也容易忘记加 -ldflags="-s -w" 去符号。
- 写个简单 Bash 脚本（Linux/macOS）或批处理（Windows），循环常见组合：
linux/amd64、linux/arm64、windows/amd64、darwin/amd64、darwin/arm64 - 输出文件名带上平台标识，例如
app-linux-amd64、app-windows-amd64.exe，避免覆盖 - 加
-a参数强制重编所有依赖，防止缓存导致某次构建“看似成功实则不兼容” - CI/CD 中建议统一用
make build-all封装，而不是裸写 shell 命令
最容易被忽略的是：每次切换开发机（比如从 MacBook 换到公司 Linux 工作站），第一件事不是写代码，而是执行 go env | grep -E 'GOOS|GOARCH|CGO_ENABLED|GOPROXY' 确认这四个变量是否符合预期。差一个，后面全白忙。
