上周同事小李上线新功能，本地测试好好的，一部署到服务器就报 404。查了半小时才发现，他引用的文件名是 Utils.js，而仓库里实际提交的是 utils.js。就因为这一个字母的大小写差异，整个页面直接挂了。
问题出在哪？
很多开发者用的是 macOS 或 Windows 系统，这两个系统的文件系统默认不区分大小写。你在本地写 import { helper } from './Config.js';，就算文件实际叫 config.js，也能正常运行。
但一旦代码推送到 Linux 服务器，问题就来了。Linux 文件系统是大小写敏感的，Config.js 和 config.js 被视为两个完全不同的文件。找不到模块？报错没商量。
Git 也会“掩盖”问题
更坑的是，Git 默认在某些系统上也不强制区分大小写。你把 README.md 改成 readme.md，Git 可能根本不会提示有变更。等别人从仓库拉代码时，文件名可能还是旧的，导致构建失败。
可以检查当前配置：
git config core.ignorecase如果输出 true，说明 Git 正在忽略大小写变化，这在跨平台协作时就是颗定时炸弹。
真实场景：团队协作翻车现场
有个前端团队，两人同时开发。A 在 Mac 上创建了 ApiService.ts，B 在 Linux 上拉代码后想重命名为 apiservice.ts。结果 Git 没识别出这是重命名，反而认为删了一个、新增了一个。合并时冲突频发，CI 流水线接连失败。
最后发现，不是代码逻辑问题，而是文件名大小写混乱导致模块解析失败。
怎么避免这类坑？
最简单的办法：统一规范。团队约定所有文件名一律小写，用短横线或下划线连接，比如 user-api-client.js 或 auth_utils.py。这样不管什么系统，都不会因为大小写出问题。
也可以在项目初始化时设置 Git 行为：
git config core.ignorecase false让 Git 严格对待大小写变化。配合 CI 脚本做文件名扫描，发现大小写混用时直接拦截提交。
另外，IDE 设置也很关键。开启“区分大小写”的文件搜索和自动补全，能在编码阶段就发现问题。
别让一个小写字母拖垮整个系统
看似无关紧要的命名习惯，往往在跨平台、跨系统时放大成严重故障。尤其是在自动化部署越来越普及的今天，本地能跑通不代表线上没问题。
从第一天就建立清晰的命名规则，比出事后再排查省心太多。