Go 1.11起应使用go mod管理依赖，初始化模块执行go mod init example.com/myapp生成go.mod，go get默认升级间接依赖，锁定需手动require并tidy，go.sum校验依赖完整性，replace仅限开发调试且需谨慎。
Go 1.11 引入 go mod 后，Golang 的依赖管理已基本脱离 GOPATH 和 vendor 手动模式；当前绝大多数项目应直接使用模块（module）机制，而非试图“绕过”或“降级兼容”旧方式。
如何初始化一个带版本控制的 Go 模块
在项目根目录执行：go mod init example.com/myapp。这会生成 go.mod 文件，记录模块路径和 Go 版本（如 go 1.21）。注意：go mod init 不会自动拉取依赖，也不会读取现有 vendor/ 或 Gopkg.lock —— 它只声明模块身份。
- 模块路径（如
example.com/myapp）不必真实可访问，但需全局唯一，且影响后续import路径 - 若项目已有
import语句指向非标准路径（如github.com/user/lib），go mod init可省略参数，Go 会尝试从 import 中推断 - 执行后立即运行
go build或go test，Go 会自动补全依赖并写入go.mod和go.sum
为什么 go get 会升级间接依赖，以及如何锁定
go get 默认行为是升级到满足要求的最新兼容版本（遵循语义化版本规则），包括间接依赖（即你没直接 import，但依赖链中用到的包）。这常导致 go.mod 变动不可控。
- 要只更新显式依赖（不碰间接依赖），加
-u=patch：例如go get -u=patch github.com/sirupsen/logrus - 要完全禁止升级，改用
go install（仅用于可执行命令）或直接编辑go.mod后运行go mod tidy - 想锁定某间接依赖版本？在
go.mod中手动添加require行（即使未直接 import），然后go mod tidy会保留它
go.sum 文件被修改意味着什么
go.sum 记录每个依赖模块的校验和，用于验证下载内容完整性。每次 go mod download、go build 或 go mod tidy 都可能更新它——只要依赖的哈希值与本地记录不一致（比如远程 tag 被强制重写、或你切换了代理源）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不要手动编辑
go.sum；若校验失败，Go 会报错checksum mismatch，此时应确认是否用了非官方镜像源，或该模块是否被篡改 - CI 环境中务必检查
go.sum是否被意外修改（可通过git status go.sum捕获） - 私有模块若无签名支持，
go.sum是唯一防篡改手段，丢失它等于放弃依赖可信链
何时必须用 replace，以及它的副作用
replace 用于临时替换依赖路径或版本（如调试 fork 分支、修复尚未发布 PR 的问题），但它会绕过模块校验和验证，且影响整个模块树中的所有引用。
- 语法示例：
replace github.com/old/pkg => ../local-pkg或replace golang.org/x/net => golang.org/x/net v0.15.0 - 仅应在开发阶段使用；上线前应移除，或确保对应 commit 已发布为正式版本并更新
require - 多个
replace可能互相冲突；若 A 依赖 B，B 又replace了 C，而你的顶层也replace了 C，则以顶层为准 —— 这种隐式覆盖极易引发运行时行为差异
真正棘手的不是怎么写 go.mod，而是当团队共用同一模块路径、又混用不同 Go 版本、还穿插私有代理和 replace 规则时，go build 结果可能因环境微小差异而不同。这时候，go list -m all 和 go mod graph | grep 比任何文档都管用。
