Go module retract 版本仍在缓存中时为何还能下载

Go module 的 retract 不是删除命令，所以一个版本已经被撤回，仍然可能从本地模块缓存或代理下载。它真正改变的是版本选择：@latest、升级和整理依赖时会避开撤回版本；已经写进 go.mod 的精确版本仍要尽量保持可构建。

先分清 retract 标记和模块缓存

模块作者通常会在更高版本的 go.mod 中写入撤回原因。例如误发布了 v1.2.3，随后发布 v1.2.4：

module example.com/lib

go 1.23

// v1.2.4 中声明撤回旧版本，避免新项目自动选中它。
retract v1.2.3 // 该版本缺少必要的初始化检查

这条声明告诉 Go：以后不要把 v1.2.3 当作正常升级候选。但它不会回收代理上的 .mod、.zip，也不会删除开发者机器里的 GOMODCACHE 文件。这样，已经锁定旧版本的项目仍能重建，撤回才不会变成一次破坏性下架。

撤回规则来自哪个版本的 go.mod

排查时最容易忽略的一点是：Go 通常从该模块的最新版本读取 retract 指令。也就是说，旧的 v1.2.3 即使没有写撤回声明，Go 仍可能通过更高的 v1.2.4 发现它已经被撤回。

可以用下面的命令查看模块当前可见的版本以及撤回信息。-retracted 的作用是把平时隐藏的撤回版本也纳入输出，不代表它会被自动选择：

# 查看最新版本携带的撤回信息，-json 便于脚本读取字段。
go list -m -retracted -json example.com/lib@latest

# 查看版本列表时把撤回项显示出来，便于对照候选集合。
go list -m -versions -retracted example.com/lib

如果这里看不到撤回信息，先检查模块是否真的发布了包含 retract 的更高版本、代理是否可访问，以及当前 GOPROXY 是否指向了预期的源。不要只盯着本地缓存目录判断规则是否生效。

自动选择被过滤，显式版本仍可下载

下面两种命令的意图不同。第一种让 Go 按规则选版本，撤回版本会被排除；第二种明确要求一个具体版本，目标是读取这个版本本身，因此仍可能命中缓存或从代理获取：

# 自动查询：通常会跳过被最新 retract 规则覆盖的版本。
go get example.com/lib@latest

# 精确查询：明确要求这个版本，用于复现旧项目或检查发布内容。
go mod download -json example.com/lib@v1.2.3

# 查看模块缓存与代理设置，确认下载从哪里来。
go env GOMODCACHE GOPROXY GOSUMDB

因此，“retract 版本还能下载”本身并不说明撤回失败。真正应该确认的是：新项目的 go get 或 go mod tidy 是否还会自动选它，以及当前项目是否已经在 go.mod 中固定了它。后者涉及兼容性和可复现构建，不能只为了消除提示就盲目改版本。

按目标选择升级、保留还是清理

如果只是想查风险，可以执行 go list -m -u -retracted all，把“当前依赖”和“可升级但被撤回的版本”分开看。只有确认替代版本兼容、测试已覆盖，才应修改 go.mod 并重新整理依赖。清理缓存适合排除本地文件干扰，不是撤回版本的发布修复手段。

常见问题

retract 会让已经发布的 zip 立即失效吗？

不会。撤回版本通常仍保留在版本控制仓库和模块代理中，目的是让已经依赖它的项目继续构建。

为什么 go list -m -versions 看不到这个版本？

普通版本列表会隐藏撤回版本。加上 -retracted 才能把它显示出来，再结合最新版本的 go.mod 判断撤回原因。

删除 GOMODCACHE 后就不能下载撤回版本了吗？

不一定。清理只影响本地缓存；只要代理或源代码仓库仍提供该版本，显式版本查询仍可能重新下载。

判断这个现象时，先问清楚命令是在“自动选版本”还是“请求指定版本”。前者验证撤回规则是否生效，后者验证版本内容是否仍可复现，两者同时成立并不矛盾。