Composer的--working-dir选项可指定命令执行目录，无需切换当前路径。例如在project目录下运行composer install -d api即可对子目录操作；支持批量管理多个项目，如通过脚本循环执行composer update -d $dir；适用于CI/CD、Docker构建等自动化流程，在固定工作目录中精准指向目标路径；还可用于测试不同配置，如指向实验性composer.json文件验证依赖。其核心是解耦执行位置与操作目标，提升多项目或复杂结构下的灵活性和效率。
Composer 的 --working-dir（或简写为 -d）选项允许你指定 Composer 应该在哪个目录下运行，而不需要先切换当前工作目录。这个选项在多种场景下非常实用，能简化操作流程。
跨目录执行 Composer 命令
当你处于项目根目录之外，但仍想对某个子目录中的项目执行 Composer 操作时，可以直接使用 -d 指定路径。
例如，你的项目结构如下：
project/├── api/
│ └── composer.json
├── web/
└── shared/
你可以直接在 project 目录下运行：
composer install -d api这样就无需先进入 api 目录再执行命令。
批量管理多个 Composer 项目
如果你有多个基于 Composer 的子项目（如微服务、插件集合等），可以用脚本批量操作。
比如一键更新所有项目的依赖：
for dir in service-a service-b plugin-x; docomposer update -d $dir
done
这在 CI/CD 脚本或本地维护中特别高效。
与构建或部署脚本集成
在自动化流程中，往往需要在特定路径运行 Composer，但主脚本的工作目录是固定的。
使用 -d 可确保命令始终作用于目标目录，避免因路径问题出错。
常见用例包括：
- 部署时在 release 目录执行
composer install --no-dev -d /var/www/html/releases/2025 - Docker 构建过程中从项目外调用 Composer
- CI 中并行处理多个 PHP 模块
临时测试不同配置
你可以用 -d 指向一个测试用的 composer.json 文件，尝试不同的依赖组合而不影响主项目。
例如：
composer install -d ./experiments/laravel-11-test方便进行版本升级预演或组件验证。
基本上就这些。--working-dir 的核心价值是解耦“执行位置”和“操作目标”，让命令更灵活，尤其适合自动化和复杂项目结构。
