django orm中raw()是唯一带模型映射的原生sql安全入口，但必须用params列表传参且仅支持%s位置占位符；extra()和cursor.execute()无自动防护，字符串拼接即导致注入。
Django ORM 执行原生 SQL 时，raw() 是唯一带模型映射的安全入口；extra() 和直接 cursor.execute() 不做任何防护，拼字符串即失守。
用 raw() 执行原生查询必须配 params 列表
raw() 看似“原生”，但只要严格走 params 传参，底层仍走参数化查询。它只支持位置占位符 %s，不支持 {} 或 %(name)s（SQLite/MySQL 不认命名参数）。
-
params必须是列表或元组，不能是字典（除非你明确只用 PostgreSQL 且确认驱动支持） - 占位符数量和顺序必须与
params严格一致，错一位就可能查错字段或报IndexError - 错误示例：
User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{u}'")—— 字符串拼接，完全绕过防护 - 正确示例：
User.objects.raw("SELECT * FROM auth_user WHERE username = %s", params=[u])
extra() 的 where 参数根本不接受 params
extra() 是个陷阱：它声明了 params 参数，但 Django 实际上会忽略它——where=["status = %s"] 中的 %s 被当作文本字面量处理，不是占位符。
- 所有
extra()的字符串参数（where、tables、select）都禁止含用户输入 - 想动态加条件？改用
Q对象组合：Q(username__icontains=u) | Q(email__endswith='@example.com') - 真要写原生 WHERE 子句，优先用
raw()，别硬塞进extra()
cursor.execute() 必须手动确保参数化，且注意驱动兼容性
一旦走到 connection.cursor()，Django 的所有防护彻底失效，完全依赖你对数据库驱动行为的理解。
- 必须用
cursor.execute("SELECT ... WHERE name = %s", [name])形式，绝不能"' + name + '"拼接 - MySQLdb（旧版）对空值或二进制数据的参数化有边界 case，推荐升级到
mysqlclient - 返回结果默认是元组，需手动转字典：
dictfetchall(cursor)这类辅助函数得自己写或抄 Django 官方示例 - 执行写操作（
INSERT/UPDATE）同样适用该规则，且要注意事务控制
RawSQL 在 annotate() 中必须手动参数化 LIKE
RawSQL 表达式用于 annotate() 或 filter() 时，params 只绑定表达式内部的占位符，不会覆盖整个 SQL 字符串。
- 错误：
annotate(score=RawSQL(f"CASE WHEN title LIKE '%{search}%' THEN 1 ELSE 0 END"))——%和_未转义，且字符串拼接 - 正确：
RawSQL("CASE WHEN title LIKE %s THEN 1 ELSE 0 END", params=[f"%{search}%"]) - 更优：
Case(When(title__icontains=search, then=1), output_field=IntegerField())—— ORM 原生表达式自动处理转义、索引优化和数据库兼容性 - 若必须用原生
LIKE，调用connection.ops.prep_for_like_query(search)手动转义通配符
最常被忽略的是：字段名、排序字段、分组字段这些“结构参数”永远不走参数绑定。哪怕你 raw() 写得再规范，order_by(request.GET.get('o')) 没白名单校验，照样可能被用来触发全表扫描或敏感字段暴露。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
