go模块无法真正删除已发布版本，本质是通过伪版本注释、deprecated标记和replace引导用户主动避开旧版，而非物理移除；因模块不可变性，已下载版本仍可被复用，废弃核心在于显化警告与简化升级路径。
Go 模块没有“删除”或“下架”机制，go get 仍会拉到已发布的版本，所以所谓“废弃”，本质是**引导用户主动避开某个版本**，而非从镜像或代理中物理移除它。
为什么不能真正删除已发布的 module 版本
Go 的模块生态基于不可变性设计：一旦 v1.2.3 被 go mod download 过，它的 .zip 和校验和就固化在代理（如 proxy.golang.org）和本地缓存中。即使你删掉 Git tag 或私有仓库分支，已有 go.sum 记录仍能验证并复用该版本。
- GitHub/GitLab/Bitbucket 删除 tag 后，
go list -m -versions example.com/mymod仍可能显示该版本（取决于代理是否已缓存） -
go get example.com/mymod@v1.2.3在多数情况下依然成功，除非代理明确返回 404（极少见） - 强行撤回会破坏可重现构建——别人
go build时若依赖该版本，将直接失败
用 v0.0.0-伪版本 + 注释声明废弃
最通用、兼容所有 Go 版本的做法：发布一个特殊语义的伪版本（pseudo-version），并在其 go.mod 文件顶部加明确注释。
- 在代码库新建 commit，修改
go.mod，顶部加入：// DO NOT USE v1.2.3 —— broken, insecure, or superseded by v2.0.0 // See https://example.com/mymod/releases/tag/v2.0.0 for migration guide
- 不打正式 tag，而是让 Go 自动生成伪版本：
go mod edit -require=example.com/mymod@v0.0.0-20260803152000-abc123def456（时间戳+commit hash） - 推送该 commit，再运行
go mod tidy并提交go.mod和go.sum - 此举不会干扰现有用户，但新用户执行
go get example.com/mymod默认会拿到这个带警告的伪版本
通过 go.mod 的 // deprecated 注释 + require replace 引导升级
如果你控制着模块仓库，可在最新版 go.mod 中添加 // deprecated 行，并配合 replace 指向维护中的替代模块。
- 在
v2.0.0的go.mod里写：module example.com/mymod/v2 // deprecated: v1.x is unmaintained; migrate to v2.x or example.com/mymod-pro
- 同时在用户项目中，用
replace显式覆盖旧版本：replace example.com/mymod => example.com/mymod-pro v1.0.0
- 注意：
// deprecated不影响go get行为，但 IDE（如 VS Code）和go list -m -u会显示提示 - 搭配
go mod graph | grep mymod可快速定位哪些依赖还在拉旧版
关键细节：别忽略 go.sum 和 proxy 缓存的影响
即使你废弃了 v1.2.3，只要项目 go.sum 里还存着它的校验和，go build 就永远会尝试复用它——哪怕你已删掉远程 tag。
- 清理旧版本残留的唯一可靠方式：在用户侧执行
go mod edit -droprequire=example.com/mymod@v1.2.3，再go mod tidy - 若使用私有代理（如 Athens），需手动 purge 对应模块路径；公共代理（
proxy.golang.org）无法干预 - CI 流程中建议加检查：
go list -m all | grep 'example.com/mymod@v1\.' && exit 1，防止意外引入
真正的难点不在发布端，而在消费端——你无法强制他人更新。所以废弃的核心动作不是“删”，而是让旧版本在工具链里变得显眼、难用、且升级路径清晰。任何试图绕过 Go 模块不可变原则的操作，最终都会反噬可重现性和协作信任。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
