子查询必须全程参数化，不可拼接用户输入；正确做法是整条sql用execute(sql, params)绑定参数，深层嵌套应拆为多步查询，orm的subquery()也需显式参数化。
SQL子查询里不能直接拼接用户输入
子查询本身不提供参数化入口，WHERE id IN (SELECT user_id FROM logs WHERE type = 'login') 这类写法看着安全，但一旦你把用户传来的 type 值拼进去，比如 'login' OR 1=1，就立刻崩盘。根本原因：子查询在语法上仍是 SQL 字符串的一部分，没经过预编译绑定。
- 所有外部输入（包括 URL 参数、表单字段、API body）必须视为不可信，哪怕它只用于子查询的
WHERE条件或IN列表里 - 不要用字符串格式化（
f"SELECT ... WHERE x = '{user_input}'"）、str.format()或%拼接子查询内容 - ORM 的
.filter(...).subquery()类方法也得小心——如果底层生成 SQL 时用了字符串插值，照样中招
用参数化查询包裹整个子查询语句
多数数据库驱动（如 Python 的 psycopg2、mysql-connector-python）支持对完整 SQL 语句做参数绑定，子查询只是其中一段语法，只要整条语句走 cursor.execute(sql, params)，参数就会被安全转义或绑定到执行计划里。
- 正确写法：
cursor.execute("SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = %s)", ("active",)) - 错误写法：
cursor.execute(f"SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = '{status}')") - PostgreSQL 的
ANY(ARRAY[...])配合%s可安全传入动态列表，比拼接(1,2,3)更可靠
嵌套层级深时，优先拆成两个独立查询
三层以上子查询（比如 SELECT ... FROM (SELECT ... FROM (SELECT ...))）不仅难审计、易出错，还常迫使开发者绕过参数化，改用拼接来“灵活控制结构”。这时不如主动降级：先查内层结果，再用参数化方式带入外层。
- 例如要查“最近登录用户的订单”，别写
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE last_login > (SELECT max(login_time) FROM audit_log WHERE action='login')) - 改成两步：
cursor.execute("SELECT max(login_time) FROM audit_log WHERE action = %s", ("login",))→ 取出时间 → 再查users→ 最后查orders - 虽然多一次 round-trip，但每一步都可控、可测、可加缓存，且彻底避开深层嵌套带来的参数盲区
ORM 中 subquery() 方法的参数陷阱
Django 的 .values('user_id').subquery()、SQLAlchemy 的 select().subquery() 默认不自动参数化子查询里的变量，尤其当你用 where() 传入 f-string 或未校验的变量时，风险和原生 SQL 一样高。
- Django 示例：避免
Subquery(User.objects.filter(status=user_input).values('id'))；应改用Q(status__exact=...)或显式params传参 - SQLAlchemy 示例：用
bindparam('status')定义占位符，再通过connection.execute(stmt, {'status': user_input})执行 - 检查 ORM 生成的最终 SQL（如 Django 的
str(queryset.query)），确认子查询部分没有裸露的引号包裹用户值
最危险的不是不会写子查询，而是以为“用了 ORM 就天然免疫”或者“子查询在括号里就安全了”。参数化必须贯穿整条语句，从最外层 SELECT 到最内层 WHERE，缺一不可。
