composer why 不报冲突而需查 install/update 错误中的否定结论，再用其包名和版本执行 composer why 定位依赖源；降级需注意 SemVer 兼容性；--dry-run 仍会校验冲突；dev 分支引用存在稳定性风险。
composer why 报出“root requires”却找不到冲突包？
这通常不是 composer why 失效，而是你查错了目标。它只显示「谁依赖了某个包」，不直接报冲突。真正要定位冲突，得先看 composer install 或 composer update 的错误输出——里面一定有类似 Conclusion: don't install packageA v2.0.0 这样的否定句，这才是冲突源头。
此时应把被拒绝安装的包名（比如 monolog/monolog）和版本（比如 ^2.0）作为 composer why 的参数：
composer why monolog/monolog ^2.0
它会列出所有直接或间接要求该版本的包。注意：如果返回空，说明没有包显式要求这个版本，可能是其他包的 require-dev 或 conflict 规则在起作用，需配合 composer show --tree 查依赖树。
composer update 时强制降级某个包是否安全？
不总是安全，但有时是最快解法。关键看降级是否破坏语义化版本兼容性（SemVer）。例如从 symfony/console v6.4.0 降到 v6.3.10 属于补丁更新，大概率安全；但降到 v5.4.39 就跨主版本，API 可能已移除（如 Command::configure() 替代 configure()）。
- 先确认目标包是否真被其他依赖锁死：运行
composer depends --tree vendor/package-name（Composer 2.5+）或composer show -t vendor/package-name - 若只是某一个 dev-only 包在拖后腿，可临时用
--with-all-dependencies跳过它 - 降级命令示例（指定精确版本）：
composer require vendor/package-name:5.4.39 --no-update
，再composer update vendor/package-name单独更新它
为什么 composer update --dry-run 仍提示冲突？
--dry-run 不代表“不检查”，它照常解析全部 composer.json 和已安装 lock 文件，只是不写入磁盘。所以冲突提示和真实执行一模一样。它的价值在于快速验证修改后的 composer.json 是否可行，而非绕过冲突。
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
常见误操作：
- 改了
require但忘了删掉旧版的conflict声明 - 本地
composer.lock已过期，而--dry-run仍基于它计算，导致结果和预期不符 —— 此时应先git checkout -- composer.lock或删 lock 文件再试 - 用了
platform配置（如"php": "8.2"），但当前 PHP 版本其实是 8.1，--dry-run会按配置校验，而非实际环境
依赖树里出现大量 *dev-master* 或 *dev-main* 是隐患吗？
是，而且很典型。这类分支引用意味着 Composer 正在拉取开发中的不稳定代码，它们没有固定版本号，随时可能 break。更麻烦的是，它们往往不遵守 SemVer，composer update 会静默升级到最新 commit，引发难以复现的问题。
排查方式：
- 运行
composer show --tree | grep "dev-"快速定位 - 检查这些包的
composer.json是否写了"minimum-stability": "dev"—— 这会让所有未明确指定稳定性的依赖默认走 dev 分支 - 修复建议：把
"minimum-stability": "stable"加进根项目composer.json，并为确实需要 dev 版的包显式写成"vendor/pkg": "dev-main as 1.0.0"
稳定性和可重现性，常常就卡在这一行配置上。
