镜像加速无法解决 composer update 卡在 resolving dependencies 的问题，根源是 sat 求解器穷举依赖组合导致搜索空间爆炸；应通过 composer why-not 定位冲突链、replace/conflict 主动剪枝、--no-dev 分离环境等手段缩小求解空间。
为什么镜像换得再快，composer update还是卡在 Resolving dependencies
换国内镜像（如阿里云、腾讯云）只能加速下载，对“依赖树爆炸”毫无作用——卡住的根源是 SAT 求解器在穷举版本组合，不是网络慢。大型单体应用里常见几十个顶层包，每个都带松约束（比如 "^1.0"），加上 require-dev 里混着 PHPUnit、Infection、PHPStan 等工具，它们各自拉入不兼容的 symfony/*、sebastian/* 子树，搜索空间瞬间膨胀到千万级。
典型表现：CPU 占满、内存飙高、终端停在 Resolving dependencies 超过 5 分钟、日志里反复刷 Trying: monolog/monolog:v2.12.0 这类回溯尝试。
- 先跑
composer install --no-plugins --no-scripts -v，排除插件干扰，确认是否纯解析问题 - 加
-v后紧盯最后几行输出，重点看反复出现的requires和conflicts行，那是求解器卡死的锚点 - 临时删掉
composer.lock，跑composer update --dry-run，如果也卡住，说明锁文件本身已固化脆弱解，不是镜像问题
composer why-not 是定位冲突链最直接的切口
composer why-not 不是“为什么不能装”，而是“为什么当前项目状态不允许某版本共存”。它输出的是拒绝理由链，必须从底往上读——最后一行是你根 composer.json 的声明，往上每行末尾的 (required by ...) 是向上追溯的起点。
例如想升级 guzzlehttp/guzzle 到 ^7.5，但失败了，就运行：
composer why-not guzzlehttp/guzzle:^7.5
输出可能类似：
laravel/framework v10.32.1 requires guzzlehttp/guzzle ^6.5spatie/laravel-backup v8.4.0 requires laravel/framework ^10.0your-project requires spatie/laravel-backup ^8.0
这说明冲突不在 guzzle 本身，而在 laravel/framework 锁死了 ^6.5。此时别急着降级 Laravel，先查 laravel/framework 是否真需要旧版 Guzzle——去它的 composer.json 里看，很可能只是历史遗留约束。
- 如果输出里出现
your-project，检查根composer.json的conflict字段或过于严格的require - 若
why-not返回空，说明该版本本身可安装，问题出在其他间接依赖上，此时配合composer depends --tree --max-depth=2 guzzlehttp/guzzle查枢纽节点 - 注意：它只反映当前
lock+vendor的约束快照，不能直接告诉你“该降级哪个包”——要解，得对那个包再跑一次why-not
不删包、不降级，靠 replace 和 conflict 主动剪枝
大型单体应用常有“必须用 PHP 7.4”或“不能动某核心 SDK”的硬约束，升级底层包不现实。这时 replace 和 conflict 不是妥协，而是告诉求解器：“这些路径不用试了”，直接跳过无效搜索。
例如你确认所有代码已适配 psr/log v3，就在根 composer.json 加：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
"replace": {"psr/log": "3.0.0"}
Composer 就不再尝试安装 v1.x 或 v2.x，大幅收窄空间。
再比如已知 aws/aws-sdk-php v3.200+ 和某个支付 SDK 冲突，就封杀它：
"conflict": {"aws/aws-sdk-php": ">=3.200.0"}
求解器看到这条，会立刻排除所有匹配版本，避免在死路上浪费时间。
-
replace是彻底替换，适用于你有自研实现或已通过其他方式提供能力 -
provide更轻量，只声明“我提供了某接口”，如"provide": {"psr/log-implementation": "1.0"}，适合让其他包跳过拉取monolog - 慎用
dev-main：它强制走不稳定分支，求解器无法预判兼容性，会让搜索空间指数级膨胀 - 宽泛约束如
"^1.0 || ^2.0 || ^3.0"等于主动放弃剪枝机会，应收紧为"^3.0"或明确锁定已验证版本
CI/CD 和本地开发环境要分治，--no-dev 不是可选项
大型单体应用的 require-dev 常含数十个测试/分析工具，它们的依赖图和生产环境完全无关，却参与全局解析——这是递归爆炸的温床。CI 中必须用 composer install --no-dev --optimize-autoloader，本地开发也建议分离。
如果某个 dev 包（如 infection/infection）持续引发冲突，又不能移除，可用 config.platform 做虚拟约束：
"config": {"platform": {"infection/infection": "0.27.0"}}
这样它不真实安装，只提供版本锚点，避免搅乱主依赖链。
-
--no-dev必须放在-t前面，否则被忽略：composer show --no-dev -t . - 删掉 autoload 里无用条目，如
"docs/": ["docs/"]或"tests/": ["tests/"]，classmap 白扫数百文件会拖慢dump-autoload - CI 中禁用
--with-all-dependencies，改用精确更新：composer update guzzlehttp/guzzle --with-dependencies
真正麻烦的从来不是“怎么装”，而是“求解器不知道哪些路不该走”。所有命令和配置，本质都是在给它画边界——边界越清晰，爆炸越难发生。
