Composer依赖冲突需先用composer why-not定位阻塞包，再结合-v参数查看详细推理链，区分require与require-dev冲突，优先升级工具版本或隔离开发依赖，避免盲目删vendor或改配置。
composer install 报错 “Conclusion: don’t install xxx” 怎么办
这是最典型的依赖冲突表现，Composer 在尝试满足所有 require 声明时发现逻辑矛盾，比如 A 包要求 monolog/monolog:^2.0，B 包却硬性依赖 monolog/monolog:1.25.0，两者无法共存。
别急着删 vendor 或改 composer.json —— 先让 Composer 告诉你冲突点在哪：
- 运行
composer why-not vendor/package:version（例如composer why-not monolog/monolog:2.9.0），它会列出谁在阻止这个版本被安装 - 加
-v参数重试composer install -v，输出里会有一段 “Problem 1” 开头的详细推理链，比报错信息本身更有用 - 注意看冲突是否来自
require-dev：开发依赖有时会悄悄锁死生产依赖的升级路径
require 和 require-dev 的依赖打架怎么拆
常见场景是：主项目需要 phpunit/phpunit:^10.0，但某个 require-dev 工具（比如 phpstan/phpstan）只兼容 phpunit/phpunit:^9.5。这时 Composer 会把整个依赖图拉回 v9。
解决思路不是“降级主项目”，而是分层隔离：
- 确认该工具是否真需要和主项目共享 autoloader —— 大多数静态分析、格式化工具可独立运行，建议移出
require-dev，改用composer global require或phar方式调用 - 如果必须保留在项目中，检查该工具是否有新版支持更高 PHPUnit 版本（比如
phpstan/phpstanv1.11+ 已支持 PHPUnit 10） - 临时绕过：用
composer install --ignore-platform-reqs强行装（仅限调试，上线前必须修复）
dev-main / dev-develop 被当成稳定版锁定怎么办
当你在 composer.json 里写了 "some/package": "dev-main"，Composer 默认把它当“不稳定分支”处理；但如果另一个包声明了 "some/package": "^1.0"，而 dev-main 又没打正式 tag，Composer 就可能拒绝解析，报 “Your requirements could not be resolved”。
根本原因是稳定性标识不一致：
- 检查
minimum-stability设置：如果是stable，那dev-main默认不被允许，得显式加"prefer-stable": true并配合"stability-flags" - 更稳妥的做法是：用
composer require some/package:dev-main --with-all-dependencies，让 Composer 主动计算兼容路径，而不是靠手写版本约束 - 注意 GitHub Package Registry 或私有仓库的
dist模式可能缓存旧的composer.json，删掉vendor/some/package再clear-cache有时比重装更有效
lock 文件里一堆 ^x.y.z 却装不出对应版本
composer.lock 是快照，不是说明书。哪怕里面写着 "version": "3.4.5"，只要本地已存在 vendor 目录且文件未变，composer install 就不会重新下载或校验 —— 这导致“明明 lock 里有，却提示找不到类”的诡异问题。
真正起作用的是当前 vendor 状态和 composer.json 的组合：
- 执行
composer update --lock可强制重读composer.json并重生成 lock（不更新包），适合修正手动改错的 lock 文件 - 若想彻底清理干扰，删掉
vendor和composer.lock，再composer install—— 但务必确认团队共享的 lock 文件已提交，否则协作环境会不一致 - 某些 CI 环境因缓存机制跳过
install步骤，直接复用旧 vendor，这时候光改 lock 没用，得加--no-cache或清构建缓存
依赖冲突从来不是版本号对不上那么简单，关键在看清哪一层（声明层、解析层、安装层、运行层）出了偏差。很多人卡在第二层却去改第四层，结果越调越乱。
