优先用 composer why-not 定位冲突源头，结合 composer depends 和 composer prohibits 查依赖路径与限制条件，避免直接删 lock 文件或盲目降级。
composer install 报错 “can’t be installed because it conflicts with another package” 怎么办
这是最典型的依赖冲突信号，composer install 或 composer update 中断并提示某个包无法安装，根本原因是锁文件（composer.lock）里已记录的版本与当前要求不兼容，或多个 require 项对同一包提出了互斥的版本约束。
别急着删 composer.lock 或全量 update——那会放大不确定性。优先用 composer why-not 定位冲突源头：
composer why-not monolog/monolog:^3.0它会列出所有阻止该版本被安装的依赖路径，比如：myapp/core 要求 monolog/monolog:^2.0，而 vendor/lib-a 又依赖 monolog/monolog:~1.26。这时候你就知道该去查 myapp/core 的 composer.json 或推动 lib-a 升级。
怎么生成依赖关系图看清楚谁在拉低版本
composer show --tree 是最轻量的可视化方式，但它只显示当前已安装的包层级，对未安装/冲突包不敏感。真正有用的是：
-
composer depends：查谁依赖了这个包（比如composer depends guzzlehttp/guzzle），确认是否自己项目直接 require，还是某 SDK 间接带入 -
composer prohibits：查哪个包明确禁止该版本（例如: composer prohibits phpunit/phpunit:10.0），比why-not更聚焦限制条件 - 配合
--no-dev参数重试：有时冲突来自require-dev，临时去掉开发依赖可快速验证主干是否可通
注意：composer show --tree 输出里如果看到同一包出现多个版本（如 symfony/console v5.4.33 和 v6.4.7 并存），说明有包用了 replace 或 conflict 声明，得去对应包的 composer.json 查具体规则。
需要降级某个包时，为什么不能直接改 composer.json 的版本号
直接把 "laravel/framework": "^10.0" 改成 "^9.50" 然后跑 composer update laravel/framework，看似合理，但常失败。原因有三：
- 其他已安装包可能已适配 Laravel 10 的接口，降级后运行时报
class not found或Method not exist -
composer update默认只更新目标包及其子依赖，但 Laravel 9 依赖的symfony/*版本范围更窄，可能和现有symfony/http-kernel冲突，触发二次报错 - 没清理
vendor/缓存，Composer 有时会复用旧的安装结果，导致版本“看起来变了”，实际加载的仍是高位版本的类文件
稳妥做法是：
rm -rf vendor composer.lock
composer install但仅限于你完全掌控所有依赖来源的场景。更推荐分步：composer update "laravel/framework:^9.50" --with-all-dependencies，强制连带更新其生态链中所有兼容版本。
lock 文件里版本和 composer.json 不一致？别手动改 lock
composer.lock 是自动生成的哈希快照，手动编辑 packages 或 packages-dev 数组里的版本号，下次 install 会校验失败并报 lock file is not up to date。真要干预，必须走 Composer 的机制：
- 用
composer require --no-update vendor/package:1.2.3先写入composer.json，再composer update vendor/package - 若需锁定某个子依赖（如强制用
guzzlehttp/psr7的 1.x），在composer.json加conflict块："conflict": {
"guzzlehttp/psr7": ">=2.0.0"
} - 检查
platform配置：有时 PHP 版本声明太低（如"config": {"platform": {"php": "7.4"}}）会压制高版本包，删掉或调高再试
依赖冲突的本质不是版本数字打架，而是 API 兼容性断层。盯着报错里第一个「cannot use」的类或方法，顺藤摸到最早引入它的那个 require 行，往往比盲目降级更快见效。