走取购项目跟其他一般商城一样，对于订单的状态大致可以分为如下几个：
待付款 | 待发货 | 待收货 | 已完成 | 已取消 | 已关闭 | 已删除

在最初的设计中，我把‘已删除’状态跟订单的其他状态一起放入到一个字段(status)中存储。在前期看来好像是没什么问题，
并且该状态的应用场景也很简单，只是针对于前端用户手动删除自己认为可不用显示在订单列表的订单，当然用户发起的这个删除
操作是有前提的，比如某一个订单已经处于在不可逆的生命周期里面（待发货，待收货）是不允许删除的。

因此在符合特定的条件下，用户删除订单后，这张订单对于用户来说是不可见的，而对于后台系统来说，这个状态只是一个逻辑删除（状态标识），管理员仍旧可以查询到该订单，这个很好理解，一个正常的订单系统都应该完整的保存用户生成的每笔订单。

这是之前线上的订单删除逻辑，系统也稳定运行，直到有一天走取购运营人员核对财务账单后，爆出了一个问题!

他们通过后台的管理系统导出了指定日期的订单Excel，最后通过筛选统计出了营业额。但是，在对比微信商户后台的支付订单时，发现两边的交易数量不一致，金额就更不一样了。

随即我们协助运营进行了排查，在确认了支付渠道，支付日期，支付商品等关键来源信息无误后，于是决定拖出生产库中的订单数据，从而进行原生的sql查询，最后得出的数据信息和运营一样。那为什么直接从后台订单系统的excel导出算出的金额就不一致呢？

后来经过几番校对才发现了问题所在，原来商家的运营人员在统计销售数据时，已经把“已删除”的订单排除在外，而恰好这些被用户删除的订单，之前全是已完成的状态(即已成功付款的)。所以才出现了现实情况的中这样的误差现象。

但是作为使用后台的运营来说，他们正常过掉滤掉用户已删除的订单，而后统计出金额也无谓对错。在这里我的处理方法很简单，在订单表中再额外增加一个字段，用来表示该订单的删除状态，其实这个新字段应该表示为“客户端隐藏”更为贴切，因为在整个订单的生命周期里，用户完全可以在完成交易的情况下，删除订单。

所以基于此类情况，我们就不能将“删除”状态和订单的主状态记录在一起了。这样做的好处除了解决以上问题后，还可以同时避免以后可能的统计需求，比如一段时间内的订单完成数，如果状态不区分，最后会影响结果的输出。