--working-dir（或-d）强制Composer在指定目录查找composer.json并执行命令，路径需含有效composer.json，不改变shell当前目录，但会与COMPOSER环境变量冲突。
用 --working-dir 指定 Composer 执行目录
Composer 默认在当前 shell 工作目录下读取 composer.json 并执行命令。想让它在别处运行，最直接的方式就是加 --working-dir 参数——它强制 Composer 切换到指定路径查找项目文件，不依赖你当前在哪。
这个参数本质是告诉 Composer：“把这儿当根目录来处理”，所有路径解析（比如 autoload、scripts、plugin 加载）都基于该目录，而不是你执行命令时所在的终端位置。
-
--working-dir必须指向一个含composer.json的有效项目目录，否则会报错Could not find composer.json - 路径可以是相对路径（如
--working-dir=../my-project）或绝对路径（如--working-dir=/var/www/app） - 它不会改变 shell 的当前工作目录，只是 Composer 内部行为切换
--working-dir 和 -d 是一回事
-d 是 --working-dir 的缩写，完全等价，官方文档里也明确标注为 alias。日常写脚本或快速调试时用 -d 更省事。
composer install -d ./legacy-app composer update --working-dir=./legacy-app
上面两行效果完全相同。注意：不要混用，比如 composer install -d ./a --working-dir=./b，后者会覆盖前者，且 Composer 不报错，容易误判。
常见踩坑点：和 COMPOSER 环境变量冲突
如果你同时设置了环境变量 COMPOSER（用于指定自定义 composer.json 路径），它会优先于 --working-dir 生效。也就是说：
-
COMPOSER=custom.json composer install -d ./project→ Composer 会尝试在当前目录找custom.json，而不是去./project下找默认的composer.json - 想确保
--working-dir生效，要么 unsetCOMPOSER，要么显式设为默认值：COMPOSER=composer.json composer install -d ./project
这种组合使用场景多见于 CI 脚本或容器内多项目构建，容易因环境变量残留导致命令行为不一致。
替代方案：cd 进目录再执行更可靠？
有人倾向用 cd /path && composer install，看似更“自然”。但实际在自动化流程中，--working-dir 更安全：
- 避免 shell 当前目录状态污染（比如脚本中途被中断，后续命令仍在错误路径）
- 无需担心权限问题（
cd失败会导致整条命令链中断，而--working-dir报错更明确） - 适合并行调用多个 Composer 项目，不用反复
cd切换
不过要注意：某些第三方插件（尤其是依赖 getcwd() 的 PHP 脚本）可能绕过 --working-dir 的影响，仍读取真实 shell 路径——这时候就得看插件实现是否尊重 Composer 的工作目录机制了。
