电商大伙每天都在用，类似某猫，某狗等。
电商系统设计看似复杂又很简单，看似简单又很复杂
本章适合初中级工程师细看，大佬请随意

前言

在订单系统中，运费模板是其中一个重要组成部分，看似简单的一个设置，在其内的设计中，要考虑的问题还是很多滴，上一章我们讲了运费的一些规则以及在数据库表中如何设计，本章聊聊如何计算运费

获取

通过上一篇文章我们建立的数据表获取该商品绑定的哪一个运费模版

$templateId = Product::where('id',$product)->value('template_id');
if($template == 0) return [];

指定商品或许会使用多项规则，例如像这样

• 是否包邮
• 指定地区运费
• 达成某种条件下运费多少或者包邮

那这么多条件，我们要保证所有的规则全部都可以检索到，并且还要提升其计算速度。

在计算前，应当想好有几种可能性，再选择其优先级，就像有

三个不同颜色的球，拼凑的方法有多种一样

我记得这应该是一道小学的数学题。

就近原则

相比大家肯定做过这道面试题

把一份打乱的字符串，进行排序

那按照经典的方式

• 快速排序
• 选择排序
• 插入排序
• 冒泡排序

当然，我们不讲排序，我们是要通过这类算法去思考如何以快速的方式去查询到我们想要的信息。

排序算法归并与一点核心，就是通过比较的方式进行，无论是从中间开始进行计算，还是从头或者从尾开始，都是通过对字符串本身要呈现方式的一种猜测。

那我们对于运费计算，应该从什么位置开始“排序”呢？

根据业务，首先我们考虑关于是否包邮、指定地区运费、达成指定条件这三种规则，他们的优先级大多是这样的。

达成指定条件 > 指定地区运费 > 是否包邮

一、达成指定条件就不在计算指定地区条件和是否包邮
二、达成指定地区条件就不判断是否包邮

思路是不是清晰了一点呢，那么我们上代码

实战

演示为伪代码，这类计算肯定不能交给前端去计算，会出现很多安全问题，例如数据被篡改等等，偷懒的后端不是一个好后端

当我们获取templateId后，在表product_template_config中查询其关联的规则，这是一个一对多的数据列，意味着会查询出多条，首先我们先查询指定条件。

select count(1) product_template_config where template_id = $templateId and 是否有指定条件

当有指定条件则进行计算，例如

• 达成指定金额，运费固定
• 达成指定金额，运费多少

计算就简单了，小学就学过的嘛～

商品数量*商品单价 > 指定金额 = 运费

如果没有指定条件，则去查询指定城市运费，城市我们使用的是json存储，会有多条，免不了for，这样你肯定会说了，那很多个城市不会导致效率低嘛？

做任何功能都要以实际业务出发，除了西藏、新疆及偏远地区，会有商家一个市一个市设置不同运费的嘛😂，那我们就使用二种方式

第一种：死循环法

$list = "select * from `product_template_config` where template_id = $templateId";
$city = [];
for($list){
   if($list->city == "北京市"){
        return price;
   }
}

第二种：模糊查询

select * from `product_template_config` where city like "%北京市%"

like有时会导致索引失效，要特别注意

最后如果以上两种规则都不满足，则就回到最简单都自定义运费和是否包邮，自定义运费的话就计算最终运费，包邮的话，直接return 0就完事喽。

流程图如下

一些思考

至此，我们运费模版的设计和实战就到此结束了。

当然这仅仅是设计上的思路，使用该方法是承受不住访问冲击的，我仅仅提供思路而已。

最后我给一些思考，你不妨实践下。

1.检索优先级是我们预先设定的，可以每天定时去分析某个商家的设置习惯，例如商家经常都是设置包邮，那我们优先级的计算可以更换下位置。

2.对于并发过大的应用，不妨使用redis试试呢？变化的仅仅是数据结构～

3.根据用户购物习惯，去计算运费，有没有更多的实践呢？

4.考虑如果有免运费卷，或者运费优惠卷，应该加在哪个流程内呢？

任何一个简单的功能，在应用不断迭代中，都会变的不再简单。期待你们的最佳实践。

致谢

感谢你的关注，希望本篇文章可以帮到你，谢谢。