extra() 的 where 参数不支持 params 参数化，必须用列表形式的 %s 占位符配合列表/元组 params 才生效；tables、order_by、select 均存在 sql 注入风险，应改用 q()、annotate()、白名单校验等安全替代方案。
extra() 的 where 参数不接受 params= 就等于裸写 SQL
extra() 方法的 where 参数本身不自动做参数化，哪怕你写了 params=，Django 也会忽略它——这是最容易被误信的坑。比如 extra(where=["status = %s"], params=[user_status]) 看似安全，但实际 params 在这里完全无效，Django 不会把 %s 替换成参数值。
真正起作用的只有 where 列表里字符串本身是静态的，或者你手动用 %s 占位 + 配合 params（仅限于 extra() 的顶层 params 参数，且只对 where 中的 %s 生效）。
-
extra(where=["status = %s"], params=[user_status])✅ 唯一合法路径，params必须是列表或元组，且%s不能写成%(name)s（SQLite/MySQL 不支持） -
extra(where=[f"status = '{user_status}'"])❌ 等同于字符串拼接，直接注入 -
extra(where=["status = %s"], params={"status": user_status})❌params必须是列表/元组，字典会被静默丢弃
extra(select={}) 里塞变量就是高危操作
select 参数用于向 SELECT 子句注入字段表达式，但它不经过任何安全校验。一旦你把用户输入拼进字符串里，比如 select={"score": f"COALESCE({request.GET.get('col')}, 0)"}，攻击者就能传 col=__class__ 或 col=id IN (SELECT ...)，直接执行任意子查询。
这种写法绕过了所有 ORM 安全机制，且 select_params 只能配合 SortedDict 用在极少数固定结构场景，不适用于动态字段名。
- 禁止用
f"..."、.format()、%拼接select字符串中的任何部分 - 如需动态字段计算，优先改用
annotate()+F()或Case()，它们天然参数化 - 实在要手写 SQL 表达式，必须白名单校验字段名，例如：
if col not in ["price", "discount"]: raise ValueError
extra() 的 tables 和 order_by 同样不免疫注入
tables 和 order_by 都是原始 SQL 片段拼接点，Django 对它们不做任何转义或参数化。比如 tables=[f"myapp_user_{suffix}"] 或 order_by=[f"{field} DESC"]，只要 suffix 或 field 来自用户输入，就等于开放了表名/列名注入入口。
这类注入比值注入更危险：它能跨表读取、触发 UNION 查询、甚至执行 DDL（取决于数据库权限）。
-
tables必须是硬编码字符串或白名单枚举，不可动态生成 -
order_by若需用户控制排序字段，先映射到白名单：sort_map = {"name": "first_name", "date": "created_at"}，再用queryset.order_by(sort_map.get(request.GET.get("sort"), "id")) - 避免用
extra(order_by=[...])，改用链式order_by()——它支持参数化字段名校验
为什么不用 extra() 更安全
extra() 是 Django ORM 中最易出错的接口之一：它绕过查询编译器、不兼容多数据库、无法被 QuerySet 缓存识别，且每个参数都是独立拼接点。2026 年的主流实践已明确倾向用组合式替代方案。
绝大多数原本靠 extra() 实现的需求，现在都有更安全、更可维护的写法。
- 动态 WHERE 条件 → 用
Q()组合：Q(title__icontains=q) | Q(content__icontains=q) - 复杂字段计算 → 用
annotate()+Func()或数据库函数封装类 - JOIN 多表 → 用
select_related()/prefetch_related()或显式inner_join（Django 4.2+ 支持） - 真需要原生 SQL → 优先走
raw()（支持params=）或connection.cursor().execute(sql, params)，别卡在extra()上
extra() 的存在意义正在快速萎缩；你现在写的每一行 extra()，都在增加未来某次升级或迁移时的排查成本。
