根本原因是Go模块路径大小写敏感而文件系统行为不一致：Windows/macOS文件系统不区分大小写，Linux严格区分；需统一修正go.mod中大写路径为小写、清理modcache并添加CI校验。
为什么 go mod download 会在 Windows/macOS 上成功，Linux 上却报错？
根本原因是 Go 模块路径大小写敏感，而不同文件系统行为不一致：Windows 和 macOS 默认文件系统（NTFS/HFS+）对路径大小写不敏感，Linux（ext4/xfs）严格区分大小写。当你在 Windows 上写 github.com/Sirupsen/logrus（首字母大写），go mod tidy 会记录这个路径；但推到 Linux 构建时，Go 尝试拉取该路径，而实际仓库已迁移到全小写的 github.com/sirupsen/logrus，导致 go mod download 失败，错误类似：module github.com/Sirupsen/logrus: reading github.com/Sirupsen/logrus/go.mod: 404 Not Found。
如何快速定位大小写不一致的模块路径？
别猜，直接查当前 go.mod 和实际依赖图中的路径差异：
- 运行
go list -m -f '{{.Path}} {{.Version}}' all | grep -i sirupsen，看输出是Sirupsen还是sirupsen - 检查
go.mod中require行：是否含大写首字母（如github.com/Sirupsen/logrus v1.8.1） - 执行
go mod graph | grep -i sirupsen，确认是否多个大小写变体共存（比如your/module github.com/Sirupsen/logrus@v1.8.1和some/dep github.com/sirupsen/logrus@v1.9.0同时存在）
修复步骤：统一路径 + 清理缓存
大小写问题不是“版本冲突”，而是路径解析失败，必须修正模块路径本身：
- 手动编辑
go.mod，把所有大写首字母的旧路径（如github.com/Sirupsen/logrus）替换成标准小写形式（github.com/sirupsen/logrus） - 执行
go mod tidy—— 它会重新解析依赖图，并用小写路径拉取最新兼容版本 - 删掉本地模块缓存避免残留：运行
go clean -modcache，否则go build可能仍尝试加载旧路径的缓存 - 验证：再跑一次
go list -m all | grep -i sirupsen，确认只出现小写路径且版本一致
CI/CD 和多平台协作中必须加的防护
单次修好不等于一劳永逸。只要团队有人在 Windows 上用 IDE 自动生成 import 或 go get，就可能再次引入大写路径：
- 在
.git/hooks/pre-commit或 CI 脚本里加校验：用grep -n '[A-Z]/' go.mod检查非法大写字母路径，失败则阻断提交 - 设置
GO111MODULE=on和GOPROXY=https://proxy.golang.org,direct（或国内镜像），避免因代理返回重定向导致路径被意外标准化 - 禁止直接
go get github.com/Sirupsen/logrus—— 始终用小写全量路径：go get github.com/sirupsen/logrus@latest
真正麻烦的不是改一行 go.mod，而是让所有人、所有环境、所有自动化流程都遵守同一套路径规范。大小写问题表面是技术细节，底层是协作契约。
