Go项目构建失败多因依赖状态不一致或校验失效，应优先检查go.mod与go.sum是否匹配、是否被手动修改；checksum mismatch需删go.sum后go mod tidy重建，必要时加-x查下载源；go get指定版本不生效是因MVS算法升级优先，可用commit hash或go mod edit -require锁定；vendor需显式加-mod=vendor参数且每次更新后重新生成并提交；replace与exclude混用时replace优先，但replace规则须团队同步维护。
Go 项目构建失败，八成不是代码问题，而是依赖状态不一致或校验失效。直接看 go.mod 和 go.sum 是否匹配、是否被意外修改，比重写 import 更快定位根因。
go build 报 checksum mismatch 怎么办
这是最典型的构建中断现象，本质是本地下载的包内容和 go.sum 中记录的哈希值对不上。常见原因不是网络污染，而是人为干预了依赖缓存或校验文件。
-
go.sum被手动删减或编辑过 —— 它必须由go mod tidy自动生成并提交，禁止手改 - 执行过
go mod download后又提交了新生成的go.sum—— 这会让其他协作者本地校验失败，因为go.sum应该只在开发者运行go mod tidy后提交 - CI 中设了
GOSUMDB=off或跳过go.sum校验 —— 失去防篡改能力，且破坏可重现性 - 私有模块未配置
GOINSECURE或 git credential，导致代理 fallback 到不一致源
修复建议：先 rm -f go.sum，再运行 go mod tidy 重建；若仍报错，加 -x 参数看实际下载 URL，确认是否命中了非预期镜像或 fork。
go get 指定版本不生效，还是拉 latest
go get foo/bar@v1.2.3 看似明确，但 Go 默认行为是“升级到满足约束的最新兼容版”，不是“锁定到该版本”。尤其当已有更高主版本（如 v2.0.0+incompatible）时，它会拒绝降级。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 检查目标 tag 是否真实存在：
curl -I https://proxy.golang.org/foo/bar/@v/v1.2.3.info - 若 tag 缺失，用 commit hash 强制拉取：
go get foo/bar@abcd123 - 想彻底绕过 MVS 算法，用
go mod edit -require=foo/bar@v1.2.3+go mod tidy - 避免用
go get -u—— 它会无视go.mod中的版本约束，强行升到最新 patch 或 minor
vendor 目录存在但构建仍连网
go mod vendor 只是复制依赖到本地，并不改变 Go 工具链默认行为。从 Go 1.14 起，即使有 vendor/，go build 仍会走 GOPROXY 校验或补全缺失间接依赖。
- 构建时必须显式加
-mod=vendor参数：go build -mod=vendor - 每次修改依赖后，要重新运行
go mod vendor并git add vendor/提交 —— vendor 不是“一次生成永久有效” - 验证 vendor 完整性：
go mod verify（注意不是go mod vet） - IDE（如 GoLand）可能忽略
-mod=vendor，需在设置里启用 “Use vendor directory”
replace 和 exclude 共存时行为异常
replace 和 exclude 都作用于 go.mod，但优先级和适用场景完全不同。混用时容易出现“明明 replace 了却还走远端”或“exclude 后编译失败”这类问题。
-
replace是路径重映射，仅影响 import 路径解析，不改变版本语义；exclude是完全剔除某版本，仅限临时规避严重 bug，不能用于长期维护 - 若同时 replace 和 exclude 同一模块，以
replace为准，exclude会被忽略 —— 因为 replace 已让该模块不参与版本选择 -
replace目标如果是本地路径（如./fix），必须确保该目录下有合法go.mod，否则go mod tidy会报错 - 私有仓库 replace 写法必须带版本号：
replace example.com/lib => git.example.com/team/lib v1.0.0，漏掉v1.0.0会导致解析失败
真正难处理的从来不是怎么写 replace，而是团队协作时没人同步更新 go.mod 中的 replace 规则 —— 它不像 require 那样会被 go mod tidy 自动收敛，必须靠 Code Review 卡住。
