答案是先用 composer prohibits 检查新约束是否被其他依赖拦截：运行 composer prohibits vendor/package:version，可列出所有阻止该版本安装的包及其约束，如 laravel/framework 8.75.0 requires guzzlehttp/guzzle ^6.5，则 ^7.5 无法生效。
用 composer prohibits 快速验证版本约束是否被其他依赖拦住
写完 composer.json 里的新版本约束，别急着 composer update——先查它是不是根本没机会生效。比如你加了 "guzzlehttp/guzzle": "^7.5"，但项目里已有 laravel/framework 锁死在 ^8.75，而后者只兼容 guzzlehttp/guzzle: ^6.5，那你的 ^7.5 就永远装不上。
运行这条命令：composer prohibits guzzlehttp/guzzle:^7.5
它会列出所有已安装或声明的包，以及它们对 guzzlehttp/guzzle 的反向约束。输出里如果出现类似 laravel/framework 8.75.0 requires guzzlehttp/guzzle ^6.5，就说明你的新约束被硬性卡住了。
常见误判点：
- 没加
^或~直接写7.5，会被当成精确版本而非范围，prohibits查不到冲突但实际装不上 - 只查主包，忘了检查
require-dev里的测试工具（如phpunit/phpunit）也可能拖后腿 -
prohibits不检测 PHP 版本冲突，得另用composer why-not php:8.1
用 composer show -a 看清包到底有哪些可用版本和稳定性标签
约束写得再准，也得仓库里真有对应版本。比如你写 "monolog/monolog": "^2.0"，但 Packagist 上最新 stable 版只有 1.27.4，那 composer update 就会报 Could not find a matching version。
执行：composer show -a monolog/monolog
输出里每行是一个 tag 或分支，末尾标着 stable、RC、beta 或 dev。注意两点：
- 默认只取
stable，哪怕你写了^2.0，只要没有带stable标签的 2.x 版本，就匹配失败 - 分支名如
dev-main是合法的，但不能写成main或v2.x——必须带dev-前缀 - 私有包若未在
composer.json中声明仓库，show -a也查不到，得先确认config.repo配置正确
用 composer update --dry-run 模拟升级路径，不改任何文件
这是最接近真实场景的验证方式。它会跑完整个依赖解析流程，告诉你最终会装哪些版本、有没有冲突、是否满足 PHP 和扩展要求，但不会修改 vendor 或 composer.lock。
执行：composer update vendor/package --dry-run
关键看三类输出：
- 开头是否出现
Dependency resolution completed：没这句，说明约束本身就有语法错误或无法满足 - 中间列出的“Installing”行：确认目标包是否真按你写的约束升到了预期版本（比如
^7.5是否拉了7.5.3而不是卡在7.4.5） - 末尾是否有
Nothing to install, update or remove：说明当前composer.lock已满足新约束，无需操作——很多人误以为没生效，其实是已经锁定了
注意：--dry-run 仍受 config.platform 和本地 PHP 版本影响，如果想跳过平台检查，可临时加 --ignore-platform-reqs，但生产环境慎用。
为什么 composer install 从不验证你的新约束
这是最容易忽略的一点：改完 composer.json 后直接 composer install，什么都不会变。因为 install 只读 composer.lock，完全无视 composer.json 里的 ^/~/* 约束。
真正让约束起作用的，只有两个动作：
-
composer update：重新解析整个依赖图，按composer.json重算版本，并更新lock文件 -
composer require vendor/package:version：相当于自动更新该包并写入lock，比手动改json+update更可靠
所以测试约束是否生效，本质是测试 update 能否导出你想要的 lock 内容。别把 install 当作验证手段，它只是部署时的还原指令。
