Composer 报“Your requirements could not be resolved”是因为依赖图闭包无解，如 symfony/console 版本冲突；应优先用 composer show --tree 和 composer why-not 定位冲突源，谨慎使用 --with-dependencies 或 --with-all-dependencies 更新，避免盲目 update 或 --ignore-platform-reqs。
为什么 composer install 突然报 “Your requirements could not be resolved”？
这不是 Composer 在故意为难你，而是它发现你声明的依赖组合在当前约束下根本不存在可同时满足的版本。比如 package-a 要求 symfony/console:^5.4，而 package-b 锁死在 symfony/console:6.2.0，两者无法共存——Composer 会直接拒绝安装，而不是“选一个凑合用”。
关键点在于：Composer 解析的是整个依赖图的**闭包解**，不是逐个安装。冲突往往藏在间接依赖里，composer show --tree 比报错信息更值得先看。
- 别急着删
vendor/或composer.lock：这只会让问题更模糊，尤其在 CI 环境中可能掩盖真实不兼容性 - 运行
composer why-not vendor/package:version是最快定位“谁拦着我升级”的方式 - 注意
conflict字段：有些包（如 Laravel 的官方扩展）会在composer.json中显式声明与高版本框架互斥
如何安全降级或升级某个包而不引发连锁反应？
盲目执行 composer update vendor/package 很危险——它默认会连带更新该包的所有子依赖，可能把其他组件拖进新坑。真正可控的做法是加 --with-all-dependencies 或精确锁死范围。
composer update monolog/monolog --with-dependencies
这个命令只更新 monolog/monolog 及其直接依赖（即 monolog/monolog 自己 require 的那些），不碰项目顶层其他包的版本。如果你要强制对齐某版本号，直接写死：
composer require symfony/http-kernel:5.4.* --no-update composer update symfony/http-kernel --with-all-dependencies
-
--no-update先改composer.json，再手动update，比一步到位更可控 - 避免用
^或~锁太宽的版本（如^4.0），尤其当主包已发布 v6 时，^4.0仍可能拉到 5.x 的破坏性更新 - 如果必须混用大版本（如 v5 和 v6 组件），确认它们是否支持“并行安装”——例如 Symfony 的组件从 v5.4 起普遍支持
symfony/polyfill-*补丁，而非硬依赖统一主版本
遇到 “Root package requires … but … is locked to …” 怎么破？
这是 composer.lock 文件和 composer.json 不一致的典型提示。常见于多人协作中有人手改了 composer.json 却没跑 composer update 提交新 lock 文件，或者 Git 合并时丢掉了 lock 的变更。
正确做法不是覆盖 lock，而是让它重新协商：
composer update --lock
这个命令不改任何包版本，只根据当前 composer.json 重生成合法的 composer.lock。如果失败，说明 composer.json 本身存在逻辑矛盾（比如两个 require 写了互斥版本），就得人工介入。
- CI 流水线中务必校验
composer.lock是否过期：加一行composer validate --strict && ! composer update --dry-run - 不要在
composer.json中用dev-master或分支名作为版本约束——它们没有确定性哈希，每次 install 都可能拉不同 commit，lock 文件失去意义 - 私有包若用
path类型仓库，确保路径存在且含有效composer.json，否则 Composer 会跳过解析，导致后续依赖找不到来源
什么时候该考虑 fork、patch 或禁用冲突检查？
95% 的冲突靠调整版本约束就能解决；剩下 5%，往往是生态断层（如 PHP 8.2+ 下某老包彻底不维护）或公司内部强耦合架构导致的硬冲突。这时妥协方案才有意义。
优先尝试 composer config --global platform.php 8.1.0 临时降级平台版本声明，绕过某些仅因 PHP 版本标记导致的误判。但注意：这只是告诉 Composer“假装我在 8.1”，实际运行时仍需真环境匹配。
- 用
composer require --ignore-platform-reqs属于最后手段，它会跳过所有php、ext-*、lib-*检查，可能导致运行时报扩展缺失错误 - 给上游提 PR 并打 patch（通过
composer patches插件）比 fork 整个包更轻量，尤其只改几行类型声明或兼容性判断时 - 如果冲突来自 dev-only 工具（如
phpunit/phpunit），确认它们是否被标记为require-dev，避免污染生产依赖树
最常被忽略的一点：Composer 的冲突提示有时是“假阳性”——它基于静态分析认为不可解，但实际运行时某些包的 autoloading 或条件加载让低版本也能工作。验证前，先看那个报错的包是否真的被你的代码路径调用。
