retract 是模块根 go.mod 中声明式屏蔽旧版本的机制，仅影响下游执行 go mod tidy 时的依赖选择，不删除远程版本或改变 go.sum；须配合新版本发布才能使 @latest 生效。
retract 命令只在 go.mod 里生效，不推送到远程仓库
Go Module 的 retract 不是“撤回发布”，而是本地模块消费者端的**声明式屏蔽**。你不能靠它让别人自动忽略某个版本——除非他们也显式更新自己的 go.mod 并加入 retract 指令。
常见错误现象：go list -m -u all 仍显示旧版本为“可升级”，go get 仍可能拉到被 retract 的版本。
- retract 必须写在模块自己（即该 module 的根
go.mod）中，才对依赖它的其他项目起作用 - 仅当下游项目执行
go mod tidy或go build时，才会检查并跳过被 retract 的版本 - retract 后的版本仍存在于 proxy（如 proxy.golang.org）和你的私有 GOPROXY 中，不会被删除
怎么写 retract 语句：语法、范围与时间格式
retract 后只能跟版本号或版本区间，不支持通配符、分支名或 commit hash；时间戳必须是 RFC 3339 格式（如 "2023-01-01T00:00:00Z"），且仅用于说明原因，不影响逻辑。
使用场景：修复严重 bug 后发布 v1.2.3，但发现 v1.2.0–v1.2.2 存在 panic 风险，需引导用户跳过。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 单个版本：
retract v1.2.0 - 连续区间：
retract [v1.2.0, v1.2.2]（闭区间，包含两端） - 带理由注释（非必需，但推荐）：
// v1.2.0–v1.2.2: causes data race in concurrent use - 错误写法：
retract v1.2.*、retract master、retract "2023-01-01"（缺时分秒和时区）
为什么 go.sum 不变，且 retract 不影响构建缓存
retract 是模块元数据层面的提示，不是构建过程的过滤器。Go 工具链在解析依赖图时才应用 retract 规则，而 go.sum 记录的是已下载模块的校验和——只要那个版本曾被拉取过，它的记录就保留。
性能 / 兼容性影响：无运行时开销，也不改变 go build 行为；但若下游项目未 go mod tidy，仍可能间接依赖被 retract 的版本（尤其在 replace 或 require 显式指定时）。
-
go mod graph | grep v1.2.1可验证是否还在依赖图中 - 若某依赖强制
require v1.2.1，即使你 retract 了，它仍会被选中（除非上游也更新自己的 retract） - CI 中建议加
go list -m -u -f '{{.Path}} {{.Version}}' all检查是否意外包含被 retract 版本
真正想“下架”旧版？得配合 tag 删除 + proxy 清理
retract 不等于删除。如果真要阻止他人获取某版本，唯一办法是：从代码仓库删掉对应 tag，并通知所用 GOPROXY 清除缓存（如 Goproxy.cn、JFrog 等需手动 purge）。
但多数情况没必要——retract 已足够传达意图。容易被忽略的是：很多团队误以为 retract 后 run go get example.com/mymod@latest 就不会拿到 v1.2.1，其实 @latest 仍可能返回它，除非 v1.2.3 已发布且满足 semver 规则。
- retract 后务必发布一个新版本（哪怕只是 v1.2.3+incompatible），否则
@latest会卡在最后一个未被 retract 的版本上 - 私有模块若用
go install直接装二进制，retract 完全无效——它只作用于go mod依赖解析 - GitHub/GitLab 上删 tag 是不可逆操作，切勿在未同步通知所有协作者前执行
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
