多模块项目中composer install必须按模块边界分层执行，禁用全局执行；每个模块需独立vendor目录和autoload路径，CI/CD须脚本化逐模块install并校验autoload.php存在。
composer install 在多模块项目里不是“能用就行”，而是必须按模块边界和部署阶段分层控制——否则 vendor 目录会混装、autoload 冲突、CI 构建失败。
多模块项目下 composer install 为什么不能全局执行
所谓“多模块”，常见于 monorepo 结构（如 Laravel + Admin 模块 + API SDK 模块共存），或微服务拆分后多个 PHP 子项目共目录。这时每个子模块往往有独立的 composer.json 和 composer.lock，但根目录可能没有。
- 在根目录直接跑
composer install：Composer 会报错No composer.json found in the current directory，因为没找到入口配置 - 在某个模块内执行，但未清理上一次残留的
vendor/：可能因 autoload 生成逻辑重叠，导致类找不到（Class XXX not found） - 所有模块共享一个
vendor/（比如用composer install --working-dir=module-a）：不同模块对同一包的版本要求冲突时，Composer 会拒绝安装，报错Your requirements could not be resolved
正确做法：按模块路径分别执行，且显式指定工作目录
不要 cd 进去再执行，而要用 --working-dir 参数隔离上下文。这是避免污染和复现性偏差的关键。
- 对模块 A：
composer install --working-dir=./modules/admin - 对模块 B：
composer install --working-dir=./packages/sdk - 加
--no-dev必须按模块判断：admin 模块上线需加，sdk 模块作为依赖库发布则不能加（否则测试代码不进 dist） - 若模块间有私有包依赖（如 sdk 提供了
acme/sdk，admin require 它），确保repositories配置在各自composer.json中，而非全局镜像覆盖
常见错误：autoload 冲突与 classmap 错乱
多个模块共用同一 autoloader（比如都写入根目录 vendor/autoload.php）时，composer install 会反复覆盖 vendor/composer/autoload_classmap.php，最终只保留最后一次生成的结果。
- 现象：模块 A 的类能加载，模块 B 的类提示
Class not found，即使vendor/里文件存在 - 根本原因：Composer 默认只为当前
--working-dir下的composer.json生成 autoload 映射，不合并其他模块 - 解法一（推荐）：每个模块保持独立
vendor/，通过 PSR-4 自动加载路径在应用启动时手动注册（如 Laravel 的composer.json中"autoload": {"psr-4": {"Acme\Sdk\": "packages/sdk/src/"}}） - 解法二：用
composer create-project初始化模块，再统一用composer config --global fxp-asset-plugin.enabled false等插件规避历史兼容问题（仅限旧项目迁移）
CI/CD 流水线中如何安全执行多模块 install
流水线不是本地开发，不能靠人工判断该进哪个目录。必须用脚本枚举模块并逐个 install，同时防止缓存污染。
- 先检查每个模块是否含
composer.lock：find ./modules -name "composer.lock" -exec dirname {} ; - 对每个路径执行：
composer install --working-dir=$path --no-interaction --no-dev -o --ignore-platform-reqs（--ignore-platform-reqs仅用于构建机 PHP 版本固定但 lock 文件声明宽松时） - 禁用全局缓存或清空缓存：
composer clear-cache，避免上一次构建的包被复用导致版本错乱 - 关键检查点：流水线末尾加
ls -la modules/*/vendor/autoload.php，确保每个模块都有自己的 autoload 文件
多模块项目的 composer install 不是命令熟练度问题，而是模块边界意识问题。最容易被忽略的是 autoload 路径未隔离和 CI 中未校验每个模块的 vendor/ 是否真实生成——这两个点一旦出错，故障现象极其隐蔽，只能靠日志里 require_once 的实际路径反推。
