大小写敏感带来的迁移问题
Windows 文件系统不区分大小写，Linux 区分：README.md 与 readme.md 在 Windows 上是同一个文件，在 Linux 上是两个。迁移中最典型的两类事故是：写到不敏感的文件系统上时同名文件互相覆盖；以及代码或配置里引用路径的大小写与实际文件名不一致，运行时找不到资源。
基本信息
| 差异来源 | Windows/macOS 默认不敏感，Linux 的 ext4/xfs 敏感 |
|---|---|
| 高发位置 | 静态资源、类路径、配置引用、脚本里的路径 |
| 检测手段 | 重名清单、rsync 演练模式、构建报错反查 |
| 风险动作 | 往 FAT/exFAT 等不敏感文件系统复制含重名的目录 |
| 处理原则 | 以实际文件名为准统一引用，源端先消歧 |
典型使用场景
- 从 Windows 开发环境迁到 Linux 后的资源加载失败
- 打包或解压过程中同名不同大小写文件互相覆盖
- 版本发布后静态资源 404，但文件看似都在
- 迁移到大小写不敏感的对象存储或 NAS 上出现文件丢失
- CI 在 Windows 上通过、在 Linux 上失败
排查与处理
排查与处理
find /data -type f | tr 'A-Z' 'a-z' | sort | uniq -d | head # 仅大小写不同的近似重名清单
ls -l /data/README.md # 引用与实际文件名核对
grep -rn 'assets/Logo.png' --include='*.java' . | head # 查找代码中的可疑引用
rsync -avn /data/ /backup/ | grep -iE 'collision|conflict' # 演练模式发现覆盖风险（-n 不实际写入）
git config --get core.ignorecase # 确认仓库是否忽略大小写
git mv Logo.png logo.png && git mv logo.png Logo.png # 仅改大小写时用两步改名
# 处理顺序：出清单 → 改名消歧 → 统一引用 → 再同步部署现象与指向
| 现象 | 可能原因 | 确认方式 |
|---|---|---|
| 构建报找不到资源 | 引用大小写与实际不符 | 按报错路径反查实际文件名 |
| 文件无故丢失 | 复制到不敏感文件系统被覆盖 | 检查目标文件系统类型 |
| 本地正常、CI 失败 | 开发环境不敏感 | 在 Linux 上用同一份代码构建验证 |
| 仓库改动识别不到 | Git 忽略大小写 | 用 git mv 分两步改名 |
「Windows 开发、Linux 部署」是大小写问题的高发链路：部署检查清单里应固定一项，对新增资源做一次引用与实际文件名的比对。
往 FAT/exFAT 的 U 盘或某些不敏感 NAS 上复制含重名的目录会直接覆盖文件且不报错：先消歧再搬，别把 U 盘中转当安全环节。