答案是先运行composer why-not vendor/package:version定位阻塞链，再结合composer show --tree分析真实依赖结构，避免盲目删除vendor或composer.lock；需检查require-dev等隐形冲突源，并用--with-dependencies定点更新。

别删 vendor 或 composer.lock，那只会重跑一遍失败逻辑。 真正卡住的不是包本身，而是依赖图里某条路径上互斥的版本约束——得把阻塞点挖出来，再定点干预。

用 composer why-not 定位冲突源头

它输出的是反向链：从你 composer.json 里写的根声明开始，逐层往上推，直到某一行标着 (required by ...) 提出了矛盾约束，那就是冲突起点。

• 比如报错说不能装 guzzlehttp/guzzle:^7.5，就运行 composer why-not guzzlehttp/guzzle:^7.5
• 如果输出为空，大概率是 require-dev 里的包在拖后腿（比如 phpunit/phpunit 锁死了某个 sebastian/... 版本）
• 加 --dry-run 验证：如 composer require laravel/framework:11.0.0 --dry-run，不改文件就能看到是否真能解出路径

看真实依赖结构，别信 composer.json 的“愿望清单”

composer show --tree 显示的是 vendor/ 和 composer.lock 的快照，不是你写在 composer.json 里的理想状态。它能暴露你根本没意识到的间接路径。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 查某个包被谁引入：composer show --tree | grep "symfony/console"，注意后面是否标着 (locked to 5.4.42)
• 过滤关键段：composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"
• 看到某包标着 (replaced) 或 (provided)，得去它自己的 composer.json 里确认实际行为

用 composer update 定点更新，不是全量重算

全量 composer update 容易触发 SAT 求解器卡死，尤其依赖多的项目。升级单个包必须带 --with-dependencies，否则 Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来。

• 正确写法：composer update monolog/monolog --with-dependencies —— 只动它和直系依赖
• 错误写法：composer update "monolog/monolog:^3" —— 引号 + ^ 会让 Composer 自己找“最新兼容版”，不是你要的 3.0.0
• 降级跨主版本（如从 guzzlehttp/guzzle:^8.0 切回 7.4.5），必须在 composer.json 里写死："guzzlehttp/guzzle": "7.4.5"，不能只写 "^7.0"
• 执行后立刻 git diff composer.lock，确认只有目标包及其直系依赖被改，没波及其他

最常被忽略的其实是 require-dev 和 replace 声明——它们不显眼，但可能悄悄锁死某个底层组件的版本。解决冲突不是比谁删得狠，而是比谁看得清依赖图里的每一根线。