ThinkPHP聚合查询由数据库执行而非PHP计算，字段类型错误（如VARCHAR存金额）或索引缺失会导致sum返回0、科学计数法或查询慢；分组统计需显式field()并带as别名；JSON接口须用return json()且字段名、时间格式、空数据需与前端严格匹配。
Db::name('order')->sum('amount') 这类聚合查询不是“PHP 算出来的”，而是直接生成 SQL 交给数据库执行；用错方法或字段类型不匹配，结果就离谱——比如 sum() 返回 0 或科学计数法，八成是字段存成了 VARCHAR。
聚合函数怎么用才不返回 0 或 NaN
ThinkPHP 的 count()、sum()、avg() 都不走 PHP 循环，但行为受字段定义和调用方式影响：
-
count('id')会跳过NULL值，count(*)不会；想统计非空记录数，得确认字段是否允许为NULL -
sum('amount')对VARCHAR字段求和，MySQL 默认转成 0（如'123.45元'→ 0），必须确保字段类型是DECIMAL或FLOAT - 带条件时别漏
where()：例如查昨日销售额，写成sum('amount')->whereTime('create_time', 'yesterday')，而不是先select()再 PHP 循环过滤 - TP6 返回值是原生 PHP 数字类型（
int/float），不用intval()强转；但如果前端要 JSON，注意float可能精度丢失，可改用number_format($val, 2)格式化后进数组
GROUP BY 统计必须手写原生 SQL 吗
不用。ThinkPHP 支持链式 group() + field()，但有硬性约束：
-
field()必须显式列出所有字段，包括分组字段和聚合字段，且聚合字段必须带as别名：field('status, count(*) as total, sum(amount) as amount_total') - 分组字段含中文或特殊字符（如
category_name）时，要用反引号包裹：field('`category_name`, count(*) as total')，否则 SQL 报错 - 别在
group()后接count()——那统计的是“有多少个分组”，不是“每个分组多少条”；要每个分组的汇总，必须用select() - TP5.1 模型调用时，若模型设置了
autoWriteTimestamp，可能干扰字段映射，建议用Db::table()直接查
报表接口返回 JSON，为什么 ECharts 渲染失败
70% 的报错不是数据逻辑问题，而是 HTTP 层低级错误：
立即学习“PHP免费学习笔记（深入）”；
- 没用
return json(...)（TP6）或return $this->success(...)（TP5.1），而是echo json_encode(...) + exit，导致Content-Type是text/html，前端 fetch 拿到的是解析失败的 Promise - 字段名和前端 JS 不一致：后端返回
['xAxis' => [...], 'series' => [...]]，前端却写res.data.categories，白屏不报错 - 时间字段没处理：数据库查出的
create_time是'2026-05-14 10:23:45'，ECharts 的xAxis.type = 'time'要求毫秒时间戳，得用strtotime($v) * 1000转换 - 空数据没兜底：聚合结果为空数组时，
array_column([], 'month')返回空数组，但 ECharts 会静默失败；建议加判断：if (empty($data)) { return json(['xAxis' => [], 'series' => []]); }
统计慢？先看 SQL 有没有走索引
别急着优化 PHP，90% 的慢报表卡在 SQL 没走索引：
- 用
Db::getLastSql()拿真实 SQL（不是buildSql()），粘贴到 MySQL 客户端执行EXPLAIN；重点看type（要是ref或range）、key（是否命中索引）、rows（扫描行数） -
type = ALL或key = NULL，说明 WHERE 条件字段没建索引，或者写了WHERE DATE(create_time) = '2026-05-14'这种带函数的表达式，索引失效 - 高频统计（如“用户订单总数”）别每次
count(*)，改成冗余字段 + 模型事件更新；事务里必须保证主表和计数字段一起提交 - 多维分组（如按日+地区+品类）别靠实时
group()，建预计算表sales_daily，用定时任务每晚跑一次聚合写入
真正卡住的地方往往不在聚合函数本身，而在字段类型、SQL 索引、JSON 字段命名这些细节上——少一个反引号，多一个字符串字段，慢三秒，错一行。
