go模块仓库改名后需手动修复：用go mod edit -replace替换旧import path，或go1.22+用go mod migrate全量更新源码与go.mod，无法自动重定向。
go get 时提示 module github.com/old-org/repo not found
仓库改名后，旧 import path 的模块在 Go 中无法自动重定向，go get 会直接失败，而不是像 npm 或 pip 那样尝试跳转。Go 的模块系统严格依赖 import path —— 它不是 URL 别名，而是模块身份标识。
- Go 不会自动解析 GitHub 重定向（比如 301），
go get请求的是https://github.com/old-org/repo?go-get=1这类元数据端点，而改名后的仓库不提供旧路径的go.mod响应 - 如果项目里仍引用
github.com/old-org/repo，go mod tidy会卡在 checksum mismatch 或直接报not found - 不能靠
replace临时绕过 —— 它只影响构建，不解决go mod download阶段的 fetch 失败
用 go mod edit -replace 修复导入路径
必须显式告诉 Go：所有对旧路径的引用，实际应使用新路径的代码。这不是“别名”，而是强制重写依赖图中的模块地址。
- 执行：
go mod edit -replace github.com/old-org/repo=github.com/new-org/repo@v1.2.3
（注意：末尾必须带具体版本，不能是latest或分支名） - 若新仓库已发布 v2+ 版本且启用了语义化导入路径（如
github.com/new-org/repo/v2），则 replace 目标也必须匹配其module声明，例如：github.com/old-org/repo=github.com/new-org/repo/v2@v2.1.0 - 执行后检查
go.mod是否新增了replace行，并确认require中仍保留旧路径（这是正常现象，replace 就是为覆盖它）
批量替换多个旧路径时避免 go mod verify 失败
多个 replace 共存时，容易因 checksum 计算顺序或间接依赖冲突导致 go mod verify 报错，尤其当旧模块被其他未 replace 的依赖间接引入。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 先运行
go mod graph | grep old-org/repo，确认是否只有你控制的模块在引用它；若有第三方模块硬编码旧路径，就得联系对方发版修复，或 fork 后 patch 其go.mod - replace 后务必运行
go mod vendor（如有 vendor）再go build，因为replace不影响 vendor 目录内容，旧路径的代码可能仍残留其中 - CI 环境中要禁用
GOPROXY=direct，否则go mod download会跳过 proxy 缓存，直接请求已失效的旧仓库地址
长期维护建议：用 go mod migrate（Go 1.22+）替代手工 replace
Go 1.22 引入了 go mod migrate 命令，可自动扫描并重写所有源码中的 import 路径，比手动 replace 更彻底，但需谨慎使用。
- 它会修改所有
.go文件里的import "github.com/old-org/repo"为新路径，并同步更新go.mod中的require行 —— 这意味着你不能再兼容旧版本代码 - 运行前必须 commit 当前状态，因为它不区分“主模块”和“依赖模块”，可能误改 vendor 内第三方代码（尽管文档说跳过 vendor，实测仍有风险）
- 若项目同时被多个团队消费，migrate 后需同步通知所有下游，因为他们的
go.mod里旧 require 将不再有效
仓库改名不是纯运维动作，它本质是模块 identity 的变更。Go 的设计让这事没法静默过渡，要么全量迁移 import，要么长期靠 replace 维持 —— 两者都得动代码，没有“配置一下就好”的捷径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
