go get 报错“module not found”通常因仓库重命名导致，需手动更新 go.mod 路径、import 语句，并用 replace 临时桥接或 gofmt -r 批量修正；直连验证新路径有效性并核对语义兼容性。
go get 时提示 module github.com/old/repo not found
这是最典型的症状：你本地 go.mod 里还写着旧路径，但远程仓库已从 github.com/old/repo 重命名为 github.com/new/repo，Go 工具链无法自动跳转，直接报错。
根本原因不是 Go 不支持重定向，而是 go get 默认只查 GOPROXY（如 proxy.golang.org），而代理缓存的是旧路径的模块快照；即使源站加了 HTTP 301，代理也不转发重定向给客户端。
- 别指望
go get -u自动修复——它只会按go.mod里的路径去拉，不会探测重命名 - 手动改
go.mod中的路径只是第一步，后续所有 import 语句也必须同步更新，否则编译失败 - 如果模块有 v2+ 版本，新路径很可能对应新 major 版本（比如
github.com/new/repo/v2），不能简单替换字符串
用 go mod edit -replace 临时桥接旧路径到新路径
在不立刻修改全部 import 的前提下，先让构建通过。这招适合中大型项目，需要分步迁移。
假设旧路径是 github.com/old/repo，新路径是 github.com/new/repo，执行：
立即学习“go语言免费学习笔记（深入）”；
go mod edit -replace github.com/old/repo=github.com/new/repo@v1.2.3
注意：@v1.2.3 必须指定一个存在的 tag 或 commit，不能写 @latest（go mod edit 不解析 latest）。
- 该命令只修改
go.mod，添加replace指令，不影响源码 - 如果新仓库已发布 v2+ 版本，应使用
github.com/new/repo/v2@v2.0.0，且确保 import 语句也带/v2 -
replace是临时方案，CI 环境若禁用 replace（如设置GONOSUMDB或私有 proxy 规则），会失效
批量修正 import 路径：用 gofmt -r 或 sed + 手动验证
replace 只解决构建，不解决代码可维护性。必须把源码里所有 import "github.com/old/repo" 改成新路径。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
推荐优先用 Go 自带的重写能力（安全、跨平台）：
go fmt -r 'github.com/old/repo -> github.com/new/repo' ./...
如果模块有子包（如 github.com/old/repo/client），需单独处理：
go fmt -r 'github.com/old/repo/client -> github.com/new/repo/client' ./...
-
go fmt -r不修改未被go build引用的文件（比如测试文件里孤立的 import），得人工扫一遍 - 避免用全局
sed -i，容易误伤注释、字符串字面量或 vendor 内容 - 改完后务必运行
go mod tidy，清理旧路径残留，并检查是否引入了重复版本
验证新路径是否真正可用：绕过 GOPROXY 直连 fetch
有时新仓库虽已创建，但尚未打 tag 或未被 proxy 同步，go get 仍失败。此时要确认真实状态。
临时禁用代理，直连 GitHub 验证：
GOPROXY=direct go list -m -versions github.com/new/repo
如果返回空或 404，说明仓库不存在、私有未授权，或路径拼写错误（比如大小写不符——GitHub 路径区分大小写）。
- 私有仓库需配置
git config的 HTTPS 凭据或 SSH key，否则direct模式会卡在认证 - 若新路径存在但无符合要求的 tag（如只有
v0.0.0-xxx提交 hash），go get默认不接受，需显式指定 commit：go get github.com/new/repo@abcd123 - 别忽略
go.mod里require行末尾的// indirect标记——它可能掩盖真实依赖来源，导致你以为修好了，其实只是被间接引入
重命名后的模块路径变更，本质是契约断裂。工具能帮你跳转和替换，但没法替你确认语义兼容性。v1 和 v2 的 API 差异、breaking change 日志、甚至文档链接是否更新，这些都得人眼核对。
