retract用于模块作者在自身go.mod末尾声明废弃版本，如retract v0.1.0或retract [v0.1.0, v0.2.0)，仅由发布者提交且须置于文件末尾；下游go get @latest或go mod tidy会自动跳过被retract的版本，但对显式指定或已锁定的版本无效，且在私有/离线环境中基本失效。
retract在go.mod中如何声明已废弃的版本
retract不是用来回滚你自己的依赖，而是模块作者向下游用户声明“这个版本有问题，请不要用”。它写在模块自己的go.mod里，不是你的项目里。比如作者发现v0.1.0有严重 bug，又不能删 tag（因为语义化版本规范禁止修改已发布版本），就在自己模块的go.mod末尾加：
retract v0.1.0
也可以撤回一个范围：
retract [v0.1.0, v0.2.0)
注意：retract行必须放在go.mod文件末尾，且只能由模块发布者提交到该模块的源码仓库中；你作为使用者，改自己项目的go.mod加retract是无效的。
下游项目执行go get时如何响应retract声明
Go 1.16+ 默认会检查远程模块的retract声明。当你运行go get example.com/pkg@latest或go mod tidy时，如果最新可用版本被 retract，工具链会自动跳过它，选下一个未被 retract 的版本（如v0.2.1）。但这个行为只在满足以下条件时生效：
-
GO111MODULE=on（默认已启用） - 模块使用的是标准代理（如
proxy.golang.org），且该代理已同步了 retract 声明 - 本地缓存未锁定被 retract 的版本（比如之前
go get example.com/pkg@v0.1.0手动指定过）
如果你仍看到v0.1.0被拉入项目，大概率是因为：你显式指定了它（go get example.com/pkg@v0.1.0），或者go.sum里还存着它的校验和，而go mod tidy没触发重新解析——此时需先删掉go.sum中对应行或运行go clean -modcache再重试。
retract无法解决你当前的依赖问题？别误用
很多开发者想用retract来“让自己的项目避开某个坏版本”，这是典型误用。retract 是单向广播机制，只影响go get @latest或go mod tidy的自动版本选择，对已显式锁定的版本（如require example.com/pkg v0.1.0）完全无感。你项目里已经写了v0.1.0，哪怕上游 retract 了它，go build照常运行——Go 不会主动报错或拦截。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
真正该做的只有两件事：
- 手动把
go.mod里的v0.1.0改成v0.2.1，再跑go mod tidy - 或用
go get example.com/pkg@v0.2.1覆盖更新
retract 的价值在于预防：它让新用户第一次引入该模块时，就不会踩进坑。但它不修复历史遗留锁定，也不替代你的版本决策。
私有模块或离线环境里retract基本失效
如果你的模块托管在私有 Git 服务器，或设置了GOPROXY=direct、GOINSECURE，那么go命令根本不会去远端检查go.mod里的retract行——它只从本地 clone 或 proxy 缓存里读取模块内容，而 retract 声明不在这些路径里被解析。
这种情况下，retract 形同虚设。更实际的做法是：
- 在内部文档或 README 中明确标注“
v0.1.0已废弃，请勿使用” - CI 流程中加一条检查：
grep -q 'require.*v0\.1\.0' go.mod && exit 1 - 用
replace强制所有开发机指向安全版本（仅限临时兜底）
retract 是个优雅的协作信号，但它的传播依赖基础设施支持。没有代理同步、没有公网访问、没有标准发布流程，它就只是文件里一行没人读的注释。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
