必须用--working-dir（或-d）指定子目录，否则Composer只在当前shell工作目录找composer.json，不递归扫描；-d仅改变Composer查找配置的路径，不影响PHP的getcwd()。
必须用 --working-dir（或简写 -d）指定子目录，否则 Composer 根本找不到 composer.json，直接报错退出。
为什么在子目录执行 composer install 会失败
Composer 默认只在当前 shell 工作目录下找 composer.json。如果你人在项目根目录，而想装 packages/foo 里的依赖，直接运行 composer install 就会提示：Command "install" is not defined. 或 Could not find a composer.json file —— 它压根没去子目录里看。
这不是路径拼写问题，是设计如此：Composer 不会递归扫描子目录，也不自动识别 monorepo 结构。你得明确告诉它“去哪干活”。
composer install -d packages/foo 的实际行为
这个命令不会改变你的 shell 当前路径，也不会影响 PHP 运行时配置，它只做三件事：
- 检查
packages/foo/composer.json是否存在且可读 - 把
packages/foo/当作项目根目录，加载其中的vendor/、composer.lock和 autoloader 配置 - 所有输出日志（包括警告、错误、包下载路径）都隐含上下文：「操作发生在
packages/foo」
示例：
composer install -d packages/core --no-interaction
等价于手动执行：cd packages/core && composer install --no-interaction && cd -，但更安全——不依赖 cd 成功，也避免因上一条命令失败导致后续操作跑偏。
常见踩坑点：路径、权限与上下文
这些错误几乎都源于对 -d 作用范围的理解偏差：
-
-d后面的路径必须是**包含有效composer.json的目录**，不能是文件，也不能是空目录；写成-d packages/foo/和-d packages/foo效果一样，但建议去掉末尾斜杠，避免某些 shell 环境解析异常 - 相对路径（如
-d packages/bar）是相对于**执行命令时的 shell 当前工作目录**，不是脚本所在目录；CI/CD 中推荐优先用绝对路径，比如-d "$GITHUB_WORKSPACE/packages/bar" - 某些自定义
scripts或插件钩子（如post-install-cmd）内部可能调用getcwd()，此时它们拿到的是 shell 当前路径，不是-d指定的路径 —— 这类逻辑需要额外适配，不能默认认为所有 PHP 代码都感知-d -
-d对composer global命令无效，它只作用于项目级命令（install、update、dump-autoload等）
批量处理多个子目录的可靠写法
在 monorepo 或微服务目录结构中，别用 cd + 循环，直接用 -d 配合 shell glob：
for dir in packages/*; do [ -f "$dir/composer.json" ] || continue composer install -d "$dir" --no-interaction --quiet done
关键点：
- 先用
[ -f "$dir/composer.json" ]排除非项目目录（比如packages/.git或临时构建产物） -
--quiet抑制成功输出，让日志聚焦在错误上；--no-interaction防止卡住 - 所有命令都在同一 shell 上下文中执行，路径变量稳定，无需
pushd/popd
真正容易被忽略的，是 -d 并不改变 PHP 进程的 getcwd() 返回值 —— 如果你写的自定义脚本或插件里硬编码了相对路径操作，它依然会按 shell 当前路径走，和 -d 无关。
