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 元标签。

可行方案只有两个：

• 用 replace 在依赖方的 go.mod 中硬绑定本地路径：

  replace mycorp.internal/lib => ./internal/lib

  （仅限开发，不可提交到公共仓库）
• 部署最小化 Go module proxy：哪怕只是 Nginx 返回固定 JSON（{"Version":"v1.0.0","Time":"2025-01-01T00:00:00Z"}）并配好 go-import meta 标签，就能让 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 安全得多。