电商“订单号”的思考

1.三个真实的案例

案例1：最近面试的将近20位产品经理里面，我都会问一道问题：请您为我公司的订单系统设计一套订单号的生成规则。应聘者里面有一两年的职场新人，也有工作将近十年的老鸟，当然也不乏运营或者开发转岗到产品的，有些甚至还做过订单与支付系统，但几乎所有的面试者都没能说的很全面。

案例2：去年的某个时间，朋友A所在的公司订单系统改造升级，开发在没有知会运营和市场的前提下将订单号长度由14位改到了19位（事后得知产品人员当时也不知情），而公司现有的用户至少70%都在使用货到付款的刷卡支付，即每次刷卡前都需要输入订单号，然后你懂的，整个市场炸锅了，开发于是紧急发版，又把订单号的长度改回了14位。

案例3：再说说6年前的一个经历。当时朋友（简称为C吧）在一家游戏公司做PHP网站开发，C和其他几位开发完成了整个游戏的在线支付系统，并且联调成功了。系统运行后发现了一个情况，某游戏玩家充值了5万块钱，当时运营人员想查下是什么时间充值的，但后台系统里面没有记录充值时间，无奈之下只能去数据库查到了时间戳，然后根据时间戳反查出来了充值时间。

2.订单号的生成规则

再回到上述案例1里面的问题，其实题干里面还隐含了一个关节信息，即该系统是为我公司设计的，而不是其它公司设计的（我公司现在做酒饮类B2B，未来可能会做B2C或其它）。但回答者几乎都忽略了这一点。

这些应聘者的原话记不清了，但主要就以下这些思路及其组合，括号里面是我的点评（吐槽）：

• 订单号由数字和字母和连字符-组成（您考虑过英文和拼音发音分不清楚的用户么？连字符起什么作用？）；
• 订单号由时间/年月日时分秒和随机数组成（仅时间20161111112233就14位了啊，随机数你打算再来几位？考虑到支付峰值每秒10万笔订单，系统怎么来随机？再加5位数？）
• 订单号前几位标识商品，比如茅台编码是001，五粮液是002，既有茅台又有五粮液是003，后面由日期+随机码构成（商品标记会有什么意义？即便商品数量只有几十个的情况下，他们的排列组合也很多啊，这个得多少位？）；
• 由下单日期+用户手机号+随机数构成（即便日期只取月和日会占4位，加上11位手机号也15位了，而且日期会重复，每个用户每天可能会下很多单，而且用户手机号不具有唯一性。后来有人提过类似的规则，只不过将用户手机号换成了唯一的user id，但user id还是会很长）；
• 根据卖家和买家的ID+随机数生成订单号(如果是C2C网站，用户体量在几千万上下，这样就需要至少8位来标记用户ID，随机数即便1位的话订单号也得17位，但实际情况有可能买家经常在某个卖家那买东西，3位随机码都不一定够用)；
• 根据商品的品类+时间+随机数生成订单号（他没有具体说是大的品类还是小的品类，如果是小的品类，可能也会很多）；

那么问题来了，一个好用又好看的订单号，应该具备哪些规则和依据呢？

关于这个问题，知乎和简书上都有很多相关的讨论，比如这篇《电子商务网站中订单号设计有什么规则和依据吗？》和这篇《电商订单号设计思考》，里面一些关于订单号的生成规则和依据很值得参考，在此，我说点自己的经验和见解。

3.订单号怎样生成才好用

回到问题的本质，订单号是拿来干嘛用的？谁会关注订单号？简而言之，订单号是用来标记/查询订单（查询的时候可能更关注于物流单号）用的，一般会在订单有支付/售后/异常问题的时候会用到，也就是说订单号主要是拿给客服/运营/开发部门用的。

那么客服在处理一笔订单的时候，什么格式的订单号才会好用呢？首先订单号中最好避免数字以外的其它字符类型，订单号尽量短，订单号尽量能结合当前的业务情况有特定的标识，如渠道编号（包括平台、下单渠道、支付方式）、业务类型和时间信息等。为了便于理解，下面还是举例说明：

• 平台：这个以游戏举例，目前很多手游除了官方服务器外，还有一些是和其它平台比如小米、腾讯联合运营的，但是充值有可能是用的同一套，这种情况就很有必要在订单号中标记平台；
• 下单渠道：目前很多电商产品都涵盖多平台，包括WEB、APP（Pad）和门店（比如1919和苏宁等），比如通过订单号发现近期反映的问题都来自于APP，则理论上可以推断出APP渠道有问题。
• 支付渠道：如上文案例2所说，不同支付方式会遇到的问题也是不一样的，比如货到付款的刷卡支付仅POS机错误代码就几十项，而支付宝基本不会有这些。比如APP不支持公司转账，如果某订单有了代表公司转账的标识位，不用后台查询即可知道这是一笔来自WEB的订单等等。同样，用户反映该订单号无法使用红包，客服人员也可以通过支付渠道标识位来识别出是因为红包功能在APP上没有上线造成的；
• 业务类型：以前在游戏行业的时候，我们一般会把订单号的某一位用来标识游戏名称，比如梦幻西游、魔兽世界和阴阳师分别用1、2、3来标识。这样遇到相关问题时，不用后台查询即可快速识别出问题并把其转给相关游戏团队。同理的还有零售和团购，自营订单和入驻商家订单，2B业务订单和2C业务订单；
• 时间信息：有时间信息会让客服/运营人员看到订单时不需要经过后台查询即可知道该订单时哪天产生的，可以简单的判断问题的紧急程度。同时在B2B业务中，我们也可以根据该时间推算出大致的清分结算时间等等。所以我的建议是如果业务类型决定了客服类问题比较多，则有必要在订单号里面加上这个信息。但时间的完整格式2016年11月11日 11点22分33秒这样的显示出来就是20161111112233，年和时分秒信息略显多余，只记录月和日即可；

综上，我给出的好用的订单规则是这样的：

下单渠道1位+支付渠道1位+业务类型1位+时间信息4位+下单时间的Unix时间戳后8位（加上随机码随机后的数字）+用户user id后4位。然后你会说，这样算下来就订单号就19位了啊，一点都不精简啊，不好记不好念不好输的。但我说的上面的这些业务标记，你不一定要全部加上啊。

你看淘宝/天猫那么大的订单量，16位订单号就搞定了。细心的网友已经发现了，订单号的后4位是取自用户user id的后四位，前12位中有10位可能是由Unix时间戳加随机规则生成的。

然后我们再来看看《电商订单号设计思考》中提到的那2个问题：

问题1：为什么淘宝单号这么长？前几年还12、13位，现在都16位了？订单号之所以那么长，我的理解是短了不够用，毕竟那么大的用户基础和订单量。至于现在都是16位？我查询了2011年的淘宝订单，发现是14位的，并不是该简友说的12/13位，但由14位扩充到16位，应该很大一部分原因是业务增长的原因。

问题2：为什么自己的淘宝单号最后4位都一样呢？这4位数字代表什么？2011年3月之前的订单，后4位是不一样的；3-7月之后（4/5/6三个月我没有下过单）的淘宝订单，后4位是一样的。我猜想可能是user id，后来我验证了下，一定程度上是的，比如我的ID后4位是1190，订单的后4位是9910，由此看来，淘宝订单后4位是将user id后4位简单处理过的。至于前12位，我 猜想其中有10位可能是由Unix时间戳加随机规则生成的。

4.订单号怎么生成才好看呢？

相信很多人都受够了银行卡上面不分段的银行卡号了吧，还有就是快递单上面不分段的快递单号码（顺丰的就很好），这些简直就是反人类设计。其实订单系统里面也可以借鉴顺丰的这个思路分段显示，方便查看和诵读。

如果做的再智能点，支持WEB上双击复制或者APP上长按复制（点击后可复制），是不是更好看更人性化更便捷了呢？

5.几句题外话

前几天我看到了宅妈妈APP的订单号，4位纯自增的数字，极其精简。当时我就在想他们为什么会把订单号设计这么短，后来仔细想了下她们的具体业务情况，或许是这样的：处于业务开拓起步阶段的宅妈妈不希望用户在反馈问题时报上冗长的订单号，同时她们希望用户通过订单号能感受到该APP有很多人在使用并下单，进而打消她们的部分顾虑。

滴滴出行因为每次行程都有司机车牌号，所以在遇到问题时直接反馈“时间+起点+车型车牌号”可能更方便。饿了么同理，我在反馈问题的时候也不会去报订单号，直接报时间和商家名更方便，订单号可能在客服处理问题的时候会用的更多一点吧。

原文链接：订单号怎样生成才能好用又好看，难倒了20多位产品经理

=============================================================================================================

订单命名的几种规则：
1、不重复。
这点我相信大家都懂，订单的唯一性不用解释。

2、安全性。
你的订单编号不能透露你公司的真实运营信息，比如你的订单就是流水号的话，那么别人就可以从订单号推测出你公司的整体运营概括了。所以订单编码必须是除了你们公司少部分人外，其他人基本看不懂的。参考京东和淘宝的编码规则，基本别人是搞不清是什么意思的。
其实最好的防泄漏编码规则就是在编码中不要加入任何和公司运营的数据。

3、不能使用大规模随机码。
很多人分析订单编码规则的时候，第一个念头肯定是不重复唯一性，那么第二个念头可能就是安全性，那么同时满足前两者的第三个念头就是随机码了。因为大规模的随机码随机生成，因为本身就没有意义所以无所谓泄密了。但是事实上这种编码规则在实现上会有很大问题的。
随机码满足第二点安全性要求，为了满足第一点不重复特性，那就得在生成随机码的时候对比历史数据是否有重复，如果你的订单数量到达了十万次，你每次生成订单编码时就得对比十万条历史数据，你可想而知会造成什么巨大问题。
但是难道随机码就不能在编码中使用了吗？小规模的随机码是可以使用的，比如2~3位，这种随机码一般都是和流水号等结合使用，主要作用是为了隐藏流水号的真实数据而进行使用的。

PS:在这里感谢 @马驰 @dad ni @bao xu（这个不知道为何@不到）同学的讨论，马驰同学实际测试估算了生成随机码并且检测重复所花费的时间在纳秒级别。但是我还是保持原来观点，觉得这种生成规则存在方向性问题，可能会造成检测时间过长的问题出现。
希望大家积极参与讨论。

4、防止并发。
这条规则主要针对编码中有时间的设定。

5、控制位数。
这点很好理解，订单号的作用就是便于查询。
一般正常使用场景应该是订单出异状或者退货的时候，用户将订单号报给客服，由客服进行查询。
所以一般在10~15位为好。
京东10位，淘宝15位。

推荐的几种编码规则：

年月日时分秒+用户ID(命名用户ID时也要注意，不要用流水号。可以采用区域ID+随机码+流水号+随机码方式)
1、唯一性：时间是单向的，确保唯一性。
2、安全性：确保用户ID安全即可。
3、随机码不参与判断，因为之前数据已确保无重复。
4、在同1秒钟，同一用户是不会产生2个订单编码的，所以可以防并发。
5、位数可能会在20位之内，位数比较多。

年月日时分秒微秒+随机码(2)+流水号+随机码(3)
1、唯一性：时间是单向的，确保唯一性。
2、安全性：确保流水号不会识别出即可。
3、随机码的位数和前后都是保密的，所以如果不清楚这一点的话，是很难判断出流水号的位数的。因为同时产生的订单数量很多，编码不具备线性对比功能。就算知道了流水号，可以在初始化时进行赋值。
4、在同1秒钟，同一用户是不会产生2个订单编码的，所以可以防并发。
5、位数可能会在20位之内，位数比较多。

PS：多谢大家的点赞，但我更希望大家能留言参与讨论。
毕竟如果搜到这问题的都是想解决这问题的，进行思考参与讨论，才是大家的原本目的。