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” 是版本约束打架了
根本原因不是包“重复”，而是多个依赖对同一包提出了互斥的版本要求。比如 monolog/monolog 被 A 包锁死在 ^2.0，B 包却要求 ^3.0，Composer 就卡住不动。
- 先运行
composer why monolog/monolog（把包名换成实际冲突包）看谁在拉它，再用composer why-not monolog/monolog:3.0.0查具体哪条依赖链拒绝升级 - 别急着删
vendor或composer.lock—— 这只会让问题更模糊；优先用composer update --dry-run验证调整后的效果 - 如果必须降级某个包来让整体兼容，加
--with-all-dependencies参数，否则 Composer 默认只更新直连依赖，深层冲突仍存在
require 同一个包两次但版本不同，为什么没报错？
Composer 允许你在 composer.json 里多次写 "monolog/monolog": "^2.8" 和 "monolog/monolog": "^3.0"，但它只认最后一个声明 —— 不是合并，也不是报错，而是静默覆盖。
- 这种写法常见于手写 JSON 时复制粘贴出错，或脚本生成配置遗漏去重逻辑
- 检查方式很简单：运行
composer show monolog/monolog，看输出的 version 是否符合你“以为”的那个 - 真正起作用的是
composer.lock里的 resolved 版本，composer.json中重复项不会导致安装失败，但会误导维护者
dev-main / dev-develop 被当成稳定版引入，引发不可控更新
用 "some/package": "dev-main" 这类开发分支引用，等同于告诉 Composer：“我接受任何提交”，一旦上游改了接口或删了函数，你的 composer update 就可能悄无声息地引入 break change。
- 生产环境绝对不要用
dev-前缀；必须用就加#commit-hash锁死，例如"some/package": "dev-main#abc1234" -
composer outdated不会提醒你 dev 分支有新提交，它只比对 tag；所以这类包要单独盯紧 - 如果某个包只有 dev 分支可用，优先考虑 fork 后打自己的 tag，而不是长期依赖不稳定的分支
require-dev 里的包和 require 冲突，为什么 install 不报错？
因为 composer install 默认不装 require-dev，只有加 --dev（或没加 --no-dev）才装。但如果你在 CI 或部署时用了 --no-dev，而某个测试工具（比如 phpunit）又被主依赖间接拉进来了，就可能触发隐性冲突。
- 查清依赖来源：用
composer depends --tree phpunit/phpunit看是不是某个生产包偷偷依赖了它 - 避免“测试包污染生产环境”的最稳做法：把所有
require-dev移到独立的composer.json（比如tests/composer.json），CI 里单独装 -
composer update --no-dev仍可能因 lock 文件残留旧记录而装错版本，遇到怪问题先删composer.lock再试
真正的难点不在命令怎么敲，而在搞清哪个包是“主动声明”的、哪个是“被动继承”的。Composer 的冲突提示永远只说“不能满足”，不说“谁在捣鬼”——得靠 why 和 depends 一层层挖。
