Composer install成功不等于版本一致，真正冲突常藏于require-dev、平台约束或隐式依赖；须用--dry-run+why-not+prohibits三步定位，删lock文件无法根治问题。
composer install 成功不代表依赖版本一致，真正冲突往往藏在 require-dev、平台约束或隐式依赖里；必须用 --dry-run + why-not + prohibits 三步定位，不能靠删 lock 文件硬解。
composer install 成功但运行时报错，怎么确认是版本不一致？
因为 composer install 只保证能落地 vendor/，不保证所有包在运行时兼容。比如 guzzlehttp/guzzle 装了 7.8.x，但某个 dev-only 工具包（如 phpunit/phpunit）悄悄拉了 symfony/http-client 6.4，而你的代码调用了 7.x 才有的方法——install 不报错，运行才崩。
- 先看报错堆栈里具体哪个类/方法找不到，反查它属于哪个包、什么版本
- 运行
composer show --installed | grep确认该包实际装的是不是你预期的版本 - 重点检查
require-dev里的包：它们可能没在生产环境装，但 CI 或本地测试时会参与解析，间接锁死主依赖版本 - 别忽略
platform配置：如果composer.json里写了"ext-gd": "*"，但 PHP 实际没开 GD，composer install仍成功（除非加--ignore-platform-reqs），而某些包的 autoloader 会在运行时检测扩展并 fatal
为什么 composer update --dry-run -v 是首选排查命令？
它完整走一遍依赖求解器逻辑，但不改任何文件，输出里藏着所有冲突线索。关键不是看开头“Resolving dependencies”，而是盯住末尾几行反复出现的包名和版本号。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 输出中出现
Root package requires ... but ... is locked to ...：说明composer.lock里某包被硬锁，而新需求要更高/更低版 - 看到
... is not satisfiable by ... because ... depends on ...：这是链式冲突，A 包要 B 2.x，B 2.x 又要求 C 3.x，但你的项目直接 require 了 C 1.x - 如果有大量
downgrading提示，说明你加的新包强制降级了已有依赖——这比升级更危险，容易触发运行时 break change - 加
-v后，每轮回溯都会打印当前尝试的版本组合，冲突点通常出现在最后一组失败尝试里
composer why-not 和 composer prohibits 怎么配合用？
这两个命令不是备选，是必须连用的定位组合：why-not 告诉你“谁拦着你装”，prohibits 告诉你“谁定死了不让动”。
- 假设你想装
laravel/sanctum:4.0.0却失败，先跑composer why-not laravel/sanctum:4.0.0—— 它会列出所有明确拒绝该版本的包，比如laravel/framework的conflict规则 - 再跑
composer prohibits laravel/framework，查谁在 require 或 require-dev 里锁死了laravel/framework的旧版（比如orchestra/testbench还只支持 9.x） - 注意
prohibits默认只查顶层依赖，加--recursive才深入子依赖树，但输出爆炸，建议先用why-not锁定目标包再针对性查 - 如果
why-not返回空，说明没人主动拒绝，问题可能出在稳定性约束上：检查是否漏了@stable后缀，或minimum-stability设成了dev导致自动匹配到不兼容的开发分支
删 composer.lock 能解决问题吗？
不能。它只会让当前可运行状态丢失，把问题从“已知冲突”变成“未知风险”。
-
composer.lock是你线上环境的真实快照，删了等于扔掉唯一可信基准 - 执行
composer update后生成的新 lock 文件，可能引入其他未测试过的版本组合，CI 通过但线上凌晨崩 - 真正该做的是：保留 lock，用
composer update --dry-run模拟变更，确认无冲突后再手动编辑 lock 文件（如只更新某几个包的 version 字段），或加--with-dependencies精准升级 - 如果 lock 文件本身损坏（比如手动改过哈希值），先用
composer validate --lock检查，再考虑composer update --lock重生成（仅限私有项目，且确保所有开发者同步）
复杂点在于：冲突不总在表层 require 里，可能藏在某个工具包的 conflict 字段、PHP 扩展的平台约束、甚至 Git 分支的 commit hash 锁定中。每次 why-not 返回空，都得再查一遍 composer show -a 全量版本列表，确认你要的版本真被发布过——Packagist 上的 tag 名和 Composer 解析的版本字符串，经常差一个 v 或大小写。
