go get -u 默认升级到最新主版本，可能破坏兼容性；应使用 -u=patch、-u=minor 或显式指定版本如 @v1.8.3 来安全升级，replace 可临时覆盖依赖但需及时清理，回退版本须显式指定并检查间接依赖冲突，go.sum 不可手动编辑但可通过 go mod tidy -v 清理无效条目。
go get -u 会升级到最新主版本，但可能破坏兼容性
默认执行 go get -u 时，Go 会把依赖升级到该模块的最新**主版本（major version）**，比如从 v1.12.0 升到 v2.0.0。而根据 Go Module 规则，v2+ 必须通过带 /v2 后缀的导入路径引用，否则编译失败——这会导致大量代码报错：import path does not contain package 或 cannot find module providing package。
- 想只升补丁/小版本（保持
v1.x不变），用：go get -u=patch - 想升小版本但不跨主版本（如
v1.5.0 → v1.12.0），用：go get -u=minor - 明确指定版本升级（最安全）：
go get github.com/some/pkg@v1.8.3
go.mod 中 replace 语句用于临时覆盖依赖版本
当某个依赖存在 bug、尚未发布修复版，或你正在本地调试其修改时，可用 replace 强制使用指定路径下的代码。它优先级高于远程版本，且不改变 go.sum 的校验逻辑（除非你同时改了内容）。
- 替换为本地路径：
replace github.com/example/lib => ../lib - 替换为特定 commit：
replace github.com/example/lib => github.com/example/lib@3a1b2c - 替换后需运行
go mod tidy才真正生效并更新go.sum - 注意：提交代码前应删除
replace行，否则协作者无法复现构建环境
回退依赖版本必须显式指定，并检查间接依赖冲突
Go 不提供类似 npm install --save-exact 的自动锁定机制，回退依赖不能只靠删 go.mod 再重装——因为 go mod tidy 会按依赖图自动拉取满足条件的最新版本，很可能又升回去。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 正确做法是直接运行：
go get github.com/some/pkg@v1.7.2 - 若提示
require github.com/some/pkg: version "v1.7.2" invalid，说明该版本未被其他已引入模块声明支持，需加-d参数先下载：go get -d github.com/some/pkg@v1.7.2，再手动编辑go.mod中的require行 - 回退后务必运行
go mod graph | grep some/pkg检查是否仍有其他依赖间接引入更高版本，造成版本冲突
go mod graph | grep github.com/some/pkg github.com/your/app github.com/some/pkg@v1.9.0 github.com/other/lib github.com/some/pkg@v1.10.1
go.sum 不可手动编辑，但可清理无效条目
go.sum 是模块内容的哈希快照，手动删行或改内容会导致后续 go build 失败：checksum mismatch。但长期迭代后，文件里常残留已废弃模块的旧记录，干扰阅读。
立即学习“go语言免费学习笔记（深入）”；
- 清理无用条目：运行
go mod verify确认当前go.mod下所有模块校验通过后，再执行go mod tidy -v，它会自动移除未被引用的go.sum条目 - 若某次升级后
go.sum新增大量变更，建议用git diff go.sum快速确认是否只有预期模块的哈希变化 - CI 流程中应始终校验
go.sum是否与本地一致，避免“本地能过 CI 报错”这类问题
go.mod 的 require 列表里，却真实影响行为。每次 go mod tidy 后，值得花 10 秒跑一遍 go list -m all | grep target 确认关键依赖的实际解析版本。 
