^2.0 解析为 >=2.0.0 && =2.5.0 &&
^2.0 和 ~2.5.0 的边界到底差多少
差一个数量级。不是“差不多”，是数学上完全不同的区间。^2.0 解析为 >=2.0.0 && ，覆盖整个 2.x 系列；而 <code>~2.5.0 是 >=2.5.0 && ，只允许修复级更新（2.5.0 → 2.5.9）。
常见错误现象：
- 以为
~2.5能装上2.6.0—— 实际被拒绝，连尝试都不会发生 - 在 PHP 8.2 环境写
^8.1，结果8.2.0被排除（因未显式声明8.2.*，^8.1不包含8.2.0） -
dev-main不参与 SemVer 边界计算，它靠 commit hash 匹配，composer/semver根本不处理这类值
为什么 composer update 卡在 “Resolving dependencies…”
这不是网络卡，是 SAT 求解器正在做逻辑推演：把每个包版本当布尔变量，把 require、conflict、platform 配置全转成 CNF 子句，搜索满足全部条件的一组赋值。
搜索爆炸的典型诱因：
- 同时
require多个大生态包（如 Laravel + Symfony + Doctrine），每个带几十个可选版本 -
composer.lock没删就改composer.json，求解器被迫以旧 lock 为起点做“最小变更”，反而锁死可行路径 -
config.platform.php设为"8.1.0"，但实际运行环境是8.2.5，大量合法版本被提前剪枝 - 混用稳定性标记：
"monolog/monolog": "dev-main"和"phpunit/phpunit": "^9.6"冲突，因后者要求 stable 版本
composer install 为什么秒出，而 update 要算半天
composer install 根本不跑求解器。它只校验 composer.lock 里的每个包版本是否仍满足当前 composer.json 中的约束——这个校验是 O(n) 的快速比对。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer.lock 不是缓存，是上一次成功求解输出的「已验证可行解」，包含精确版本、源类型、SHA256 校验和、依赖映射等完整快照。只要 lock 文件没坏、仓库元数据没变、平台配置一致，install 就永远快。
容易踩的坑：
- 改了
composer.json但忘了composer update，CI 上composer install依然装旧版本，且不报错 - 手动编辑
composer.lock后直接install，下次update会覆盖你的修改 - 删掉
composer.lock再install，会退化成一次不受控的update，哪怕你只是多敲了一个空格导致content-hash不匹配，也会触发警告甚至失败
如何真正看清谁在拉扯谁的版本
composer update --dry-run -v 是唯一能看清“谁在拉扯谁”的方式。它不改任何文件，却会把求解过程完整打印出来：哪些包被升级/降级、主版本号是否变化、有没有触发新的 conflict 提示。
其他关键命令：
-
composer why-not laravel/framework:11.0.0输出阻断链，末尾带(for xxx)的行即需调整的真实拦路包 -
composer show -t展示的是lock文件里真实锁定的结构，不是你composer.json里写的理想状态 -
composer show -t | grep "symfony/console"快速定位路径和锁定版本
边界效应最隐蔽的地方在于：同一个包在树中出现多次、版本不同，说明上游存在不兼容分支；看到 (replaced) 或 (provided) 标记，必须立刻查对应包的 composer.json，确认是否真能等价替代。
