正确做法是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 语法骨架，必须靠白名单校验或静态定义兜底。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
