composer outdated --minor-only 不触发死锁但掩盖风险：它只显示次版本更新，忽略主版本跃迁及间接依赖约束冲突，导致后续 composer update 时求解器因新引入的约束（如 symfony/deprecation-contract: ^3.0）与现有锁定冲突而无限回溯。
composer outdated --minor-only 为什么可能触发死锁？
它本身不触发死锁，但会掩盖真正风险：composer outdated --minor-only 只显示次版本（如 2.4.1 → 2.4.2）更新，而忽略主版本跃迁或间接依赖的约束冲突。当你据此执行 composer update vendor/package 时，Composer 仍会重算整棵子树——如果该包的次版本升级悄悄拉入一个新约束（比如要求 php:^8.2 或 ext-json>=8.0），而其他已锁定包又无法满足，求解器就可能陷入无限回溯。
常见现象是 composer update monolog/monolog --minor-only 看似安全，结果卡住、CPU 暴涨，根本原因不是 monolog 本身，而是它新发布的 2.13.2 版本在 require 中新增了 symfony/deprecation-contract: ^3.0，而项目里另一个包锁死了 ^2.0，形成隐式循环。
-
--minor-only不检查传递依赖的约束变更，只比对语义化版本号段 - 次版本更新可能带
conflicts字段，但outdated不解析也不提示 - 输出里没
!标记 ≠ 安全，!仅针对 Composer 自动识别出的 BC-breaking，不覆盖约束冲突
怎么提前发现次版本更新引发的依赖死锁？
靠 composer outdated 单独看不够，必须交叉验证：
- 先跑
composer outdated --all --format=json，提取所有待升级包名，再对每个包单独查依赖树：composer show -t vendor/package version - 重点观察升级后是否引入新 require 条目，尤其是
symfony/*、psr/*、doctrine/*这类高频冲突源 - 用
composer update vendor/package --dry-run --with-dependencies，注意输出里是否有 “Could not resolve” 或反复出现的版本来回切换 - 若项目用了
config.platform，记得加--ignore-platform-reqs再试一次，排除 PHP 扩展缺失导致的假死锁
为什么 composer show -t 比 outdated 更适合查死锁线索？
composer show -t 直接展开当前 composer.lock 中已解析的依赖图，不依赖 Packagist 最新数据，也不受 minimum-stability 影响——它反映的是“此刻真实加载路径”，而 outdated 是“假设升级后可能的路径”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
死锁往往藏在重复展开的节点里：比如 vendor/a 在树中出现三次，分别来自 laravel/framework、spatie/laravel-backup 和 monolog/monolog，且每次引入的版本范围有交集但无共同解，show -t 能暴露这个结构，outdated 则完全不呈现。
- 加
--no-dev避免开发依赖干扰生产路径 - 加
--ignore-platform-reqs绕过本地环境限制，聚焦纯约束冲突 - 输出中看到同一包名在不同层级以不同版本号展开（如
v1.2.0和v1.3.0并存），就是潜在求解器卡点
CI 中如何自动拦截次版本更新引发的死锁风险？
别让 composer outdated --minor-only 成为唯一检查项。CI 流程里应强制加入两步：
- 运行
composer update --dry-run --with-dependencies 2>&1 | grep -q "Could not resolve"，失败即中断 - 对所有
outdated --minor-only输出的包，循环执行composer show -t package-name | wc -l，若行数 > 50，触发人工复核（说明依赖树过于复杂，次版本变更影响面不可控）
真正要防的不是“次版本更新”，而是次版本更新带来的约束膨胀——它不会报错，只会让 composer install 在某次部署时突然卡住，且无日志可查。
