Laravel函数接收Model ID与Model实例的方案对比及优劣分析

先看你给出的两个实现：

// 方案一：基于payment_id直接查询数据库求和
function get_total_payment($payment_id){
   return PaymentModel::where('payment_id', $payment_id )->sum('amount');
}

// 方案二：基于传入的集合/查询构建器求和
function get_total_payment($payments){
    return $payments->sum('amount');
}

方案一的优缺点 #

优点

• 大数据场景性能更优：直接在数据库层面执行聚合计算，无需将所有Payment实例加载到PHP内存，内存占用低，数据量越大优势越明显
• 调用门槛低：只需要传入payment_id就能得到结果，不用提前做查询操作，适合仅需求和、不需要关联其他数据的场景
• 逻辑内聚性强：筛选和求和逻辑都封装在函数内部，外部调用者无需关心数据来源，对调用方更友好

缺点

• 功能单一：仅能处理按payment_id筛选的求和需求，无法复用已有的查询结果，若已获取相关payments集合，再调用该函数会重复查库，造成资源浪费
• 灵活性不足：无法适配复杂筛选场景，比如要统计已支付、特定时间范围内的金额，必须修改函数内部的查询条件，改动成本高
• 重构成本高：后续业务规则变化（比如要求仅统计有效支付）时，必须修改函数内部的where条件，所有调用该函数的地方都会受影响

方案二的优缺点 #

优点

• 灵活性极强：无论是多条件过滤、关联查询得到的集合，还是未执行的查询构建器，都能传入该函数求和，适配各类业务场景
• 避免重复查询：若已通过其他业务逻辑获取了payments集合，直接传入即可，无需再次执行数据库请求，节省资源
• 重构友好：后续调整求和的前置数据规则时，仅需修改生成payments集合的代码，求和函数本身无需改动，符合单一职责原则
• 复用性高：同一个函数可处理所有payments集合的求和需求，无需为不同筛选逻辑编写多个求和函数

缺点

• 大数据场景内存压力大：若传入的是已加载的Eloquent集合，所有模型实例都会占用内存，数据量极大时会拖慢PHP进程
• 调用者责任更重：需要调用方确保传入的payments集合逻辑正确，若集合筛选出错，求和结果会直接错误，排查成本更高
• 无法完全利用数据库优化：若传入的是集合，求和在PHP层面完成，无法用到数据库的聚合索引优化，数据量极大时效率不如方案一

内容的提问来源于stack exchange，提问作者Umar Jafar