上周同事小李急匆匆跑来问我：‘我本地改好的文件，怎么推到仓库后线上还是老样子？’他一脸懵，我也替他纳闷。查了半天才发现，问题出在一个文件名上——他把 Header.vue 改成了 header.vue，本地开发环境没报错，但上线后页面直接 404。
问题根源：文件系统差异
这个问题的核心在于不同操作系统对文件名大小写的处理方式不一样。Windows 和 macOS（默认配置）的文件系统是大小写不敏感的，也就是说，Readme.md 和 readme.md 被认为是同一个文件。而 Linux 是大小写敏感的，这两个名字就是两个不同的文件。
大多数服务器和 CI/CD 环境用的是 Linux，所以你在 Windows 上开发时看不出问题，一旦部署就炸了。
Git 的“宽容”埋下隐患
更麻烦的是，Git 默认在 Windows 和 macOS 上也会忽略文件名的大小写变化。你把 About.vue 改成 about.vue，Git 可能根本不觉得这是个重命名操作，导致提交记录里啥也没变。
可以用下面命令查看 Git 当前的大小写设置：
git config core.ignorecase如果返回 true，说明 Git 正在“帮你”忽略大小写差异。这在协作开发中特别危险，尤其是多人跨平台开发时。
真实场景再现
想象一下：前端项目里有个组件叫 UserProfile.vue，某天有人想统一命名规范，改成 user-profile.vue。他在 Mac 上改完提交，CI 流水线跑着跑着报错了：找不到模块 user-profile.vue。原因是构建服务器是 Linux，原来的 UserProfile.vue 没删干净，新文件又不能覆盖旧名，结果两边都找不到。
怎么绕过这个坑？
最直接的办法不是靠系统或 Git 去猜，而是手动触发一次真正的重命名。比如你想把 AppHeader.js 改成 app-header.js，别直接改，分三步走：
git mv AppHeader.js temp_name.js
git mv temp_name.js app-header.js
git commit -m "rename file with case change"这样 Git 能明确识别出这是两次移动操作，不会因为大小写问题漏掉变更。
预防胜于补救
团队协作时，最好在项目初期就约定好命名规范，比如全部用 kebab-case 或 camelCase，并在 ESLint 或 Stylelint 中加上规则约束。还可以在 CI 脚本里加一步检查，扫描是否有仅大小写不同的文件名，提前报警。
另外，如果你用的是 VS Code，可以装个插件比如 Case Sensitive Rename，重命名时自动提醒你可能存在的大小写问题。
别让一个字母的大小写，毁了你一晚上的调试时间。