"满 99 包邮，怎么这单收了 12 块运费？"这类问题几乎每个商城都会遇到，而且解释起来特别费劲，因为运费算错很少是程序坏了，基本是规则叠加的时候哪一层没配对。
先把运费模板的结构理清楚。它通常是这么几层摞起来的：计费方式（按件数、按重量、按体积），区域（全国默认价 + 指定地区单独设价，偏远地区一般更贵），首件或首重的价格加续件续重的价格，包邮门槛（满多少钱、满多少件、或者指定地区不参与包邮），最后是这批商品里如果有多个不同模板，系统怎么合并。错的地方八成在这五层里的某一层的"优先级"上，而不是数字填错。
最典型的是商品没绑模板。新增的商品如果没指定运费模板，就走了系统默认的那一套，而默认模板经常是 0 元或者一个很久没改的旧价格，于是出现"这件商品莫名其妙包邮了"。批量导入商品时尤其容易漏这一列，导完一定要抽查几个。
第二种是计费方式和填的数据不匹配。选了按重量计费，但商品的重量字段是空的，系统拿 0 去乘，运费自然算成 0。选了按体积计费而体积没填，结果一样。这类问题在测试环境用标准商品是测不出来的，因为测试数据通常填得很全。
第三种是区域规则打架。一个客户同时命中"全国"和"新疆"两条规则，系统一般取更具体的那条，但如果你把顺序或者层级配错了，可能就取了默认价。还有的情况是只设了"不包邮地区"，忘了他同时也在"满额包邮"的覆盖范围里，两种规则谁优先，不同系统实现不一样，得自己在后台实际下一单验证。
第四种最容易被忽略：优惠和运费的计算顺序。是先算完优惠券再判断满额包邮，还是先看原价够不够包邮门槛？两种算法结果能差出一笔运费。规则本身没有对错，但你得清楚自己这套系统是哪一种，否则客服永远解释不清。同样的问题也出现在"包邮商品和其他商品一起下单"的时候，包邮到底只包那一件，还是整单都免。
还有几个小坑值得单独记一下：虚拟商品、到店自提的订单不该收运费，模板里要排除掉；重量单位是克还是千克，填混一次运费能差十倍；改完模板如果前台没变化，先清一次缓存再说。
上线前建议拿五个典型订单自己跑一遍——单件寄包邮区、单件寄偏远地区、多件超重、刚好卡在满额门槛、两种模板混着买。这五单跑通，基本能覆盖九成以上的客诉场景，比在后台盯着规则看半小时有用。
另外给客服留一句话版本，比如"满 99 包邮，新疆西藏除外；不满 99 首重 8 元、续重 3 元"。客服能背下来，前台再显示清楚运费的构成（商品多少、运费多少、为什么收），争议会少一大半。
最后一句实在话：运费规则不是越精细越好。每多一层条件，出错概率和客服的解释成本都会翻倍，能用一套简单规则覆盖九成订单，就别为了那百分之几的特殊情况把模板做成迷宫。