我们都知道空和无不是同一个概念，生活中随意用没问题，但在产品设计中，这样不严谨的操作，有时候会带来很大的误解。

假如明天周末，你要开车带家人出游，希望提前加满汽油。当你开车到一个看起来是加油站的地方，希望加满95#汽油：

1、如果这里不是加油站，并不售卖汽油，那就是——“无”

“hi，伙计！我们这里不卖汽油”。他就不能说，自己的汽油全部卖完了（空）或95#油为0了。（也许你找的这个加油站实际上是个新能源充电站，或是个cng加气站）

2、如果这里是加油站，但今天95#油全卖完了，那就是现在95#汽油为0了

“hi，伙计！没有95#汽油了”。

但是你一定还想弄明白，到底是这里压根儿没有95#汽油（售卖清单：95#油品-空） 还是卖完了（95#-有售，目前售完，库存为0）。

这个问题有点抽象，却很普遍的存在我们的生活中，被这几个含义糊弄、或者拿这几个含义糊弄别人的事情相信你一定经历过。

🧒小孩子拥有比大人更清晰的世界

2024年春节期间，在重庆鸿恩寺游玩，登顶鸿恩阁下来的路上，偶闻一小女孩对妈妈说：回家给你捶背，收费0元。妈妈问：0元是多少钱啊，小女孩说0元就是不要钱。

你看，其实小朋友对世界的理解，还是很清晰的，他们不收钱，就明确的给出了标价是0元，而不是不告诉你（也就是给你“空”）让你自己去猜。虽然在语言世界里面还可以说“不收钱”，但是他们理解的世界就是一个明确的，存在交易但金额为0元。

👤挠头的成年人，可怕的自以为是

紧接着2024年春节返工后，投入团队一个正在进行的项目继续和三方对接，中间遇到一个特别尴尬的问题。API对接清单中，我方需要指定一些属性的属性值入参，对三方系统进行调用创建订单，如果涉及到一些属性值没有或不满足的时候（比如：某个sku的规格值），对方系统会认为自己没有某项属性值信息，而直接阻断报错，all wrong，创建订单失败。

但发生上述情形的前提是，对方有另外的说明，允许调用方指定属性/属性值、且允许缺货下单，那我们现实世界的理解就是你既然允许我要、也允许自己没有，那你没有时候你还报错阻断个锤子啊！

至少允许订单提交过去，但没有的商品创建订单不包含在里面即可，并返回给缺货的商品list。但对方对缺货下单的理解是，必须是商品档案库有的商品才能允许缺货下单。如果包含没有的商品，直接整个订单就会错误。你看这些理解，就很奇葩。

（话说如何识别到这个问题呢？面临对方文档信息的不完善，且对接沟通时候也未识别这种情况，团队成员在几次失败之后，我自己拿着开发捞出来的错误报文才识别到了该问题，对方拿到这个信息也是恍然大悟。）

🙅‍♂️这里其实已经产生了严重的定义偏歧：

对方定义的允许缺货下单，其实并不是“无”，也就是说不允许不存在这个商品。所说的允许接缺货下单，前提必须是存在这个商品档案，其实对应的是“有➕非空”的要求，然后与他们的现有商品可用库存值做对比。

而对于接受者理解缺货下单应该可以是“无”的情况，也就是说，当报订了一个经营范围之外的商品时，不能因为这个商品没有经营，进而影响其他商品的正常下单和业务数据流转。对方处理是偏程序思维的，但却脱离了业务的实际。但聪明的你说，产品、技术不得服务于商业吗？

🚶‍♀️千里之行，始于足下：

反观当时所在团队的产品实操，我们自身业务也会经常遇到空、无、0的定义问题。就拿对于团队连锁门店店员操作来说，很多时候我们为了让店员清晰自己的系统输入动作，而不允许空数据提交，如果你不能执行，请输入0表示你“关注到了且不能执行”。0表示你的明确表达，但“空”则是未知。

🤔️所以你说，0 和空，到底是不是有区分？

当然，空代表的是不确定，是不是出现了故障，所以没有响应？

从用户情绪出发，这个时候是恐慌、是不确定。

0，是确定性的结果输出，我做出了动作，你给我了反应，这是一种闭环的信息流。

往生活里面想一想，也是一样，我们问别人个东西，他不能因为不知道，所以不吱声吧，那到底是知道还是不知道呢？

靠 猜啊！别，大家都累。