编辑导读：后端产品在工作中经常会遇到一些坑，稍不留神就很容易“入坑”了。本文作者基于自己的工作经验，围绕两个小话题展开介绍，希望对你有帮助。

本文结合案例，聊两个小话题：

1. 异步处理机制，会给脏数据带来可乘之机？
2. 取“全部”，是否等同于遍历所有枚举值？

一、异步处理机制，是否会给脏数据带来可乘之机？

1. 场景

【商品列表】，以导入的方式新增商品，是很正常的一个功能。作为资料一部分，商品的图片，也可以导入。

方式就是在Excel录入图片的url地址。

机制就是：导入后，系统先打开地址，然后下载图片；下载成功，再上传到【商品列表】。

只是这个功能在机制上，往往要异步执行。因为解析url的时间太长。

于是，异步的实现手法，就可能导致bug的光临。案例如下：

2. 案例

和上述的场景相似，且规定了导入模板中，商品图片是必须项，所以未写入图片的时候商品数据不完整。

如果：

00:00的时候提交Excel，其中有商品编码001。

当时，检查到商品编码001在系统不存在，于是该数据等待异步执行。

而就在00:01的时候，（另一）用户手动创建了同一商品编码001，创建的时候系统验重通过（因为Excel导入的那个001还没执行写入）。00:02的时候Excel写入成功。此时，系统就会出现两个001商品编码。于是导致数据重复。

这里一个隐藏的不合理条件：就是导入的数据中无图片，则无资格参与去重。

这就是一个利用异步处理的时间窗，数据偷渡的现象。

3. 解析

这个失误的原因本质上，在于Excel的校验和执行之间，拖的时间太长，或者说，写入数据的时候没做校验。但是产品经理的需求到开发那里，这样实现的开发，没测到位的测试，绝对是有的。

产品经理的启发：

PRD中做提醒：

要尽量想在开发前面，因为开发也有不靠谱的。比如案例中的PRD，可以增加特别提醒，将可能的风险暴露。

方案根源避免：

比如案例中，要求在Excel导入的时候，图片未到位时，视为草稿状态写入数据库，占住商品编码的坑。那么，如果有同样的商品编码手动创建，就会当场检查到。从而避免异步的时间窗，引入不法数据。

二、取‘全部’与取每个枚举值的差别

1. 背景

O2O平台的门店商品，是商品编码个数n，乘以门店个数m的矩阵。表达的意思是，将某商品，铺货到某个门店中。

若某场景下，n个商品要铺货到所有门店，以导入方式执行。

那么导入Excel的表格中，就只需要录入n行商品数据，不必写具体的门店，而是定义：门店为空的，即为全部门店。

从而将数据量降维，减轻用户负担。

2. 案例

用户有1个商品，铺货到m个门店。那么导入表格中只写一行，门店列为空：要求系统对该商品铺货到所有门店。

开发的实现机制就是，发现门店列为空，则抓取所有门店，挨个执行铺货。

但是忽视一个问题：全部门店中，会有启用和禁用的门店（甚至更多关系）。

门店禁用之后，在数据库，还有这些门店与商品的绑定关系，只是前端页面没显示。

有数据，就有可能被新的逻辑运算引用（所见非所得）。

那么方案中就要做启用状态的过滤。

那么问题就是：你定义门店列为空的逻辑，是否可靠。

3. 分析

正常情况下，业务不这么单纯。用户录入指定门店的时候，一定是用户看得到的。而为空的时候，默认取全部，就意味着可能超出了用户的可控范围。

好比指定一个星球（火星、木星），和默认全部星球（认知边界之外的星球无法把控），是完全不一样的。

意识到这个问题之后，那么方案需要优化：

方案一：

在默认全部的基础上，增加限制，比如全部启用状态的门店。

优点：从逻辑层面是安全可靠的。

缺点：增加了一个非强逻辑的校验，因为可能转眼这个门店就启用了，那么又要重新处理。

方案二：

不允许用户将门店列留空。

若用户想对全部门店铺货，那么就录入全部门店，用逗号隔开。即多个门店写在一个单元格中。

类似的问题，在搜索项中也存在。比如搜索全部、该项不参与搜索、勾选全部枚举值，在某些具体环境下，是三种完全不同的结局。

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交APP。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议