array_count_values()用于一维数组值频次统计，GROUP BY适合大数据量数据库实时聚合，array_reduce()适用于自定义复杂统计逻辑。
用 array_count_values() 统计数组中值的出现次数
这是最直接、最轻量的统计方式，适合处理已加载到内存的离散数据（比如日志行为、用户选择、标签列表）。它只接受一维数组，返回一个以原数组值为键、出现次数为值的新数组。
常见错误是传入多维数组或 null/false 导致警告；也有人误以为它能按条件过滤，其实它不做任何逻辑判断，纯计数。
- 确保输入是普通索引或关联一维数组，嵌套需先扁平化（可用
array_merge(...$arr)或递归提取） - 字符串和数字在键比较时会类型转换，
'1'和1会被视为相同键，如需严格区分，先统一转为字符串再统计 - 对大数组（>10 万项）性能尚可，但若只是想统计满足某条件的个数，用
array_filter()+count()更清晰
$actions = ['login', 'search', 'login', 'logout', 'search', 'login']; $result = array_count_values($actions); // ['login' => 3, 'search' => 2, 'logout' => 1]
用 GROUP BY 在 MySQL 查询中实时聚合
当数据存在数据库且量级较大（比如百万级订单表），绝不要把全量数据 SELECT * 拉到 PHP 再统计——这浪费内存、网络和时间。直接让数据库做聚合是最稳妥的做法。
典型坑是忘记加索引导致 GROUP BY 变慢，或者在 HAVING 中误用未聚合字段引发 SQL 错误。
立即学习“PHP免费学习笔记（深入）”；
- 统计字段（如
status）必须建索引，尤其是高基数字段（如用户 ID）不适合直接GROUP BY，考虑预计算或分桶 -
HAVING只能跟聚合结果（如COUNT(*) > 10），不能写WHERE status = 'paid'这类条件——那是WHERE的事 - PHP 中用
PDO::FETCH_ASSOC获取结果，避免用数字索引依赖字段顺序
$pdo->query("SELECT status, COUNT(*) as cnt FROM orders WHERE created_at > '2024-01-01' GROUP BY status HAVING cnt > 5");
用 array_reduce() 自定义复杂统计逻辑
当统计规则不是简单计数，比如“统计每个用户的平均下单金额，但排除金额为 0 的订单”，这时 array_count_values() 不够用，而 SQL 又太重（比如数据来自 API 或临时数组），array_reduce() 就很合适。
容易出错的是初始值类型不匹配，或在回调里修改外部变量导致状态污染。它本质是函数式写法，应保持无副作用。
- 初始值必须与期望返回结构一致：要返回数组就给
[]，要返回对象就给(object)[] - 回调函数中不要直接改原始数据，也不要依赖
$carry以外的变量；如有多个维度统计，可在$carry里组织嵌套结构 - 相比
foreach，它更难调试，建议只在逻辑真正需要链式累积时使用，否则可读性反而下降
$orders = [['user_id' => 1, 'amount' => 99.9], ['user_id' => 1, 'amount' => 0], ['user_id' => 2, 'amount' => 150]];
$result = array_reduce($orders, function($carry, $item) {
if ($item['amount'] <= 0) return $carry;
$uid = $item['user_id'];
$carry[$uid] = ($carry[$uid] ?? 0) + $item['amount'];
return $carry;
}, []);
注意浮点数精度和时区对统计结果的影响
看似和统计无关，但实际踩坑最多：用 strtotime('today') 做日期分组时，如果服务器时区和业务时区不一致，会导致某天的数据被切到两天；用 float 做金额累加，小数位误差累积后对不上账。
这类问题不会报错，只会让结果悄悄偏移，查起来非常耗时。
- 所有时间相关统计，统一用 UTC 存储，PHP 中用
new DateTime('now', new DateTimeZone('UTC'))构造，显示时再转本地时区 - 金额类统计一律用整数（单位：分）或
bcmath函数，避免+、+=直接操作float - 导出统计报表时，检查前端 JS 是否又把时间戳转成本地时间再渲染，造成“明明数据库是 0 点，页面显示成 23 点”
统计功能越往后越依赖数据一致性，而不是代码技巧。上线前务必用真实时间段+真实数据样本跑一遍端到端结果，比看十遍逻辑更重要。
