Q对象必须全部用逻辑运算符连接，不可混用字典式参数；嵌套Q支持复杂括号逻辑；exclude()对Q取反整个表达式；annotate()中需用Count(filter=Q())实现条件聚合；OR跨字段易致索引失效，应结合EXPLAIN优化。
Q对象必须显式使用逻辑运算符
Django的filter()默认是“且”关系，但一旦混用Q对象和普通字段查询，Django会报TypeError: unsupported operand type(s) for |: 'Q' and 'dict'这类错误。根本原因是Q不能直接和字典式参数（如name__icontains='a'）拼接，必须全部转为Q实例再运算。
正确写法是把所有条件都包进Q，再用|（或）、&（与）、~（非）连接：
from django.db.models import Q
qs = MyModel.objects.filter(
Q(status='active') & (Q(title__icontains='bug') | Q(description__icontains='bug'))
)
-
&和|优先级高于普通Python运算符，建议加括号明确分组 - 多个
Q用&组合时，等价于filter(a=x, b=y)，但更利于动态拼接 - 避免写成
Q(status='active') | name__icontains='bug'——后者不是Q，语法直接报错
嵌套Q对象处理多层括号逻辑
当业务规则出现“（A且B）或（C且D且非E）”这类结构时，靠链式filter()无法表达，必须用Q嵌套。常见误区是试图用多个filter()调用模拟括号，结果变成全局“且”关系，逻辑被扭曲。
例如查“已支付且未发货”的订单，或“未支付但创建超24小时的订单”：
立即学习“Python免费学习笔记（深入）”；
Q(
(Q(paid=True) & Q(shipped=False)) |
(Q(paid=False) & Q(created_at__lt=threshold) & ~Q(refunded=True))
)
- 每个子条件块用括号包裹，确保运算顺序可控
-
~Q(...)比Q(...)=False更可靠，尤其对NULL字段（如refunded可能为NULL） - 嵌套过深时可提前赋值变量，提升可读性：
unshipped_active = Q(paid=True) & Q(shipped=False)
Q对象与exclude()、annotate()配合的边界情况
exclude()对Q的支持是“取反整个表达式”，不是逐项取反。比如exclude(Q(a=1) | Q(b=2))等价于WHERE NOT (a=1 OR b=2)，即a!=1 AND b!=2；而exclude(Q(a=1)) | exclude(Q(b=2))语法非法。
在annotate()中直接用Q会报FieldError: Cannot resolve keyword 'Q' into field——因为annotate()需要聚合函数或F表达式，Q只用于过滤上下文。
- 需要条件聚合时，改用
Case+When：Count('id', filter=Q(status='done')) -
exclude(Q(...))内部可含&/|，但外部不能再套逻辑运算符 - 混合
filter()和exclude()时，注意执行顺序：先filter再exclude，类似SQL的WHERE后接AND NOT
性能隐患：Q对象导致数据库索引失效的典型场景
看似简洁的Q(title__icontains='x') | Q(content__icontains='x')在PostgreSQL/MySQL上大概率触发全表扫描。因为OR分支涉及不同字段，优化器很难同时利用title和content的独立索引。
更糟的是Q(tags__name__in=['a','b']) & Q(category__isnull=False)这种跨关联表的Q，可能生成LEFT OUTER JOIN并放大结果集。
- 用
EXPLAIN验证实际执行计划，别依赖Django ORM的“看起来合理” - 高频模糊搜索优先考虑全文检索（
SearchVector）或ES集成，而非icontains堆Q - 关联字段条件尽量收拢到单张表，必要时用
select_related()或prefetch_related()拆解
复杂查询的真正难点不在语法拼接，而在理解每层Q最终编译成什么SQL，以及数据库是否能高效执行它。写完务必看queryset.query和EXPLAIN输出。
