Composer安装报“can’t resolve package X”根本原因是版本约束冲突，如A要求monolog^2.0而B要求^3.0；应先用composer why和why-not定位依赖链，再用--dry-run验证，慎删vendor或lock文件。
composer
install 时提示 “can’t resolve package X” 是版本约束打架了
根本原因不是包“重复”，而是多个依赖对同一包提出了互斥的版本要求。比如
被 A 包锁死在
，B 包却要求
，Composer 就卡住不动。
先运行
（把包名换成实际冲突包）看谁在拉它，再用
查具体哪条依赖链拒绝升级
别急着删
或
—— 这只会让问题更模糊；优先用
验证调整后的效果
如果必须降级某个包来让整体兼容，加
参数，否则 Composer 默认只更新直连依赖，深层冲突仍存在
require 同一个包两次但版本不同，为什么没报错？
Composer 允许你在
里多次写
和
，但它只认最后一个声明 —— 不是合并，也不是报错，而是静默覆盖。
这种写法常见于手写 JSON 时复制粘贴出错，或脚本生成配置遗漏去重逻辑
检查方式很简单：运行
，看输出的 version 是否符合你“以为”的那个
真正起作用的是
里的 resolved 版本，
中重复项不会导致安装失败，但会误导维护者
dev-main / dev-develop 被当成稳定版引入，引发不可控更新
用
这类开发分支引用，等同于告诉 Composer：“我接受任何提交”，一旦上游改了接口或删了函数，你的
就可能悄无声息地引入 break change。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
生产环境绝对不要用
前缀；必须用就加
锁死，例如
不会提醒你 dev 分支有新提交，它只比对 tag；所以这类包要单独盯紧
如果某个包只有 dev 分支可用，优先考虑 fork 后打自己的 tag，而不是长期依赖不稳定的分支
require-dev 里的包和 require 冲突，为什么 install 不报错？
因为
默认不装
，只有加
（或没加
）才装。但如果你在 CI 或部署时用了
，而某个测试工具（比如
）又被主依赖间接拉进来了，就可能触发隐性冲突。
查清依赖来源：用
看是不是某个生产包偷偷依赖了它
避免“测试包污染生产环境”的最稳做法：把所有
移到独立的
（比如
），CI 里单独装
仍可能因 lock 文件残留旧记录而装错版本，遇到怪问题先删
再试
真正的难点不在命令怎么敲，而在搞清哪个包是“主动声明”的、哪个是“被动继承”的。Composer 的冲突提示永远只说“不能满足”，不说“谁在捣鬼”——得靠
和
一层层挖。
monolog/monolog^2.0^3.0composer why monolog/monologcomposer why-not monolog/monolog:3.0.0vendorcomposer.lockcomposer update --dry-run--with-all-dependenciescomposer.json"monolog/monolog": "^2.8""monolog/monolog": "^3.0"composer show monolog/monologcomposer.lockcomposer.json"some/package": "dev-main"composer updatedev-#commit-hash"some/package": "dev-main#abc1234"composer outdatedcomposer installrequire-dev--dev--no-dev--no-devphpunitcomposer depends --tree phpunit/phpunitrequire-devcomposer.jsontests/composer.jsoncomposer update --no-devcomposer.lockwhydepends