Composer根本不会自动降级包，只升不降是设计原则；触发降级的唯一可靠方式是composer require monolog/monolog:2.9.2 --with-all-dependencies，它会重写composer.json、重算依赖图、更新lock文件并替换vendor文件，漏掉该参数易因子依赖不兼容而失败。
Composer根本不会自动降级包
它只升不降，这是设计原则，不是bug。当你看到composer update没把monolog/monolog从3.0.0拉回2.9.2，不是它“没算出来”，而是你没明确要求——^2.0约束下，3.0.0合法且更新，Composer 会直接跳过降级尝试。
真正触发降级的唯一动作是显式声明版本：用composer require monolog/monolog:2.9.2，它会重写composer.json、重算整个依赖图、更新composer.lock，并替换vendor/里的文件。漏掉--with-all-dependencies时，子依赖可能卡在不兼容状态，报错却不说清哪一层出问题。
- 直接改
composer.json里版本号再跑composer update，只在新约束允许范围内生效；如果旧composer.lock锁死了高版本，它可能完全无视你的修改 -
composer install永远按composer.lock复现，哪怕composer.json已改成更低版本 - 手动编辑
composer.lock是危险操作：下次install或update大概率覆盖，甚至因校验失败中断
冲突解决靠SAT求解器，不是优先级排序
Composer 没有“优先级协商”机制，它用布尔可满足性（SAT）求解器寻找一组同时满足所有require、conflict、platform约束的版本组合。所谓“谁先写谁优先”是误解——repositories数组顺序只影响元数据获取源，不影响版本选择逻辑。
当guzzlehttp/guzzle:^6.5和guzzlehttp/guzzle:^7.0共存时，求解器发现无交集，直接报错。它不会选6.x或7.x中的某一个，也不会按配置顺序“妥协”。输出里Root composer.json requires那行只是起点，真卡点往往藏在缩进最深的(required by myapp/sdk v2.1)或(conflict with php: ^8.2)里。
-
composer why-not guzzlehttp/guzzle:7.9.0输出要倒着读：最后一行是根需求，往上每行是阻断链上一级依赖 -
conflict字段是包自己写的硬规则，不是Composer加的限制；看到conflict with foo/bar (>=2.0)，得查谁把foo/bar拉进来，而不是删foo/bar -
config.platform.php参与求解，但只影响解析阶段；设成"7.4.33"后必须跟composer update --lock，否则composer.lock仍绑定PHP 8的包
私有仓库不生效？多半是"packagist": false没配
默认情况下，packagist.org是兜底源——哪怕你把它写在repositories第一位，只要没在composer.json顶层显式关掉，它就会插队到末尾匹配。结果就是：私有仓库声明了myorg/utils:2.1.0，但Composer还是从Packagist拉了1.8.0。
验证方式很简单：composer show -a myorg/utils看source字段输出的URL。如果没指向你的私有地址，八成是漏了"packagist": false，或者它被错写在repositories对象内部而非根层级。
-
"packagist": false必须是composer.json根对象的直接字段，不能嵌套 - 多个私有仓库共存时，顺序决定谁能被选中；
repositories数组第一个能返回元数据的仓库胜出，后面同名包版本不参与比较 -
type必须匹配：Satis/Toran用"type": "composer"，Git仓库用"type": "vcs"，类型错会导致元数据无法解析，直接跳过
降级后Class not found？autoload缓存没清
版本显示正确、vendor/里文件也替换了，但运行时报Class 'Xxx\Yyy' not found，这不是包装错了，是autoloader映射还停留在旧版本。Composer 不会自动刷新autoload缓存，尤其当你用--no-update或--with-all-dependencies这类非标准流程时。
必须手动执行composer dump-autoload（开发环境）或composer dump-autoload --optimize（生产）。如果启用了OPCache，还得重启PHP进程；某些IDE（如PhpStorm）也会缓存类路径，关掉项目再重开更保险。
- 别删
vendor/autoload.php——它只是入口文件，真正映射在vendor/composer/autoload_*.php里 -
composer dump-autoload不检查代码语法，只重建映射；如果类文件本身已被删或移动，它照样生成空映射 - CI/CD流水线里记得加
composer dump-autoload --classmap-authoritative，避免运行时动态扫描
真实场景里最容易被忽略的，是降级后没跑测试就提交了composer.lock——它记录的是“能装上”，不是“能跑通”。
