oefenweb/statistics仅提供基础统计函数，不能直接处理关联数组或海量原始数据；需先用array_column等预处理提取数值字段，再配合phpClickHouse在存储层完成分组聚合，PHP层仅做轻量后处理。
直接用 oefenweb/statistics 就能撑起多维数据统计层，但前提是别把它当“计算器”用——它不处理数据源、不管理维度切片、不缓存中间结果。真正高性能的统计层，是靠组合策略+边界控制+提前降维实现的。
为什么不能直接 foreach + Statistics::mean() 处理原始订单数组
常见错误是把上万条订单记录全 load 进内存，再丢给 Statistics::sum() 或 Statistics::variance() 算。这会触发两次全量遍历：一次 PHP 数组扫描，一次库内循环。更糟的是，oefenweb/statistics 所有方法都要求输入是纯数值数组，而真实订单数据是关联数组（['id'=>1,'amount'=>299.99,'category'=>'electronics']），不做预过滤就会报 Warning: array_sum() expects parameter 1 to be array, null given。
- 必须先用
array_column($orders, 'amount')抽出维度字段，再喂给统计函数 - 若需按
category分组统计，得先array_reduce聚合成['electronics'=>[299.99, 150.00], 'books'=>[39.99]]结构，再对每个子数组调用Statistics::mean() - 避免在循环里反复 new 对象或调用静态方法——
oefenweb/statistics全是静态方法，无实例开销，但频繁调用仍产生函数栈帧压力
如何用 phpClickHouse 替代 PHP 层计算高频指标
日活、小时销售额、Top10商品等实时性要求高的指标，硬扛在 PHP 层算就是自找麻烦。ClickHouse 的 GROUP BY + quantileExact() 比 PHP 循环快两个数量级，且天然支持多维下钻（WHERE date >= '2026-06-01' AND category IN ('A','B')）。
- 用
smi2/phpclickhouse的select()直接查聚合结果，不要fetchRows()拿原始数据回 PHP 再算 - 建物化视图预计算常用组合维度，例如
MATERIALIZED VIEW sales_by_hour_category，避免每次请求都重跑 GROUP BY - PHP 层只做轻量后处理：比如把 ClickHouse 返回的
['hour'=>14,'revenue'=>8423.5]映射成前端需要的折线图数据格式
composer dump-autoload --classmap-authoritative 对统计层的实际影响
统计逻辑常散落在多个 service 类中（SalesAnalyzer、CustomerRetentionCalculator），自动加载效率直接影响并发请求下的 CPU 占用。启用权威类映射后，PHP 不再尝试从文件系统查找未声明的类，而是严格依赖 vendor/composer/autoload_classmap.php 中的预生成路径。
立即学习“PHP免费学习笔记（深入）”；
- 生产环境必须开启：
"optimize-autoloader": true和"classmap-authoritative": true写进composer.json - 如果统计类用了 traits 或动态类名（如
new $className），要确保这些类已被composer dump-autoload扫描到，否则会抛Class not found - 搭配
opcache.preload效果更明显——但注意 preload 文件不能包含任何运行时依赖（如 DB 连接），统计层的初始化逻辑得剥离出去
真正的瓶颈往往不在算法本身，而在数据进出 PHP 进程的路径上：原始数据是否经过冗余字段裁剪？维度分组是否在存储层完成？统计结果有没有被合理缓存（而非每次 HTTP 请求都重算）？这些比选哪个统计库重要得多。
