“空”和“0”在赋值上有完全不同的适用范围，在一开始，产品端应该格外注意字段的限制，能够提高产品开发效率。

作为一个产品经理，从来不会把“空”等同于“0”来看待，在写原型的时候也不会特意强调，这是“空”，不是“0”。

两个毫不相关的东西，为什么要去解释一遍无关性呢？就好比人和狗，为什么要去说明人不是狗，狗不是人？

直到产品验收时，看到了那些0……

让产品抓狂的0

案例1：月经生育史

先来看个月经史、生育史的例子。

医生还未写病历，这些“0”就已经默认写上了，这也就罢了，一个个删除，然后保存；回头一看，“0”全都出来了。

一下子崩溃了，问开发：初潮0岁，你见过生下来就来大姨妈的吗？月经周期0天，你见过365天，天天来大姨妈的吗？

开发小哥很委屈：我又不懂这些是什么意思。

想想这好像也不能怪他们，毕竟还是单身。

案例2：预约次数限制

这是微信预约的限制，用来限制每个微信id一天可预约的次数。

当我打开设置时，发现默认值就是0，删了保存还是0。这应该有常识了吧，问开发：所有人都不能预约，那预约功能的意义在哪？我要的是“空”，不是“0”。

开发小哥哥又委屈了：数据库又不能存空，空就是0啊。

也确实是难为他们了，一方说我要空，一方又不让为空。

案例3：积分规则设置

做过电商的朋友对积分都不陌生，消费后赠送积分，再次消费时抵扣积分。

当我打开页面设置时，也是满眼的0。问开发：都是0，设置和不设置有什么区别？这功能都没有用。

这回开发小哥哥有理了：既然“空”和“0”没影响业务，显示着也没问题啊。

好像挺有道理，怎么就隐隐透着些傻气呢。

开发怎么看“空”

产品经理眼里的“空”，怎么就成了开发眼里的“0”了呢？但是，也不是所有的空，都显示成了“0”啊，比如填写联系人和联系电话的地方，都没有显示0。

为此，我去采访了一下开发小哥哥，发现了其中的原因。

每一个字段都是有一个类型的，常用的是：

1. 字符型数据：包括中文字符、英文字符、数字字符和其他ASCⅡ字符。就像上面的联系人就是这种文本类型，可以输入中文姓名。数据库默认值就是空字符串，即“”。
2. 数值型数据：只可由数字、小数点、正负号和表示乘幂的字母E组成，不能输入中英文字符。就像上面的经期就是这种数值类型。数据库不能存空，必须存入一个确定的值，故开发常常把空存成0。

既然字符型数据能支持数字，为什么不都存成字符型数据呢？不就没有0的那个问题了吗？

从开发角度来说，原因有好多，说个我们比较关注的：字符类型往往比数字类型占用更多的存储，而更多的存储空间消耗会导致查询性能变慢，就是系统很卡。

为了使有限的存储空间发挥最大的能效，我们有必要把字符类型和数值类型分开，那怎么做才能让开发不直接把空当0呢？

让开发分清空和0的法则

明确数据类型

产品经理是最熟悉业务的，每个字段可能填写什么内容，都会有一个深入的理解。那在写原型的时候，就需要针对每个字段可填写内容的类型做个明确的标识，哪些是文本，哪些是数值。

比如说上面的字段：

这样至少能保证文本类型的地方不会出现0，下面重点关注数值类型就可以了。

明确数值范围

我们会发现，有的地方空=0是没有问题的，比如说初潮，因为0不在数据范围内，数据库存了0前端不显示出来就可以了，不会引起误解。

但有的地方空=0就会发生错误，比如说生育史里面的足月产，意思是足月生育了几个孩子，那填写0是完全合理的；如果空就是0，那填了0也会被认为是空。

我们可以给每个数值一个范围，这样开发在赋值的时候，就知道哪些值不能用了。

比如上面的字段：

明确空的定义

空其实是有很大的想象空间的，有时候代表无限大。比如说预约次数的显示，不填就是不限制预约次数，任意次都可以。

有时候代表未知。比如说足月产，你没法知道这个人到底生了几个孩子，不能随便给一个值。数据库需要给这个未知赋一个值，但肯定不能是0了。这空值也不能保存进去，在其他相关的地方显示出来。

有时候就代表0。就像积分累积规则，0就代表没有积分活动。

空具体的值不需要我们定义，但我们需要告诉开发这个空值的含义是什么。

比如说上面的字段：

可以和开发约定一个整体的规则，“空”=999999，999999是系统里面肯定不会出现的正常业务数据，用这个代替不会出现像0那样的异议。

当然，一些特殊的字段，还需要单独去处理，比如说预约次数限制，最大值就是999，空只能代表最大的999。

明确空回显内容

最后要和开发强调一点：不管哪个功能下的“空”，不管“空”的含义是什么，也不管给“空”赋了什么值；既然是空，页面上千万别回显出内容来，千万不要随处可见的“0”。

我们要的就是空！

总结

空和0的问题，是产品很容易忽视的问题，却是很容易和开发引起争执的问题。

我们在写需求文档的时候，需要格外注意数值型字段的取值范围和空值含义。提前告知开发，就能避免很多数据错误的情况，提高产品开发质量。

本文由 @辰阳 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议