根本原因是Composer在Monorepo中默认反复解析所有packages/*/composer.json参与SAT求解，path仓库越多、宽泛约束越广、插件越多，I/O与逻辑开销叠加导致依赖树层级被撑开。
Monorepo里为什么依赖树越拉越深？
不是包太多，是Composer默认把所有packages/*下的composer.json全当远程源反复解析——哪怕你只改了packages/utils，它仍会扫描packages/api-client、packages/db-layer的约束并参与SAT求解。path仓库越多，I/O+逻辑叠加越重，依赖树层级自然被撑开。
常见现象：composer show -t .输出动辄嵌套8层以上，psr/log在3个不同深度重复出现，但实际安装版本不一致；composer why --tree溯源时看到your-project-name dev-main出现在第6层，说明顶层require没管住传递链。
- 确认是否真由path仓库引发：临时注释掉根
composer.json中repositories里的"type": "path"块，再跑composer show -t .，对比层级深度 - 检查子包是否误用宽泛约束：比如
"acme/core": "^1.0 || ^2.0"会让Composer保留两套候选版本，直接增加树宽 - 禁用
fxp-asset插件（如果没用bower/npm资产），否则每个path包都会触发额外HTTP校验，拖慢解析节奏
怎么让composer show -t只显示真正需要的路径
composer show -t不是“过滤器”，而是快照读取器——它只反映vendor/和composer.lock当前状态。想精准收缩依赖层级，必须先控制安装范围，再查树。
日常开发时，别在根目录跑composer install，进具体包目录执行：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
cd packages/utils && composer install --no-install --no-autoloader：只生成vendor/autoload.php，不 symlink 其他包，避免把packages/api-client的依赖也拖进来 - CI构建单个包时，加
--no-dev和--lock：例如composer install --no-dev --lock --no-interaction，跳过dev依赖解析，且强制按lock文件还原，不重算图 - 查某包真实上游链路：用
composer why --tree acme/core，而不是composer show -t acme/core——前者能穿透间接依赖，后者只展它自己的require列表
根composer.json里哪些配置会偷偷加层级
很多团队把config当万能开关，却不知道某些字段会让Composer主动“拓宽”依赖图。
-
"minimum-stability": "dev"：即使没显式require dev包，也会让Solver考虑dev-master等不稳定候选，大幅增加版本组合数 -
"prefer-stable": true本身不加层级，但如果配合"^1.0"这种宽松约束，反而让Solver优先选稳定版的同时保留大量候选分支 -
"platform": {"php": "8.3"}写错版本（如写成"8.3.0"）会导致Composer反复尝试兼容旧版约束，延长解析时间并可能引入冗余中间包 - 删掉
"installer-paths"和"archive"这类非必要字段——它们不参与依赖计算，但增大JSON体积，拖慢整个composer.json加载
私有包引用时如何避免“一层套一层”
Monorepo里最隐蔽的层级膨胀点，是子包之间互相require本地path包，形成环状或网状引用。比如packages/utils require packages/core，而packages/core又 require packages/utils，Composer会强行展开所有路径直到超限。
- 强制用
replace替代require：在packages/core/composer.json里写"replace": {"acme/utils": "*"}，告诉Composer“这个包我自有实现”，跳过解析其依赖 - 拆分
type: library和type: metapackage：把纯工具类包设为library，把组合多个包的“壳包”设为metapackage，后者不带autoload，天然不参与类加载链 - 禁止跨
packages/目录的PSR-4映射：根composer.json里"autoload"只映射apps/和公共命名空间，子包的src/路径由各自composer.json管理，避免autoload注册顺序混乱导致隐式依赖
真正难处理的不是层级数字本身，而是某个psr/container被5个不同版本同时require，却没人敢动——因为不确定哪个包在运行时真正调用它。这时候composer show --who psr/container比任何树形命令都管用。
