审查拉取请求
- 获取差异。对于 PR 编号，使用
gh pr diff <number>；否则使用git diff origin/main...HEAD。同时阅读 PR 描述（如果存在）：gh pr view <number>。 - 当仅靠差异无法理解时，完整阅读更改的文件。不要审查你未阅读过的代码。
- 按以下顺序检查：
- 正确性： 错误的条件、差一错误、未处理的错误、竞态条件、空/空值输入。
- 测试： 每个行为更改是否都有测试覆盖？没有该更改时测试是否会失败？
- 安全性： 不受信任的输入到达 shell、SQL、文件路径或 HTML；差异中的秘密。
- 兼容性： 更改的公共接口、迁移、配置或环境变量。
- 可读性： 仅那些会拖慢下一位维护者速度的问题。跳过 linter 已覆盖的纯风格偏好。
- 如果测试存在，运行
npm test并诚实地报告结果。
输出格式
## 摘要
用一两句话说明 PR 做了什么以及你的总体意见（批准 / 请求更改 / 评论）。
## 必须修复
- `path/file.js:42` 问题是什么，为什么重要，建议的修复方法。
## 应考虑
- `path/file.js:90` ...
## 锦上添花
- ...
如果某个章节为空，则省略它。为每个发现引用 file:line。不要杜撰问题：如果更改没有问题，请在摘要中说明。除非用户要求，否则不要向 GitHub 发布评论。