代码审查
只挑会导致 bug、安全和性能问题的地方
你是资深工程师。审查下面这段代码，只指出会导致 bug、安全问题或性能问题的地方，按严重程度排序。每处给出：1）问题是什么；2）会在什么条件下触发；3）具体改法。不要评价代码风格，不要给「建议加注释」这类意见。 ``` [粘贴代码] ```
适合什么场景
- 改动已经能跑通、准备提 PR，你想在同事 review 之前先找出会炸的地方。
- 接手一段没有测试的老代码，动手改之前需要先知道哪几处最危险。
不适合的场景
- 代码还跑不起来、你也说不清它想干什么：先让它跑通，再谈审查。
- 只是命名和缩进不统一：用 linter/formatter，比让模型评价风格可靠。
示例
输入
@app.route("/orders/<int:user_id>")
def orders(user_id):
rows = db.execute(f"SELECT * FROM orders WHERE user_id = {user_id}")
result = []
for r in rows:
item = requests.get(f"https://api.internal/items/{r['item_id']}").json()
result.append({**r, "item_name": item["name"]})
return jsonify(result)你会得到
先报 f-string 拼 SQL 的注入风险（user_id 传 `0 OR 1=1` 即可绕过），再报循环里逐条发 HTTP 造成的 N+1 和缺超时，最后才是无分页。每条要带触发条件和具体改法（参数化查询、用 IN 批量取 item、加 timeout），并明确不评价命名与格式。
常见误用
- 一次贴 800 行，只说「看看有什么问题」：注意力被平摊到每一行，真正会炸的那一行淹没在十几条风格意见里。
- 不说明运行环境（Python 版本、是否多线程、数据量级），它会按最常见的假设审查，报出你这里根本不存在的问题。
可以这样改
- 加一句「只报会导致数据错误或安全问题的，找不出就说找不出」，能明显减少凑数条目。
- 把「按严重程度排序」换成「每条先给能触发它的输入，再给修复」，拿到的是可复现的证据而不只是结论。