Go Module 强制要求依赖有版本标识，无tag仓库会生成伪版本（如v0.0.0-20230415123456-abcdef123456），其时间戳导致不稳定性；避免方式包括打tag、replace或fork，@none需配合go mod tidy才能彻底移除未引用依赖。
Go Module 不支持“无版本控制”的项目——它天然要求每个依赖都有可解析的版本标识。如果你试图在没打 tag 或没用语义化版本的仓库上使用 go get，Go 会自动生成伪版本（pseudo-version），这不是妥协方案，而是强制行为。
为什么 go mod init 后 require 项全是 pseudo-version？
当你执行 go mod init 后运行 go get github.com/some/project，而该仓库没有发布任何 tag（比如 v1.0.0），Go 就无法提取语义化版本号，只能退而求其次生成类似 v0.0.0-20230415123456-abcdef123456 的伪版本。
- 格式固定为
v0.0.0-YMMDDHHMMSS-commit-hash，时间戳来自最新 commit - 这种版本不具备稳定性：同一 commit 在不同时间拉取，可能生成不同伪版本（因时间戳变）
-
go.sum会记录该伪版本的校验和，但下次go mod tidy可能因远程仓库新提交而触发更新
如何避免伪版本污染 go.mod？
核心思路是：让依赖“看起来有版本”。不是绕过版本控制，而是补上最小可行版本标识。
- 如果能改依赖方仓库：至少打一个
v0.1.0tag（哪怕只是占位），go get就会用这个真实版本 - 如果不能改远端仓库：用
replace指向本地路径或 fork 后打 tag 的镜像，例如：replace github.com/some/project => ./local-fork
- 慎用
@commit：如go get github.com/some/project@abc1234，Go 仍会转成伪版本写入go.mod，且无法保证长期可重现
go get @none 删除依赖为何有时不生效？
go get some/module@none 的本意是移除依赖，但它只在 go.mod 中删除 require 行——前提是该模块没被其他依赖间接引用。
立即学习“go语言免费学习笔记（深入）”；
- 若 A 依赖 B，B 依赖 C，则直接
go get C@none不会删掉 C，因为它是间接依赖 - 真正生效需配合
go mod tidy，它会扫描全部 import 并清理未使用的require - 注意：如果代码里还留着
import "github.com/xxx/yyy"，tidy就不会删，哪怕你刚执行了@none
伪版本不是 bug，是 Go Module 在缺失版本元数据时的确定性 fallback。真正要警惕的，是把伪版本当稳定依赖长期使用——它意味着你没和上游建立明确的契约，随时可能因一次推送而意外升级。
