应先运行 composer why-not vendor/package:version 查清冲突根源，再用 composer update vendor/package --with-all-dependencies 局部更新，避免直接删 composer.lock 或盲目执行 composer update。
composer install 报错 “found x.x.x but x.x.x was required” 怎么办
这是最典型的版本约束冲突，Composer 检测到已安装的包版本不满足当前 composer.json 中声明的约束条件。根本原因不是“装错了”，而是锁文件（composer.lock）与 composer.json 不一致，或依赖树中某包被其他依赖强制指定了不兼容版本。
- 先运行
composer why-not vendor/package:version查清谁在阻止升级（比如 A 依赖monolog/monolog:^2.0，而 B 要求^3.0） - 不要直接删
composer.lock—— 这会导致所有依赖重解析，可能引入新冲突；优先用composer update vendor/package --with-all-dependencies局部更新 - 若报错来自 dev-master 或分支别名（如
"dev-main as 2.5.0"），检查该包是否真发布了对应稳定版；分支别名只是“伪装”，实际仍按 commit hash 解析
如何写兼容性更强的版本约束
宽松 ≠ 放任，^ 和 ~ 行为差异极大，且受最低稳定版本策略影响。默认 minimum-stability 是 stable，所以即使写了 "dev-main" 也可能被忽略。
-
^1.2.3允许升级到1.x的任意小版本和补丁版（即1.2.3 → 1.99.99），但不会升到2.0.0 -
~1.2.3更保守：只允许补丁升级（1.2.3 → 1.2.99），小版本变动（如1.3.0）就拒绝 - 生产环境慎用
*、dev-前缀或branch-alias；测试时可临时加--stability-dev，但必须明确知道哪些包因此降级了稳定性 - 如果多个包都依赖
guzzlehttp/guzzle，但各自约束不同（如^6.5vs^7.0），Composer 会选一个能同时满足的最高公共版本 —— 若无交集就报冲突
强制覆盖版本约束的几种手段及其风险
所谓“强制”，本质是绕过 Composer 的自动解析逻辑，代价是失去可复现性和协作安全性。仅限紧急修复或内部私有包场景。
-
composer require vendor/package:1.2.3 --no-update再composer update vendor/package：跳过自动推导，锁定具体版本 - 在
composer.json中用replace或provide声明虚拟包，欺骗依赖检查（例如让自研缓存组件“提供”psr/cache-implementation） - 修改
composer.lock手动改某包的version和source/reference字段 —— 极易导致下次update被覆盖，且无法通过composer validate - 设置
"prefer-stable": true并配合"minimum-stability": "dev"可缓解部分冲突，但会拉取大量不稳定快照，CI 环境慎用
为什么 composer update 不解决冲突，反而更糟
因为 composer update 默认更新全部包到最新兼容版本，而依赖图越复杂，全局最优解越难找。它不是“升级”，而是重新求解整个约束系统 —— 尤其当存在间接依赖（transitive dependency）时，一个小包的次要版本变动可能触发整条链路回退。
- 始终用
composer update --dry-run预览变更，重点关注Downgrading和Removing行 - 对关键包（如
symfony/framework-bundle）执行composer update symfony/* --with-dependencies，限制影响范围 - 如果项目长期未更新，建议分阶段操作：先
composer update --minor-only（需插件hirak/prestissimo或 Composer 2.2+ 原生支持），再逐步放开 - 真正棘手的冲突往往藏在
require-dev里 —— 某个测试工具要求新版phpunit，却和主框架的phpunit兼容层冲突，此时应考虑移出require-dev或用platform-check隔离
实际冲突常发生在团队协作时：有人本地 update 后提交了新 composer.lock，但没同步说明改动点。最稳妥的做法，是把 composer.lock 视为代码的一部分，每次变更都附带清晰的依赖影响说明，而不是靠“重装一遍”蒙混过关。
