go.mod 和 go.sum 必须完整提交到 git，缺失会导致ci/cd构建时依赖校验失败或行为漂移；应先copy二者再run go mod download，并在dockerfile中显式设置goproxy和gosumdb，最后通过go mod verify校验依赖一致性。
go.mod 和 go.sum 必须完整提交到 Git
CI/CD 构建失败最常见原因是 go.mod 或 go.sum 缺失、被 .gitignore 误排除，或只提交了部分。容器环境从零拉取代码，没有本地缓存兜底，一旦 go.sum 缺失，go build 会尝试下载最新兼容版本，导致校验失败或行为漂移。
-
go.sum不是“可选附件”，它是模块内容的加密指纹，缺失即失去可重现性保障 - 多人协作中若有人用私有代理（如
GOPROXY=https://goproxy.example.com）执行go mod download，go.sum里会写入该域名下的哈希；其他人用默认代理拉取时会因域名不一致触发校验失败 - 正确做法：团队统一使用公开可信代理（如
https://proxy.golang.org,direct），并在 CI 配置中显式设置，避免依赖个人go env状态
Dockerfile 中必须分离构建与运行阶段，且禁止复用宿主机 GOPATH
很多 Dockerfile 错误地假设容器能“继承”宿主机的 Go 模块缓存，比如写 COPY ~/go/pkg/mod /go/pkg/mod —— 这在容器里根本不存在 ~/go 路径，RUN 阶段直接报错。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 构建阶段应基于
golang:1.21.5-bullseye这类带明确小版本的镜像，而非:1.21或:latest - 必须先
COPY go.mod go.sum .，再RUN go mod download，利用 Docker 层缓存加速并隔离依赖状态 - 禁止在构建阶段执行
go get -d或go install动态拉取工具（如air），除非明确go install到/usr/local/bin并验证 PATH
多阶段构建中 GOPROXY 和 GOSUMDB 必须透传或显式声明
容器内 shell 初始化不加载用户 ~/.bashrc，go 命令可能找不到，GOPROXY 可能为空，导致构建卡在模块下载环节，尤其在内网或代理受限环境。
- 在
builder阶段开头加ENV GOPROXY=https://goproxy.cn,direct和ENV GOSUMDB=sum.golang.google.cn - 若使用 VS Code Remote-Containers 或 GitHub Codespaces，需在
.devcontainer/devcontainer.json的remoteEnv中重复声明，否则调试会话无法解析依赖 - 不要依赖
go env -w设置这些变量——它写入$HOME/go/env，而多阶段构建中$HOME可能未初始化或不可写
CI/CD 流水线中必须校验 go.sum 而非仅跑 go build
go build 成功不代表依赖干净；它可能跳过校验、静默替换不匹配模块，或回退到旧版本。真正暴露问题的是 go mod verify，但它常被忽略。
- CI 步骤应为：
go mod download→go mod verify→go build，三者缺一不可 -
go mod verify失败时退出码为 1，必须让 CI 明确失败，不能用|| true吞掉错误 - 注意：
go mod verify不修复问题，它只报错；修复需回到开发机执行go mod tidy并提交更新后的go.mod和go.sum
go list -m all 时输出完全相同的模块列表和版本号——这要求所有配置都得是声明式的、无状态的、不依赖 shell 加载顺序的。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
