composer prohibits 是定位冲突断点的首选，因它从目标版本出发反向查出所有禁止安装的约束源，如 spatie/laravel-backup v7.2.0 要求 symfony/console ^5.4，直接封死 laravel/framework:11.0.0；配合 composer update --dry-run -v 查看末尾 “because”链和“root requirements”，可精准锁定无交集版本与源头约束。
Composer 依赖冲突不能靠猜，必须用 composer prohibits 和 composer update --dry-run -v 定位真实断点——其他命令要么漏源、要么只查表层。
为什么 composer prohibits 是定位冲突断点的首选
它从你想装却装不上的包出发，反向翻出所有“拉低版本”或“明确禁止”的依赖源头，比 composer why-not 更直接有效。比如你执行 composer require laravel/framework:^11.0 失败，why-not laravel/framework:11.0.0 可能返回空（因为没在 composer.json 里声明），但 prohibits laravel/framework:11.0.0 会立刻指出：spatie/laravel-backup v7.2.0 要求 symfony/console ^5.4，和 Laravel 11 的 ^6.4 冲突。
注意三点：
-
prohibits后必须跟完整版本号，如laravel/framework:11.0.0，写^11.0或11.0都会报[InvalidArgumentException] Package not found - 输出中每行末尾的
(for spatie/laravel-backup v7.2.0)就是真正的“卡手人”，不是建议升级对象，而是必须先处理的约束源 - 它不关心你是否已安装该包，只看谁在逻辑上封死了这条路——这正是调试断点最需要的视角
composer update --dry-run -v 怎么看出哪一行是冲突断点
这个命令不改任何文件，但把 Composer 整个依赖求解过程摊开给你看。关键不是看开头，而是盯住末尾几行：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- “Because”链：例如
Because package-a v2.1 requires monolog/monolog ^1.25, and package-b v3.0 requires monolog/monolog ^2.10—— 这就是无交集的铁证，monolog/monolog在这两条路径上没有共同兼容版本 - “Root requirements”段落：列出你
composer.json里写的原始约束，比如myapp/core: ^2.0，它是整场冲突的起点 - “Found conflicting requirements”：明确标出具体包名和版本范围，如
guzzlehttp/guzzle: ^7.0 vs ^8.0，这些才是你要动手调的对象
漏掉 -v 参数，你就只看到“无法解析”；有了它，才能看见“谁在拉扯谁”。
开发期依赖（require-dev）怎么偷偷制造断点
很多断点根本不在主业务链里，而是被 phpunit/phpunit、phpstan/phpstan 这类工具包悄悄拖进来的。它们虽标为 require-dev，但子依赖仍参与全局解析，且常带高版本的 sebastian/*、phpspec/prophecy，和主业务依赖的 symfony/* 版本打架。
验证方法很直接：
- 运行
composer update --no-dev --dry-run -v，如果不再报错，说明断点来自dev分支 - 再用
composer show --tree phpunit/phpunit扫它依赖的底层包，重点看sebastian/exporter、phpspec/prophecy是否和你的symfony/event-dispatcher等存在主版本冲突 - 临时绕过：生产部署可用
composer install --no-dev，但本地调试时务必保留--with-all-dependencies，否则隐藏断点不会暴露
断点排查中最容易被忽略的三个细节
真正卡住人的往往不是大问题，而是几个极小但致命的疏忽：
-
config.platform.php和实际 PHP 版本不一致：比如本地是 PHP 8.2，但composer.json里写了"platform": {"php": "8.1"}，某个依赖只支持 8.2+，Composer 就会在 resolve 阶段静默失败，连错误提示都不给全 - 私有包或
dev-main没加@dev后缀：写"vendor/private": "dev-main"一定报错，必须写成"dev-main@dev"或全局设"minimum-stability": "dev"（慎用） - 同一包在
composer show --tree输出中出现多个版本：比如symfony/console同时有v5.4.33和v6.4.7，说明有包用了replace或conflict声明，得去对应包的composer.json查规则，而不是盲目升级
