require 冲突本质是版本约束不可满足，即 composer.json 中各包约束无法在仓库中找到同时满足的版本组合；应优先调整约束如 ^2.8 允许 2.8.0–2.9.9，而非用 --ignore-platform-reqs 等危险参数。
require 冲突的本质是版本约束不可满足
Composer 报 require 冲突，不是“锁死了不能装”，而是当前 composer.json 中各包的版本约束（如 "monolog/monolog": "^2.0"、"laravel/framework": "8.75.*"）在已知包仓库中找不到一个能同时满足所有依赖的版本组合。它不报错，只是拒绝生成 composer.lock 或更新依赖。
修改 version constraint 比强制 install 更安全可靠
不要一上来就用 --ignore-platform-reqs 或 --force-reinstall。这些参数绕过校验，但可能引入运行时崩溃（比如 PHP 版本不兼容、扩展缺失、函数签名变更）。优先检查并调整约束：
-
^表示「兼容性升级」，例如^2.8允许 2.8.0–2.9.9，但不允许 3.0；若需跨主版本，得显式改成~2.0 || ^3.0或放宽为^2.0 || ^3.0 -
~表示「补丁级兼容」，例如~2.8.0等价于>=2.8.0 ；若想允许 2.9.x，应改为~2.8 - 使用
composer prohibits vendor/package快速定位哪个包在阻塞安装，再查它的composer.json中对目标包的约束
临时重定向到私有源或特定分支需改 composer.json 的 repositories
当官方包尚未发布适配版，但你已确认某个 Git 分支（如 dev-fix-php82）可用，可通过 repositories 强制拉取：
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/yourname/package-name"
}
],
"require": {
"vendor/package-name": "dev-fix-php82"
}
}
注意：dev- 分支名必须与远程仓库实际分支一致；执行后需运行 composer update vendor/package-name --with-dependencies，否则旧 lock 文件仍会锁定历史版本。
强制重装只应在明确知道后果时使用
composer update --force 会忽略 composer.lock 中的已解析版本，重新计算整个依赖图——这可能导致大量次要包升级，甚至引入 BC Break。更可控的做法是：
- 仅更新冲突相关包：
composer update vendor/conflict-package --with-all-dependencies - 降级 PHP 版本约束（如项目实际跑在 8.1，但
composer.json写了"php": "^8.2"），改回"php": "^8.1"后再composer update - 清理缓存 + 重试：
composer clear-cache && composer update --no-cache，避免本地元数据过期导致误判
真正难解的冲突，往往藏在间接依赖里——别只盯着根 require，用 composer show -t 看完整依赖树，再逐层 inspect composer why vendor/package 找出谁在拖后腿。
