换镜像不加速sat求解，卡在“resolving dependencies”是因约束过宽、dev分支混用或require-dev冲突导致本地暴力回溯；应优先用composer why-not定位阻断链、收紧版本约束、禁用xdebug、清理缓存并设minimum-stability为stable。

用国内镜像源本身不提升更新逻辑的效率，它只加速下载环节；真正影响批量更新成败和耗时的，是包名指定方式、--with-all-dependencies的使用时机、以及是否跳过composer outdated这一步。

为什么换镜像后 update 还是卡在 SAT 求解

镜像源只管 packagist.org 元数据和 zip 包的下载速度，不影响 Composer 内部的依赖求解（SAT 算法）。当你执行 composer update monolog/monolog guzzlehttp/guzzle 时，卡住的地方是版本约束冲突分析，不是下载慢。

• 常见错误现象：composer update 命令长时间无响应，光标停在 “Loading composer repositories with package information…” 后面不动
• 真实原因：项目中存在多个互锁约束（如 "php": ">=8.1.0" + "laravel/framework": "^9.0" + "spatie/laravel-ray": "^1.29"），Composer 需反复回溯尝试组合，尤其加了 --with-all-dependencies 后搜索空间指数级增长
• 性能影响：依赖树深度 >5、约束数 >15 时，SAT 耗时可能从 2 秒飙升到 40 秒以上；腾讯云/阿里云镜像对此无优化作用
• 可缓解动作：composer update --dry-run 先预判是否卡住；或临时删掉 require-dev 中非必要包（如 phpunit/phpunit）再试

批量更新前必须跑 composer outdated

凭记忆列包名或靠 composer show 列出全部已安装包，都会漏掉安全修复和小版本补丁。只有 composer outdated 能反映当前 composer.json 约束下“实际可升”的范围。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• composer outdated --direct：只看 require 和 require-dev 中显式声明的包，优先处理这些
• composer outdated --minor-only：过滤掉带 ! 的主版本跃迁项，适合日常维护
• 输出里带 ! 的行（如 symfony/console 5.4 → 6.0 !）必须人工查 CHANGELOG，不能直接塞进 update 命令
• latest 列不可信：它只表示 Packagist 当前稳定版，不校验是否兼容你的 PHP 版本或已有扩展（比如 ext-gmp 缺失时，ramsey/uuid v4.7.5 就会静默失败）

composer update 后跟多个包名的实操细节

这是最常用、最可控的批量更新方式，但包名格式、声明状态、版本锁定三者任一出错，命令立即失败。

• 包名必须完整且大小写敏感：monolog/monolog ✅，monolog ❌，Monolog/monolog ❌
• 必须已在 composer.json 的 require 或 require-dev 中声明，否则报错：Package monolog/monolog is not required in your composer.json
• 若该包被锁死（如 "monolog/monolog": "2.9.0"），update 不会升级它——得先改成 "^2.9" 或删掉具体版本号再提交
• 临时升大版本只能改约束：写 composer update monolog/monolog:^3.0 ✅，但漏掉冒号（monolog/monolog^3.0）会报错
• 空格分隔，不加引号、不用逗号：composer update monolog/monolog guzzlehttp/guzzle symfony/console ✅

什么时候必须加 --with-all-dependencies

不加这个参数时，composer update vendor/name 只更新目标包本身及其直系子依赖；间接依赖（如被 laravel/framework 拉进来的 symfony/http-foundation）可能卡在旧版，导致运行时报 Class not found 或 Method not exists。

• 典型场景：升级 laravel/framework 或 symfony/console 这类框架级包，必须加 --with-all-dependencies
• 它不会动无关包（如 phpunit/phpunit），但会重算整棵子树，包括 nesbot/carbon、symfony/routing 等
• 仍受 composer.json 约束限制："laravel/framework": "^9.0" 绝不会升到 v10，哪怕远程已有 v10.2
• 容易踩的坑：误用 --with-dependencies（只升直系）代替 --with-all-dependencies（穿透整棵树），结果类型不匹配却查不出原因

真正拖慢批量更新的从来不是下载速度，而是没做 composer outdated 就盲目列包名、没确认包是否被锁死、或该加 --with-all-dependencies 却没加——这些错误在 CI 流水线里会被放大，一次失败就得重跑整个构建。