Composer 在大型项目中变慢、内存溢出、依赖冲突频发，根本原因是默认行为未适配大规模依赖图；通过调整 composer.json 配置（如 lock:true、prefer-stable:true）、运行时参数（--prefer-dist、--classmap-authoritative）及精准更新策略，可显著优化性能，无需换工具或重构。
Composer 在大型项目中变慢、内存溢出、依赖冲突频发，根本原因不是工具不行，而是默认行为没适配大规模依赖图。直接改 composer.json 和运行时参数就能明显改善，不需要换工具或重构包结构。
为什么 composer install 在大项目里卡在 “Resolving dependencies”
这是 Composer 7.4+ 默认启用的全新依赖解析器（SAT solver）在处理数百个包、多版本约束、平台配置差异时产生的指数级回溯。尤其当项目含大量 dev-master、@dev 或宽松约束（如 ^1.0 || ^2.0）时，解析时间从秒级升至分钟级。
- 临时跳过解析：加
--no-suggest --no-progress不解决根本问题，但能减少干扰输出 - 真正有效的是锁定解析范围：
composer install --prefer-dist --optimize-autoloader强制跳过源码安装和冗余 autoload 生成 - 更关键的是禁用动态解析：在
composer.json顶层加"config": {"lock": true}，确保不因本地platform配置差异触发重解析
composer update 内存溢出（Allowed memory size exhausted）
不是 PHP 内存设小了，而是新版 Composer 的依赖图构建过程在未限制包范围时会加载全部候选版本元数据到内存——尤其当你有 monolog/monolog、symfony/* 这类高版本密度包时。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 永远不要在根目录跑
composer update：改用composer update vendor/package-name --with-dependencies精确更新子树 - 提前过滤无关包：在
composer.json中设置"minimum-stability": "stable"和"prefer-stable": true，避免拉取大量dev-快照 - 对 CI 环境加硬限制：
COMPOSER_MEMORY_LIMIT=-1 composer update --dry-run先验证，再加--no-install跳过写入磁盘
autoload 生成慢且热加载失效（Laravel/Symfony 本地开发卡顿）
大项目常有数百个 PSR-4 命名空间，composer dump-autoload -o 生成的 vendor/composer/autoload_classmap.php 文件可能超 10MB，PHP 每次请求都要读取解析它。
- 改用静态映射 + 文件缓存：运行
composer dump-autoload --classmap-authoritative --apcu，让 autoloader 完全跳过文件存在性检查，并利用 APCu 缓存类位置 - 排除测试/开发专用代码：
"autoload-dev": {"exclude-from-classmap": ["tests/", "Tests/"]}，防止测试类污染生产 autoload - 如果用 Laravel，确认
APP_DEBUG=false时已自动启用--classmap-authoritative，否则手动在composer.json的scripts里绑定
最易被忽略的一点：大型项目中 composer.lock 文件本身是性能瓶颈。它记录了所有包的完整哈希与嵌套依赖路径，Git diff 和合并冲突极其频繁。别把它当黑盒——定期用 composer show --tree 抽样验证关键路径，比盲目信任 lock 文件更可靠。
