最轻量方式是模型中重写getattribute实现动态聚合，适合单次低频场景；需注意n+1问题、不可用于where/orderby；高频场景应冗余字段+观察者维护一致性。
用 getAttribute 动态计算关联聚合值
直接在模型里重写 getAttribute 是最轻量的方式，适合单次、低频、无需缓存的汇总场景。比如想查一个订单的总商品数量，但不想额外加数据库字段或预加载全部子项。
它绕过 Eloquent 的原始属性访问逻辑，在取值时实时调用关联查询。注意：这会触发 N+1（如果批量遍历模型且未预加载），且无法用于 where 或排序。
- 在模型中定义
getTotalItemsAttribute方法，Eloquent 会自动识别为访问器 - 方法体内用
$this->items()->sum('quantity')，而非$this->items->sum('quantity')——后者强制加载全部关联记录，性能差得多 - 如果关联关系已预加载（如用
with('items')），可改用集合操作避免重复查询：$this->items->sum('quantity')
用 withCount + selectRaw 在查询时聚合
需要在列表页展示每个父模型的统计值（如“用户发帖数”“文章评论总数”），且要求能 orderBy 或分页筛选，必须把聚合下推到 SQL 层。
withCount 本身只支持计数，但配合 selectRaw 和子查询就能实现求和、平均、最大值等。关键点是别让子查询暴露在主表外层，否则 MySQL 8.0+ 可能报错“Invalid use of group function”。
- 正确写法：
selectRaw('COALESCE((SELECT SUM(quantity) FROM items WHERE items.order_id = orders.id), 0) as total_items') - 错误写法：
selectRaw('SUM(items.quantity)')+leftJoin—— 没GROUP BY就会出错，加了又影响主查询结构 - 若需多个聚合字段，每个都用独立子查询，避免 JOIN 导致笛卡尔积放大
用 HasOneThrough 或自定义关系模拟“穿透聚合”
当要跨两层关联取聚合值（比如从 User 查所有 Order 下 Item 的总价），Eloquent 原生不支持直接 user->items()->sum('price')。强行链式调用会报错 “Call to undefined relationship”。
这时候不能硬套 hasManyThrough（它只支持一对一/一对多穿透，且要求中间表有外键），而应手动定义一个只读关系，返回 Builder 实例：
- 在 User 模型中定义方法：
public function allItems()，返回Item::query()->whereIn('order_id', $this->orders()->pluck('id')) - 后续可链式调用：
$user->allItems()->sum('price')或$user->allItems()->avg('price') - 注意
pluck('id')在大数据量时可能超 MySQL 参数max_allowed_packet，此时应改用子查询：whereExists(...)
缓存聚合结果避免重复计算
高频访问的聚合值（如商品销量、文章阅读数）一旦每次请求都查库，DB 压力会陡增。Eloquent 自带的 remember 不适用——它缓存整个模型，不是单个属性。
真正有效的做法是把聚合结果单独落库（冗余字段），用观察者或数据库触发器维护一致性。临时缓存只能作为兜底，不能替代最终一致性设计。
- 加字段如
cached_total_items到 orders 表，用OrderObserver在created/updated/deleted时更新 - 不要用 Redis 缓存
user:123:total_spent这类键——失效难管理，且无法原子更新 - 如果业务允许几秒延迟，可用
Cache::remember('order_456_total', 30, fn() => ...)，但必须搭配模型事件清除缓存
聚合逻辑越靠近数据源（SQL 层或数据库约束），越不容易出错；越往应用层堆 PHP 循环和集合操作，越容易漏掉空值、类型转换、权限过滤这些细节。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
