Go模块路径必须与实际导入路径一致，否则go get会失败；修复需同步更新go.mod的module声明、所有import语句、打新tag；自定义域名需支持HTTPS+go-get元标签或replace临时方案；大小写敏感路径应统一转为小写。
模块路径在 go.mod 里写错了，但代码已推到 Git 仓库
Go 模块路径（module 行声明的字符串）必须与实际导入路径一致，否则其他项目 go get 时会失败或拉错版本。如果已经把代码推到了 https://git.example.com/team/proj，但 go.mod 里写的是 module github.com/olduser/proj，这就是典型不一致。
修复方式不是改远程 URL，而是统一模块路径和导入约定：
- 先用
go mod edit -module new.example.com/team/proj更新go.mod中的module行（注意：新路径要能被他人解析，比如支持 HTTPS 可访问、有对应 git 服务） - 确保所有内部 import 语句同步更新，例如
import "github.com/olduser/proj/pkg"→import "new.example.com/team/proj/pkg" - 提交并打新 tag（如
v1.1.0），旧 tag 不要复用 —— Go 不允许同一 tag 对应不同模块路径 - 若想保留旧路径兼容性，可在新仓库根目录放一个
go.mod声明旧路径，并加// +build ignore或重定向说明，但这只是临时提示，不能替代真实迁移
想用自定义域名但没有公网 Git 服务
模块路径写成 module mycorp.internal/lib 看似方便，但 go get mycorp.internal/lib 会失败：Go 默认只认 HTTPS + Git 协议，且要求域名可解析、服务可响应 GET /.well-known/go-mod 或提供 go-get=1 元标签。
可行方案只有两个：
立即学习“go语言免费学习笔记（深入）”；
- 用
replace在依赖方的go.mod中硬绑定本地路径：replace mycorp.internal/lib => ./internal/lib
（仅限开发，不可提交到公共仓库） - 部署最小化 Go module proxy：哪怕只是 Nginx 返回固定 JSON（
{"Version":"v1.0.0","Time":"2024-01-01T00:00:00Z"}）并配好go-importmeta 标签，就能让go get正确跳转到你的私有 Git 地址
GitHub 迁移后模块路径没变，但 go get 报 404
常见于从 github.com/user/repo 迁移到 github.com/org/repo，但 go.mod 没改，且原 user 账号已删 —— 此时 go get github.com/user/repo@v1.2.3 会因 repo 不存在而失败，即使 tag 还在。
根本原因不是路径“不一致”，而是 Go 的 checksum database（sum.golang.org）已记录该路径下所有版本的哈希值，一旦路径下无对应代码，校验即失败。
必须处理的点：
- 不能只改
go.mod；必须用新路径发布全新版本（如v2.0.0），并确保新路径能被go list -m -json正常解析 - 旧版本无法“复活”，用户若强制
go get github.com/user/repo@v1.2.3，只能通过GOPRIVATE=github.com/user/repo绕过 checksum 校验（不推荐） - GitHub 仓库设置里的 “Transfer ownership” 功能不会自动重定向
go get请求，它只对网页跳转有效
模块路径含大写字母或下划线，go build 报错
Go 规范要求模块路径是合法的 Go 包导入路径，必须满足：^[a-zA-Z0-9._-]+$，且不能以数字开头，也不能含 Unicode 字符。但更隐蔽的问题是大小写敏感性。
例如 module MyCorp.com/lib 看似合法，但实际会导致：
-
go build在 Windows/macOS 上可能成功（文件系统不区分大小写），但在 Linux CI 上失败 - Go 工具链内部用小写路径做缓存键，大小写混用会触发重复下载或版本混乱
- 第三方代理（如 proxy.golang.org）强制将模块路径标准化为小写，导致校验失败
正确做法是全部转为小写，并避免缩写歧义：mycorp.com/lib 比 MyCorp.com/lib 安全得多。
