最快的 GitHub Actions 接入方式，是在仓库根目录运行 npx react-doctor@latest ci install。安装器会创建或更新 .github/workflows/react-doctor.yml，让拉取请求触发扫描；默认是建议模式，只报告新引入的问题，不会直接拦住合并。

最短落地路线

1. 先在本地执行 npx react-doctor@latest --verbose --scope changed，确认项目能被识别。
2. 运行 npx react-doctor@latest ci install，审阅新增的工作流文件。
3. 提交到功能分支并发起拉取请求，用一次真实改动验证权限、评论与状态检查。

工作流需要完整 Git 历史来寻找目标分支的合并基线，因此官方脚手架把 checkout 的 fetch-depth 设为 0。若手工精简这项配置，扫描可能退回到报告变更文件里的既有问题，噪声会明显增加。

拉取请求里会出现什么

位置	反馈	用途
会话区	可更新的汇总评论	查看分数、数量与本次变化
代码差异	行内审查提示	直接定位规则和文件行
检查日志	完整扫描输出	排查权限、基线与命令参数

官方 Action 还需要读取仓库内容，并写入拉取请求、问题和提交状态。组织仓库若限制第三方 Action 或写权限，应先让仓库管理员核对策略；权限不足时，扫描可能完成，却无法把评论或状态写回 GitHub。

把告警变成门禁

默认 blocking: none 适合先观察一到两周。团队确认误报和历史债务可控后，再运行 npx react-doctor@latest ci config --blocking error，让新增 error 导致检查失败；改成 warning 会连新增 warning 一起拦截。范围可保留 changed，也可根据团队目标改为 full，二者的噪声和治理成本不同。

非 GitHub 流水线怎么接

扫描器本身是 CLI，GitLab CI、CircleCI、Jenkins 或普通脚本都能读取退出码。阻断级问题存在时返回 1，否则返回 0。GitLab 可先生成脚手架：

npx react-doctor@latest ci install --provider gitlab-ci

三处参数决定结果

scope 决定扫描全量还是变更，base 决定与哪个分支比较，blocking 决定何种级别返回失败。单仓多项目还要核对 directory 与 project。先让建议模式积累真实数据，再逐级收紧门禁，团队更容易分辨新问题与旧债，也不会因为一次接入就把正常合并全部卡住。