电商人每天都在用，比如某猫某狗等，电商系统的设计看似复杂其实很简单，而且看似简单其实很复杂，在它的设计中，需要考虑的问题还是很多的。上一章我们讲了运费的一些规则，以及如何在数据库表中进行设计。本章讲的是如何计算运费和获取我们在上一篇文章中建立的数据。获取商品绑定哪个发货模板的表$templateId=Product::where('id',$product)->value('template_id');如果（$模板==0）返回[]；指定的商品可能会用到一些规则，比如指定区域包邮是否满足某些条件，需要多少运费或者包邮的条件有多少，我们需要保证所有的规则都能被检索到，同时提高其计算速度。在计算之前，你应该想好几种可能，然后选择它们的优先级，就像有三个不同颜色的球，有很多种方法可以放在一起。我记得这应该是一道小学数学题。比起就近原则，这道面试题想必大家都做过。对一个打乱后的字符串进行排序，按照快速排序、选择排序、插入排序、冒泡排序等经典方法进行排序，当然我们不说排序，我们想通过这类算法来思考如何查询我们想要的信息以快速的方式。排序算法合并一个核心点，通过比较来执行。不管是从中间算起，还是从头算起，还是从尾算起，都是对字符串本身的呈现方式的一种猜测。那么我们应该从哪里开始“整理”运费计算呢？根据业务，我们首先考虑是否包邮、指定区域运费、是否满足指定条件这三个规则。他们的大多数优先事项都是这样的。满足指定条件时>指定区域运费>是否包邮1、满足指定条件时，不计算指定区域条件和是否包邮。2.满足指定区域条件的，不判断是否包邮。实战演示为伪代码。这种计算一定不能交给前端计算。会有很多安全问题，比如数据篡改等，懒惰的后端不是好的后端。当我们得到templateId后，我们可以在表product_template_config中查询它的关联规则，这是一个一对多的数据列，也就是说会查询多个item。首先，我们将查询指定的条件。selectcount(1)product_template_configwheretemplate_id=$templateId是否有指定条件。当有指定的条件时，就会计算出来。例如，达到指定金额，运费固定，达到指定金额。运费的计算很简单。小学学过~商品数量*商品单价>指定数量=运费如果没有指定条件，则查询指定城市的运费。城市我们是用json存储的，条目会有多个，那么for是必然的，所以你肯定会说，城市多了不会导致效率低下吧？任何功能都必须基于实际业务。除了西藏、新疆和偏远地区，会有商家针对每个城市设置不同的运费吗？然后我们将使用两种方法。第一种：死循环方法{退货价格;}}第二种：模糊查询select*from`product_template_config`wherecitylike"%北京%"like有时会导致索引失败。特别注意结尾。如果以上两条规则都不满足，那就回到最简单的，自定义运费和是否免费，如果自定义运费，则以最终运费为准，如果是包邮，返回0即可。流程图如下。一些思绪到此为止，我们的货运模板的设计和实战就结束了。当然，这只是一种设计思路。使用这种方法不能承受访问的影响。我只是提供思路。最后给出一些感想，大家不妨实践一下。1.搜索优先级由我们预先设置。我们可以每天定时分析某个商户的设置习惯。比如商家经常会设置免运费，那么我们可以改变优先计算的地点。2、对于并发量太大的应用，为什么不用redis？唯一改变的是数据结构~3.是否有更多根据用户购物习惯计算运费的做法？4.考虑如果有免运费券或者运费折扣券应该添加到哪个流程？任何简单的功能都会随着应用的不断迭代而变得不再简单。期待您的最佳实践。谢谢
