这是典型的大小写路径冲突：Go模块路径大小写敏感，但macOS、Windows文件系统不区分大小写，导致本地复用错误大小写的目录而校验失败。
为什么 go get 报错 “unknown revision” 或 “module declares its path as … but was required as …”
这是典型的大小写路径冲突：Go 模块路径是大小写敏感的，但某些文件系统（如 macOS 默认的 APFS、Windows 的 NTFS）对目录名不区分大小写。当你本地已有 github.com/SomeOrg/somelib，又执行 go get github.com/someorg/somelib（仅首字母小写），go mod 会尝试复用已存在的目录，但校验时发现模块声明的路径与请求路径不一致，直接拒绝加载。
常见触发场景：
- 从 GitHub 复制 URL 时手抖改了大小写（比如把
github.com/Azure/azure-sdk-for-go写成github.com/azure/azure-sdk-for-go） - 团队协作中有人提交了错误大小写的
import语句，你go mod tidy时被带偏 - 旧项目迁移时，
go.mod里残留了历史拼写变体
快速定位当前模块路径大小写是否一致
运行 go list -m all，逐行检查输出中是否有路径与实际仓库 URL 不匹配（尤其注意组织名、库名的首字母）。更直接的方法是看 go.mod 文件里的 require 行 —— 每一项都必须和对应 GitHub/GitLab 页面上显示的完整克隆路径完全一致（包括大小写）。
验证方式：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 打开浏览器，访问
https://github.com/<组织>/<仓库>，复制地址栏里显示的完整路径 - 对比
go.mod中对应行：如果require github.com/ORG/repo v1.2.3，但网页地址是github.com/org/repo，这就是问题源头 - 不要依赖本地
vendor/或pkg/mod/目录名来判断 —— 它们可能因历史操作已“脏”
强制重置并统一为正确大小写的模块路径
不能只改 go.mod 然后 go mod tidy，因为缓存和本地 checkout 可能仍保留旧路径。必须清掉三处：
- 删掉
go.mod中错误大小写的require行（或整行替换成正确拼写） - 删除
pkg/mod/cache/vcs/下对应仓库的整个缓存目录（路径含错误大小写，例如github.com/azure→ 改成github.com/Azure后要删pkg/mod/cache/vcs/https---github.com-azure-*） - 删除
pkg/mod/github.com/下对应模块的版本目录（如pkg/mod/github.com/azure/azure-sdk-for-go@v67.0.0+incompatible）
做完以上再执行 go mod tidy -compat=1.18（加 -compat 避免因 Go 版本差异触发额外校验）。如果仍失败，加 -v 查看具体卡在哪一步。
CI/CD 和多人协作中如何预防
大小写冲突在本地可能“凑合能跑”，但 CI 流水线（Linux 环境）一定会失败。预防的关键不是靠人眼检查，而是让工具提前拦截：
- 在
.gitlab-ci.yml或GitHub Actions的 workflow 里，加一步：go list -m all | grep -i "github.com.*[a-z][A-Z]\|github.com.*[A-Z][a-z]"—— 这类混合大小写路径极大概率是错的 - 用
gofumpt -w .或goimports -w .统一格式后，再人工扫一遍import语句里的路径，确保和官方文档示例完全一致 - 禁止直接
go get github.com/xxx，一律用go get <完整导入路径>（即代码里实际import的那串字符串），避免中间转换出错
最麻烦的不是修复，而是某天突然发现 go.sum 里混着两个不同大小写的同一模块哈希 —— 那说明已经有多个分支在用不同拼写，合并前必须先对齐，否则 go mod verify 会静默失败。
