Composer本身不支持跨项目统一调度，必须依赖Makefile等上层工具协调；它仅管理当前项目的composer.json和vendor/，对其他项目及JS/Python依赖完全无感。
Composer 本身不提供跨项目统一调度能力，必须靠上层工具协调。 它只管当前项目的 composer.json 和 vendor/，对其他项目目录、package.json 或 pyproject.toml 完全无感。所谓“统一负载调度”，本质是把 Composer 当成一个执行单元，而不是调度中心。
为什么不能直接用 composer install --all-projects
因为 Composer 没有这个命令，也不支持批量扫描目录或自动识别多个 composer.json。你看到的“多项目依赖统一管理”案例，背后全是 Makefile、npm script 或 CI workflow 在驱动：
- 执行顺序不可控：如果在
composer.json的scripts里写"post-install-cmd": "cd ../other-project && composer install"，失败时不会中断主流程，错误码也被吞掉 - 环境变量和工作路径容易错乱：子项目可能依赖不同的 PHP 版本或扩展，而
composer install不校验运行时兼容性 -
composer.lock冲突无法自动解决：两个项目 require 同一包但版本不兼容时，没有全局 resolver
推荐用 Makefile 做轻量级统一调度
Makefile 是目前最稳定、最透明、且无需额外运行时的方案。它不侵入任何项目，只负责按顺序调用各项目自己的 composer install，并暴露所有错误。
示例 Makefile：
install-all: \t@echo "→ Installing backend..." \tcd backend && composer install --no-interaction \t@echo "→ Installing admin-api..." \tcd admin-api && composer install --no-interaction \t@echo "→ Installing cli-tools..." \tcd cli-tools && composer install --no-interaction update-all: \tcd backend && composer update --no-interaction \tcd admin-api && composer update --no-interaction
关键点：
- 每个
cd && composer ...独立执行，任一失败即中止（make默认行为） - 不用改任何项目的
composer.json，不污染 vendor 结构 - 可配合
.env或PHP_IDE_CONFIG控制不同项目的 PHP 运行环境
CI/CD 中如何安全调度多 Composer 项目
GitHub Actions 或 GitLab CI 里，别用单个 job 跑所有 composer install。应拆分为独立 job，并显式声明依赖关系和缓存策略：
- 每个 job 对应一个子项目，使用
working-directory隔离路径 - 缓存单独配置：
composer-cache-backend、composer-cache-admin-api，避免互相污染 - 用
needs:显式定义执行顺序，比如admin-api必须等backend成功后才运行 - 禁止在 job 中用
run: cd xxx && composer install—— 改用working-directory: ./xxx，否则缓存路径会错位
最容易被忽略的一点：多项目共用同一份 composer.lock 是伪需求。每个项目应维护自己的 composer.lock，调度层只保证执行顺序和失败可见性。强行“统一版本”只会让某个项目因 minor 更新意外 break，而你根本查不到源头。
