Composer卡住主因是SAT求解器暴力穷举版本组合，宽泛约束、require-dev冗余、PHP版本不匹配及过时插件加剧搜索爆炸；用composer why-not定位冲突，replace和conflict可主动剪枝。
Composer 卡在 Resolving dependencies 不是网络问题，也不是服务器卡顿，而是 SAT 求解器正在暴力穷举所有可能的版本组合——树越深、约束越松、require-dev 越多，搜索空间就呈指数级膨胀。
为什么 composer update 会卡住或超时
根本原因不是“包太多”，而是求解器找不到剪枝依据。当出现以下情况时，解析时间会急剧上升：
-
"monolog/monolog": "^1.0"这类宽泛约束，等价于允许 1.0.0 到 1.999.999 的任意版本，极大增加组合数 -
require-dev中混入多个测试工具（如phpunit/phpunit、nikic/php-parser），它们各自携带一套不兼容的symfony/*或sebastian/*子依赖 - 本地 PHP 版本（如 8.2）与
composer.json中"php": "^8.0"表述不匹配，导致求解器反复排除不兼容包 - 启用了已过时的插件（如
hirak/prestissimo），干扰依赖图构建逻辑
composer why-not 是定位冲突源头的第一步
报错里写的 “Your requirements could not be resolved” 只是结论，不是根因。composer why-not 才是真正告诉你“谁在挡路”的命令：
- 运行
composer why-not laravel/sanctum:^3.0，输出会明确指出：某包要求guzzlehttp/guzzle:^6.5，而laravel/sanctum:^3.0要求guzzlehttp/guzzle:^7.2—— 冲突点瞬间锁定 - 如果
why-not返回空，说明该版本本身可安装，问题出在其他间接依赖上，此时应配合composer depends --tree --max-depth=2 guzzlehttp/guzzle查枢纽节点 - 注意：
composer why只查已安装版本的来源；若目标包尚未装上，why-not才是唯一可靠入口
不删包、不降级，如何收窄依赖树
核心思路是“提前告诉求解器哪些路径不用试”，而不是等它跑完再人工干预：
- 在根
composer.json的replace字段中显式声明："psr/log": "3.0.0"（前提是代码已适配），求解器将跳过所有psr/log的其他版本尝试 - 用
conflict封杀已知互斥组合，例如："conflict": {"aws/aws-sdk-php": "，避免旧版 SDK 被任何子依赖悄悄拉入 - 设置
config.platform硬编码环境信息："php": "8.2.10"、"ext-zip": "1.20.0"，跳过运行时探测，减少无效排除分支 - CI 中禁用
--with-all-dependencies，改用精确更新：composer update guzzlehttp/guzzle --with-dependencies
依赖树可视化时最易忽略的关键细节
composer show --tree 默认不显示版本号，也不标出同一包在不同路径下的约束差异——这是绝大多数人误判层级关系的根源：
- 缩进 ≠ 控制权：
laravel/framework下缩进出现symfony/console，不代表前者控制后者版本；真正在定版本的是composer why symfony/console输出的第一行顶层依赖 - 加
--no-dev后再执行composer show --tree | grep -A 2 -B 1 "package/name"，比扫全量树快且准 - 真正危险的是“同名包被不同约束拉入却未标出版本冲突”，比如
monolog/monolog在路径 A 被要求^1.26，在路径 B 被要求^2.0，但show --tree全程只写包名，不写约束
