背景

我所在的公司是一个二手电商公司，所有即涉及买家，也涉及卖家，所有商品状态流转也就涉及两条主线(买家&卖家)，并且因为历史原因，这两条主线还有一定的交织和关联。

其中，买家侧的商品状态比较少，流转情况也较少，出现问题也较少，本篇文章不深入分析，只有和卖家侧商品状态有交织时会提及。

文章主要分析卖家侧的商品状态流转。

卖家侧的商品状态有很多，因为每一个商品处理环节都需要定义状态，甚至还有不少状态有子状态，所有商品管理平台和卖家侧展示，这两块业务，常常出现问题，并且每次解决都需要重新梳理相关状态，导致问题解决特别棘手。

20210826更新-第三次会议讨论

切换的一个新的角度来看待商品状态流转的问题。

从不同的系统角色出发,划分买家端,卖家端和中间处理状态这三种状态.

其中买家端状态不复杂,只需要一级状态即可表示. 卖家端和中间处理状态较为复杂,都才有二级状态进行表示。所以一共是1+2+2=5个状态表示全部状态，这5个字段主要用于查询和筛选某些状态的商品列表。

这5个状态字段维护的则放在不同的业务逻辑。这样就把状态查询和状态管理分离开来。

简化了查询业务的代码,但是状态管理业务的代码应该是没有很多改进。

本次会议成果要点基本如上。

我个人认为附录2的有限状态机和状态转换表是必须要梳理的东西,但是精力比较有限,想法也没有很成熟,所以暂时没有在会议上提出。

最近公司多个技术领导,准备用领取驱动来对后台管理系统进行重构。我保持悲观态度。又想到了这个商品状态流程的问题，再一次调研状态机，发现附录3的文章提到了状态机的一些应用。同时我也梳理了商品状态流转的主要问题:

状态回退。
主状态和子状态。
梳理异常流程和分支流程。哪些状态算分支,哪些算主流程,划分的标准是什么? 至于状态梳理的多少,其实不是本质问题,流程多,那么状态自然就多了,这是业务流程决定的,是无法改变的事实。