不能直接删 vendor 或 composer.lock，因为冲突源于依赖图中版本无交集（如 monolog ^1.25 与 ^2.0 冲突），需用 composer why-not 定位阻断链，再精准更新目标包及其直系依赖。
为什么不能直接删 vendor 或 composer.lock
删了只会让 Composer 重跑一遍失败逻辑，大概率还是报同样的 Conclusion: don't install xxx。冲突不是文件损坏，而是依赖图里某条路径卡死了目标版本——比如 package-a 要求 monolog/monolog ^1.25，而你刚 require laravel/framework:11.0.0，它却硬性依赖 monolog/monolog ^2.0，两者没交集，SAT 求解器直接放弃。
用 composer why-not 定位阻断链
这是最小改动的前提：不猜、不试、不删，先看谁在联合封杀你想要的版本。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer why-not monolog/monolog:2.9.0，输出是一条反向链，从最后一行（你composer.json的根声明）往上读，看到哪一行标着(required by)提出了互斥约束，就是冲突源头 - 如果输出为空，立刻检查
require-dev—— 很多时候是phpunit/phpunit或orchestra/testbench拖着老版sebastian/exporter，间接锁死symfony/console - 配合
composer prohibits monolog/monolog:2.9.0查所有阻止该版本的包，比why-not更直给
只动一个包及其直系依赖
全量 composer update 是最危险的操作，尤其依赖超过 30 个时，SAT 求解器容易卡死在 Resolving dependencies 阶段超过 5 分钟。
- 正确做法：
composer update monolog/monolog --with-dependencies—— 只更新它和它的子依赖，不碰其他分支 - 错误写法：
composer update "monolog/monolog:^2"，加引号 +^会让 Composer 自己找“最新兼容版”，不是你要的 2.9.0 - 降级跨主版本（如从
guzzlehttp/guzzle:^8.0切回7.4.5），必须在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他
锁定版本前先验证真实依赖结构
composer.json 里写的只是“愿望清单”，composer.lock 和 vendor/ 才是真实快照。别信配置，要看树。
- 运行
composer show --tree显示完整依赖结构；加过滤更准：composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle" - 查某个包被谁引入：
composer show --tree | grep "symfony/console"，注意后面是否标着(locked to 5.4.42) - 看到某包标着
(replaced)或(provided)，得去它自己的composer.json里确认替换关系是否真能覆盖——比如用symfony/polyfill-mbstring替代ext-mbstring是安全的，但用mockery/mockery去替代phpunit/phpunit的 mock 功能就不可行
require-dev 里，且不报错直到你跑测试；而 --with-dependencies 看似精准，一旦目标包的子依赖本身又牵扯进另一条冲突链，就会二次失败——这时候得退一步，用 --dry-run -v 看日志里反复出现的 Trying 和回退路径，再决定是否拆成两轮更新。 
