Composer 自动处理路径分隔符：统一用正斜杠 /，PHP 底层函数（如 realpath()）和 PSR-4 加载器天然兼容，无需手动转换；vendor/autoload.php 通过 __DIR__ 和 / 拼接确保跨平台稳定；唯一风险是 scripts 中硬编码平台专属 shell 命令。
Windows 和 Linux/macOS 的路径分隔符在 Composer 中怎么自动处理？
Composer 本身不直接处理路径斜杠转换，而是依赖 PHP 底层的 realpath()、dirname()、basename() 等函数，以及 PSR-4 自动加载器对 和 / 的兼容解析。PHP 7.4+ 在 Windows 上已原生支持用正斜杠 / 作为目录分隔符（如 vendor/autoload.php），Composer 的所有路径拼接逻辑都基于此。
- Composer 的
composer.json中所有路径字段（如autoload、autoload-dev、scripts的命令）统一使用正斜杠/，这是唯一被官方文档认可的写法 - 实际运行时，PHP 会把
/自动转为 Windows 下的（仅在内部系统调用层面，不影响代码逻辑） - 不要手动用
str_replace()或DIRECTORY_SEPARATOR改写 Composer 配置里的路径——它不是你写的运行时代码，而是声明式配置
vendor 目录路径在不同系统下会出错吗？
不会。Composer 将 vendor/ 路径写入 vendor/autoload.php 时，已通过 <strong>DIR</strong> + 相对路径方式固化，不依赖绝对路径或斜杠类型。例如生成的 autoload 文件里常见这一行：
require_once __DIR__ . '/composer/autoload_real.php';
-
<strong>DIR</strong>返回的是当前文件所在目录的标准化路径（Windows 下也是C:/project/vendor这种格式，不含反斜杠） -
require_once对路径中的/兼容性极好；即使你在 Windows 写成<strong>DIR</strong> . 'composerutoload_real.php'，PHP 也能识别，但没必要 - 唯一可能翻车的点：你在
scripts里写了硬编码的 shell 命令，比如"post-install-cmd": "cp config/.env.example .env"——这在 Windows 默认 shell（cmd.exe）下会失败，应改用copy或切到bash（需额外配置）
PSR-4 自动加载路径映射为什么跨平台没问题？
因为 PSR-4 映射的是命名空间前缀 → 目录路径的规则，而 Composer 的 autoloader 在注册时，会把配置中写的路径（如 "App": "src/"）传给 PHP 的 spl_autoload_register()，后者最终调用 file_exists() 和 include。这些函数在各平台均接受正斜杠。
-
"App": "src/"中的src/是相对路径，由getcwd()拼接，而getcwd()返回的路径已标准化（Windows 下也是C:/project） - 如果你误写成
"App": "src\"（双反斜杠），Composer 会报Invalid argument supplied for foreach()或直接跳过该映射，不加载类 - Composer 2.x 开始对路径做了更严格的 normalize（调用
ComposerUtilFilesystem::normalizePath()），所以哪怕你写了混合斜杠，也会被统一规整
CI/CD 中跨平台构建失败，大概率卡在哪？
不是路径斜杠问题，而是脚本执行环境错配。典型表现：本地 Windows/Mac 能跑通，GitHub Actions（Linux）或 GitLab CI（Docker）报 Class not found 或 Command not found。
- 错误常发生在自定义
scripts里用了平台专属命令：比如"test": "phpunit"在没装全局 phpunit 的 Linux 容器里失败，应改为"php vendor/bin/phpunit" -
composer install时加了--no-scripts或--classmap-authoritative，导致某些平台相关初始化没触发 - Windows 用户提交了带
composer.json，Linux 下解析可能出错（罕见但真实存在），可用git config --global core.autocrlf input预防
路径斜杠本身早不是障碍，真正卡住人的，永远是那些「以为自己在写跨平台配置，其实悄悄绑定了某个 shell 或扩展」的操作。
