适用场景
提交 PR 前想自查代码,或者 review 别人的代码时需要一个系统化的检查框架。
模板正文
1 2 3 4 5
| 请对以下代码进行 Code Review。
代码语言:【比如"TypeScript/Python/Go"】 代码用途:【比如"用户登录接口""文件上传模块"】 代码(直接粘贴):
|
【粘贴代码】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
| 请从以下维度审查:
1. 正确性 - 逻辑是否正确? - 边界条件是否处理了? - 空值/null/undefined 检查
2. 安全性 - SQL 注入 / XSS / CSRF 风险 - 敏感信息是否泄露(密钥、密码、Token) - 权限校验是否完整
3. 性能 - 有没有不必要的循环/查询? - N+1 查询问题 - 大数据量处理是否合理
4. 可读性 - 命名是否清晰? - 函数是否过长?(超过 50 行考虑拆分) - 注释是否充分且准确?
5. 可维护性 - 是否符合 DRY 原则? - 错误处理是否完善? - 测试覆盖建议
输出格式: - 按优先级排列(P1 严重问题 → P3 建议改进) - 每个问题给出:问题描述 + 具体位置 + 修改建议 - 最后给出整体评价(LGTM / 需修改 / 需重构)
|
使用示例
输入(Python 片段):
1 2 3 4
| def get_user(id): query = f"SELECT * FROM users WHERE id = {id}" result = db.execute(query) return result
|
输出:
P1 - 严重
SQL 注入风险
- 位置:第 2 行
f"SELECT * FROM users WHERE id = {id}"
- 问题:使用 f-string 拼接 SQL,存在注入风险
- 修复:
db.execute("SELECT * FROM users WHERE id = %s", (id,))
P2 - 建议修改
参数名遮蔽内置函数
id 遮蔽了 Python 内置函数 id(),建议改为 user_id
小提示
- 自查比被别人查出来好一万倍
- Review 的重点是”能不能在线上稳定运行”,不是”代码好不好看”
- 多关注错误处理和边界条件,这些是线上事故的主要来源
nmdft
25+ Prompt 模板、4 个 Agent Skills、4 套自动化流程、工具推荐——帮你用 AI 建立一个人的公司
Follow Me