答案：composer require roave/backward-compatibility-check 失败主因是默认 stability 不匹配，需加 --stability=dev 或临时设 "minimum-stability": "dev"；该工具为 dev-only 静态分析工具，依赖 Git 和 PHP 8.0+，不参与运行时，仅用于发版前 BC break 检测。
composer require roave/backward-compatibility-check 失败怎么办
直接运行 composer require roave/backward-compatibility-check 很可能失败，不是包不存在，而是它被设计为 dev-only 工具，默认不启用 minimum-stability: dev 的项目会拒绝安装。错误提示通常是 Could not find package roave/backward-compatibility-check 或 no matching package found。
必须显式允许开发稳定性：
- 加
--stability=dev参数：composer require roave/backward-compatibility-check --stability=dev - 或先在
composer.json中临时设置："minimum-stability": "dev"，再运行require - 装完建议还原
minimum-stability（若线上项目不允许 dev 包），因为该工具只在 CI 或本地检查时用，不参与运行时
为什么 roave/backward-compatibility-check 不能直接用于生产环境依赖
它不是运行时库，而是静态分析工具：不提供 API、不注册自动加载、不被 require 加载执行。它的作用是在两个 Git tag（如 v1.2.0 → v1.3.0）之间比对代码变更，识别是否引入了 BC break（比如方法签名修改、类删除、接口变更）。
关键限制：
- 必须配合 Git —— 它读取
git diff和git tag，没 Git 仓库会报错 - 只支持 PHP 8.0+，低于此版本会跳过或报解析错误
- 不检查运行时兼容性（如扩展缺失、PHP 配置差异），只做 AST 级语义分析
- 输出结果是文本报告，需人工判断或接入 CI 脚本做 exit code 判断（
0表示无 break，非0表示有）
如何用它检查你自己的包是否破坏向后兼容性
典型使用场景：发版前验证从 v2.5.0 到 v2.6.0 是否安全。步骤如下：
- 确保当前分支已打新 tag：
git tag v2.6.0 - 运行命令：
vendor/bin/roave-backward-compatibility-check --from=v2.5.0 --to=v2.6.0 - 若输出含
Method ... removed或Parameter ... changed type，说明有 break；若只输出No BC breaks detected，可放心发布 - 注意：
--from和--to必须是真实存在的 Git tag，不能是分支名或 commit hash（除非加--use-commit-refs）
和 composer prohibits / why-not 的定位区别在哪
roave/backward-compatibility-check 解决的是「我改了代码，会不会让别人用不了」；而 composer prohibits 或 why-not 解决的是「我想装某个包，为什么装不上」——前者面向发布者，后者面向使用者。
容易混淆的点：
- 它不分析
composer.json里的require约束，也不管symfony/console版本冲突 - 它不读
composer.lock，只读源码和 Git 历史 - 如果你的包依赖了
monolog/monolog:^3.0，但自己删了一个 public method，roave会报 break；而composer update不会报错，因为约束仍满足
真正要覆盖全链路兼容性，得把 roave（代码层）、composer prohibits（依赖层）、roadrunner-php/version-checker（运行时环境层）三者配合使用——每个环节卡点不同，漏掉一个就可能上线后踩坑。
