在Django中执行原生SQL时，防SQL注入的规则其实很明确：raw()必须用params=传参，而且只认%s占位符，绝对不能用字符串拼接；extra()的where等参数同样靠params绑定；RawSQL混入用户输入必须手动参数化；至于字段名这类结构化参数，参数化机制根本救不了，只能靠白名单校验。这几个点，一个都不能含糊。
raw() 必须用 params= 传参，不能拼字符串
Django的raw()完全绕过了ORM编译器，SQL字符串由你全权负责。只要出现"%s" % user_input或f"WHERE name = '{name}'"，就等于把数据库钥匙递出去了。
raw()只认位置占位符%s，所有后端（PostgreSQL、MySQL、SQLite）都兼容；命名参数如%(name)s在SQLite下会直接报错params必须是列表或元组，不能是字典——除非你明确只跑PostgreSQL且确认驱动支持- 错误示例：
User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'") - 正确写法：
User.objects.raw("SELECT * FROM auth_user WHERE username = %s", params=[username])
extra() 的 where 参数不自动转义，必须走 params
extra()看似像filter()，但它内部的where、tables、joins都是原始字符串拼接点，不经过任何参数化处理。
extra(where=["status = %s"], params=[user_status])是唯一安全路径extra(where=[f"status = '{user_status}'"])和裸写SQL没区别，直接触发注入- 别试图用
connection.ops.adapt_unknown_value()手动转义——难维护、易漏、不跨数据库 - 真需要动态条件，优先改用
Q()组合，或提前定义好字段白名单映射
RawSQL 表达式里混用户输入必须手动参数化
RawSQL用在annotate()或filter()中时，它本身不继承外层QuerySet的参数化机制，params=只绑定它自己SQL内的占位符。
- 错误：
annotate(score=RawSQL(f"CASE WHEN title LIKE '%{search}%' THEN 1 ELSE 0 END"))——search被直接插进字符串 - 正确：
RawSQL("CASE WHEN title LIKE %s THEN 1 ELSE 0 END", params=[f"%{search}%"]) - LIKE模糊匹配还要额外注意通配符转义：用户输入的
%、_会被数据库当语法执行，不算注入但属逻辑漏洞，需用escape参数或__icontains替代 - 更稳妥方案：优先用ORM原生表达式，比如
Case(When(title__icontains=search, then=1), output_field=IntegerField())
cursor.execute() 也得严格参数化
绕过ORM直接用connection.cursor()时，Django不提供任何防护，完全依赖底层驱动的参数化能力。
- 必须用
cursor.execute("SELECT * FROM user WHERE id = %s", [user_id]) - 禁止
cursor.execute(f"SELECT * FROM user WHERE id = {user_id}")或"%s" % user_id - 不同数据库占位符不互通：MySQL/SQLite用
%s，PostgreSQL支持%s和%(name)s，但混用会导致迁移失败 - 如果涉及多数据库部署，统一用位置参数
%s最保险
这里必须强调一点：结构化参数永远不被保护——表名、字段名、ORDER BY、GROUP BY、函数名这些，哪怕你用params=也救不了。它们不属于“值”，而是SQL语法骨架，必须靠白名单校验或静态定义兜底。这才是在Django中安全执行原生SQL的真正底线。
