Composer依赖冲突报错需先用composer why-not定位冲突源，再结合composer show -t、composer show等命令分析依赖树与可用版本，区分dev与prod环境安装策略。
composer install 或 update 报错 “found x packages that conflict”
这是最典型的依赖冲突信号，composer 拒绝继续执行，因为无法同时满足多个包对同一依赖的版本要求。比如 package-a 要求 monolog/monolog:^2.0，而 package-b 锁定在 monolog/monolog:1.25.0，二者无法共存。
关键不是看报错文字，而是定位「谁在提什么要求」。运行以下命令获取真实依赖图：
composer why-not monolog/monolog:2.0.0
它会列出所有阻止升级到该版本的包及其约束条件。同理，可替换为任意你怀疑冲突的包名和版本。
- 优先用
composer why-not，不是composer depends—— 后者只显示“谁依赖我”，不体现版本限制 - 如果报错中出现
Root package requires ...，说明是你composer.json里直接写的约束太窄，比如写死了"php": "7.4"，但某个新包已放弃支持 PHP 7.4 -
composer show -t可视化整个依赖树，但输出长，建议配合grep过滤：composer show -t | grep monolog
composer require 时提示 “could not resolve packages”
这不是网络问题，是语义版本（SemVer）解析失败。常见于你手动指定了一个不存在的版本字符串，或该包在当前 minimum-stability 下不可见。
例如执行：composer require laravel/framework:9.99.99，但 Laravel 9 最高只到 9.52.x，9.99.99 根本不存在；又或者你写了 dev-master，但 "minimum-stability": "stable" 且没加 "prefer-stable": true，就会被忽略。
- 查真实可用版本：用
composer show laravel/framework看全部 tag 列表，或去 packagist.org 搜索包名 - 临时放宽稳定性要求：加
--stability=dev，但别提交到composer.json，否则影响团队环境 - 避免用
dev-xxx分支名直连，除非明确需要未发布功能；优先用^x.y或~x.y.z
lock 文件存在但 install 失败，提示 “package x is not installed”
这通常是因为 composer.lock 记录了某个包的 dist ZIP URL，但该 URL 已失效（如 GitHub 删除了 release、Packagist 同步延迟），或本地 vendor/ 残留文件与 lock 不一致。
不要直接删 vendor 和 lock 重来——那样会丢失精确版本锁定。先尝试更轻量的修复：
composer install --no-scripts --no-plugins
跳过脚本和插件，专注还原文件结构。若仍失败，再执行：
composer clear-cache && composer install
-
composer.lock中的content-hash必须与composer.json当前内容完全匹配，哪怕多一个空格都会导致 install 拒绝使用 lock - 多人协作时，确保所有人用相同 major 版本的
composer（如都用composer v2.5.x），v1 和 v2 生成的 lock 格式不兼容 - CI 环境中若用
composer install报错，检查是否漏了--no-interaction或--optimize-autoloader参数引发超时
require-dev 里的包引发冲突，但生产环境不需要它们
开发依赖（如 phpunit/phpunit、larastan/larastan）经常比主依赖更激进地要求新版 PHP 或其他组件，导致 composer update 卡住。但线上部署时根本不需要这些包。
解决方案不是删掉它们，而是分场景安装：
- 本地开发：照常
composer install（默认包含 dev） - 线上部署：用
composer install --no-dev --optimize-autoloader，跳过所有require-dev，也避免因 dev 包冲突导致失败 - CI 测试阶段：显式指定
composer install --with-all-dependencies，确保测试所需全链路可用
注意：--no-dev 不影响 autoload-dev 的自动加载逻辑，只是不装包；如果你的测试代码依赖某个 dev 包的类，那必须保证它已被安装。
