model.query()本身不支持sum、count、avg等聚合函数，它只是orm查询构造器，未提供聚合方法；真要聚合需用对应orm的aggregate()、annotate()或func.sum()等专用接口。
model.query() 支持哪些聚合函数
直接说结论：model.query() 本身不支持 sum、count、avg 这类 SQL 聚合函数——它只是 ORM 层的查询构造器，底层调用的是数据库驱动的原生查询，但默认走的是「查记录」路径，不是「查聚合值」路径。
常见错误现象是写成这样然后报错或返回空：
model.query().sum('price')
这会抛出 AttributeError: 'Query' object has no attribute 'sum'（Django 风格）或静默忽略（某些轻量 ORM），因为 query() 返回的是未执行的查询对象，没挂聚合方法。
- 真要聚合，得先确认你用的 ORM 是否在
query()后提供了aggregate()、annotate()或values().annotate()等接口 - 如果是 Django，正确入口是
model.objects.aggregate()或.annotate()，不是model.query() - 如果是 SQLAlchemy，得用
func.sum()+session.query().scalar()或.all() - 如果是自研 ORM 或低代码平台的
model.query()，必须查文档看它是否封装了.count()/.sum(field)这类快捷方法——别猜，90% 情况下不支持
count() 为什么有时快有时慢
count() 表面简单，实际行为差异极大，取决于你怎么调用和底层是否走索引。
使用场景不同，生成的 SQL 完全不一样：
-
model.objects.count()（Django）→ 生成SELECT COUNT(*) FROM table，通常最快 -
model.objects.filter(...).count()→ 加 WHERE，如果条件字段无索引，可能触发全表扫描 -
len(model.objects.filter(...))→ 先取全部数据再算长度，内存爆、网络慢、数据库压垮三连 - 某些 ORM 的
query().count()如果没重载，可能退化成先 fetch 再 len()，务必验证生成的 SQL
性能影响明显：有索引的 status = 'active' 条件 count 可能 5ms；没索引的 content__icontains='xxx' 可能 2s+ 且锁表。
sum() 和 avg() 必须处理 NULL 和空结果
聚合函数对空数据集返回 None，不是 0；对含 NULL 字段的行，默认跳过——这点容易被忽略，导致业务逻辑误判。
比如统计订单总金额：
model.objects.aggregate(total=Sum('amount'))
返回的是 {'total': None}，而不是 {'total': 0}。前端直接 total + 100 就变成 NaN。
- 安全写法：用
Coalesce(Sum('amount'), 0)（Django）或COALESCE(SUM(amount), 0)（原生 SQL） -
avg()同理，空结果也是None，且分母是「非 NULL 行数」，不是总行数 - 如果字段允许 NULL，又没加
default=0或数据库约束，聚合前最好先.filter(amount__isnull=False)
group by 场景下 annotate() 和 values() 的顺序不能错
Django 用户最常踩的坑：想按日期统计每日订单数，写成：
Order.objects.annotate(day=F('created_at__date')).values('day').annotate(count=Count('id'))
看着合理，但实际会报错或结果错乱——因为 annotate() 在 values() 前，会导致 GROUP BY 里混入多余字段（如主键），破坏分组语义。
正确顺序永远是：values() 先定分组维度，再 annotate() 算聚合值：
Order.objects.values('created_at__date').annotate(count=Count('id')).order_by('created_at__date')
- SQL 层面对应
GROUP BY created_at::date，干净明确 - 如果还想要其他字段（比如用户邮箱），必须出现在
values()里，否则数据库报错 - SQLAlchemy 类似，
group_by()必须在add_columns()和having()之前明确声明
顺序错一点，结果就偏一点，而且不容易一眼发现——尤其当测试数据少、分组结果巧合一致时。
