Composer autoloader 本身不规范化路径大小写，其映射严格按原始大小写生成；能否加载取决于文件系统与PHP的realpath解析行为，在大小写不敏感系统（如Windows/macOS）中可能“侥幸”成功，但在Linux生产环境易因路径大小写不一致而失败。
Composer autoloader 在大小写不敏感文件系统上如何做路径规范化？
Composer 的 ClassLoader 本身不主动“适配”大小写不敏感系统；它依赖 PHP 的 include / require 行为，而该行为由底层文件系统和 PHP 的 realpath 处理逻辑共同决定。关键点在于：Composer 生成的 autoloader 映射（如 vendor/composer/autoload_classmap.php）中，类名到文件路径的映射是**严格按 PSR-4/PSR-0 规则生成的原始大小写**，但最终能否成功加载，取决于 file_exists() 和 include() 在当前系统下的实际解析结果。
为什么 Windows/macOS 上 class A\B\C 有时能加载 a/b/c.php？
这不是 Composer 的功能，而是操作系统 + PHP 的副作用：
- Windows 和 macOS 默认使用大小写不敏感的文件系统（NTFS/HFS+/APFS）
- PHP 的
include在调用前会通过realpath()或类似机制尝试解析路径，若src/Controller/UserController.php实际存在，那么即使代码里写成src/controller/usercontroller.php，file_exists()也可能返回true - Composer 的
ClassMapGenerator读取文件时也受此影响：如果目录里有UserController.php，但你误建了usercontroller.php，它可能被扫入 classmap —— 但类名仍需匹配（PHP 类声明是大小写不敏感的，但命名空间和类名在 autoload 映射中是字符串键，区分大小写）
autoload_classmap.php 中的路径键是否大小写敏感？
是的，完全敏感。该数组的 key 是类的完整限定名（如 "App\\Controller\\UserController"），value 是对应文件的**绝对路径字符串**（如 "/var/www/src/Controller/UserController.php"）。这个路径字符串在生成时由 realpath() 标准化，但前提是文件存在且路径可解析：
return array(
'App\\Controller\\UserController' => $baseDir . '/src/Controller/UserController.php',
'App\\Model\\User' => $baseDir . '/src/Model/User.php',
);
如果开发机是 macOS，而你把文件命名为 usercontroller.php，但 composer dump-autoload 时它被识别并写入了映射，那后续 new UserController() 就会尝试加载那个小写的路径 —— 这在 Linux 生产环境大概率失败。
立即学习“PHP免费学习笔记（深入）”；
如何避免大小写陷阱导致部署失败？
根本解法不是靠 Composer 自动处理，而是统一开发与生产环境的行为：
- 开发时启用
composer install --no-dev后检查vendor/composer/autoload_classmap.php，确认所有路径中的文件名与磁盘实际大小写完全一致 - CI 流程中加一步校验：
find src/ -name "*.php" -exec basename {} \; | grep "[a-z]" | grep "[A-Z]"并对比类名声明（如class UserController）是否与文件名匹配 - 在 Linux 容器中开发（例如 VS Code Dev Container），从源头杜绝“侥幸通过”的路径
- 启用 PHP 的
opcache.validate_timestamps=0时尤其注意：OPcache 缓存的是 realpath，一旦路径大小写错，缓存会固化错误路径，重启 Web 服务也不生效
最常被忽略的一点：PSR-4 声明里的 psr-4 映射前缀（如 "App\\": "src/"）不参与文件系统查找，但 Composer 拼接出的完整路径（src/Controller/UserController.php）必须与磁盘上真实存在的路径逐字节一致 —— 这个“一致”在大小写敏感系统里就是硬性要求。
