go get @vX.Y.Z 是最直接生效的方式，它会立即更新 go.mod 中的版本号、下载指定版本并重写 go.sum 校验和；手动编辑 go.mod 后必须执行 go mod download 和 go mod verify；伪版本精确锁定 commit；replace 仅适合临时调试，长期锁定应使用 require 行写死版本或伪版本；go.sum 是构建安全的关键环节，必须同步更新并提交。
go get @vX.Y.Z 会直接更新 go.mod
执行 go get github.com/sirupsen/logrus@v1.9.3 不是“建议”操作，而是最直接生效的方式。它会立刻修改 go.mod 中对应 require 行的版本号，并下载该精确版本到本地缓存，同时重写 go.sum 中的校验和。只要没手动删改或执行 go mod tidy 引入新依赖，后续所有 go build 都会严格使用 v1.9.3。
手动编辑 go.mod 后必须运行 go mod download
如果你直接在 go.mod 里把 github.com/sirupsen/logrus v1.9.0 改成 v1.9.3，Go 不会自动拉取这个版本——它只会在首次构建或显式调用时才去下载。此时必须补上：
-
go mod download：确保 v1.9.3 已缓存，避免 CI 构建时网络失败 -
go mod verify：校验本地缓存是否与go.sum记录一致，防止被篡改或镜像不同步
漏掉这两步，可能在另一台机器上 go build 报错 “missing go.sum entry”，或 silently fallback 到其他兼容版本。
伪版本（v0.0.0-...）比语义化版本更精确
当你用 go get github.com/sirupsen/logrus@8a7e6c7 指定 commit，Go 会生成类似 v0.0.0-20230510152458-6b72e3a001f6 的伪版本。它不是近似值，而是硬编码了 commit 时间戳和 hash，等价于“锁定到那一行代码”。这种写法在以下场景更可靠：
- 上游还没打 v1.9.3 tag，但你已验证过某个 commit 修复了关键 bug
- 你想绕过语义化版本的兼容性规则（比如 v1.9.3 实际引入了不兼容变更）
- 私有仓库未规范打 tag，只能靠 commit 精确复现
注意：伪版本一旦生成，只要那个 commit 在远端仓库没被 force-push 覆盖，就永远可重现；但若有人重推同名 tag，而你的 go.sum 里还留着旧 hash，go build 会直接报 checksum mismatch。
replace 不是长期锁定方案，只适合临时覆盖
replace 写进 go.mod 确实能强制所有依赖都走指定路径或版本，但它不解决“版本锁定”的本质问题：
- 它只对当前模块生效，无法让下游项目继承该约束
- 如果替换成本地路径（如
./logrus），别人go build直接失败 - CI 环境若没同步
replace配置，构建结果就不一致
真正需要长期锁定微小版本时，require 行写死 v1.9.3 或伪版本才是唯一可移植、可审计、CI 友好的方式。replace 只应在调试 patch 或对接私有镜像时临时启用，用完即删。
最容易被忽略的是：go.sum 不是“锁文件”，但它决定了构建是否能通过。哪怕 go.mod 写死了 v1.9.3，只要 go.sum 里缺了它的校验和，或者校验和被篡改，go build 就会中断。所以每次改版本，必须确保 go.sum 同步更新并提交——它不是辅助文件，是安全链上不可绕过的环节。
