编辑导语：订单号、支付流水号、售后订单号、快递取货号、电子券核销码等，这些都是我们日常在生活中进行会遇见和使用的一些单号，那么为什么有些单号那么长，有些只有几位数？有些单号一看就知道年月日的信息，有些却看不出任何意义？为什么我淘宝订单的后几位数都是一样的？今天就来带大家看一下订单号的是怎样生成的。

一、订单编号作为唯一标识码在业务中的应用场景

单号在实际的业务过程中是做为一个订单的唯一标识码的存在，提供订单号就很方便业务人员快速定位订单信息，给予用户帮助。

1. 用户订单遇到问题，需要找客服进行协助

我们日常在电商平台上面购买商品的时候，很多时候需要去向平台客服反馈在订单过程中遇到的问题，一般这个时候平台客户都是要求用户填写订单编号的，这样客服可以快递锁定订单信息，给用户信息问题的解答和处理。

2. 对订单进行操作，如线下收款，订单核销

我们在第三方平台上购买了某一个店铺的线下优惠券的时候，工作人员需要对我们提供的优惠券进行核销，核销的依据一般来说就是订单编号。

而在某些场景涉及到的线下收款，也会根据订单号来进行订单的确认和收款，不过日常在业务过程中将一般都将订单号生成二维码，再由工作人员扫码进行操作，因此用户在线下对于订单号的感知并不是很强烈。

3. 内部进行订单的处理或者跟进

从技术的层面去讲，很多时候搜索订单相关信息的时候都是以订单ID作为唯一标识符，这是由于订单号的生成规则的唯一性决定的（后面讲订单号生成规则会讲到）。

由此公司内部在进行业务操作处理时候，比如对通知仓库按单发货，内部交流某个订单信息时候，也会直接根据订单号来进行信息传达。

二、编号规则的设计原则

订单号的在业务中的使用一般都是基于唯一性的需求，因此在订单号的设计上需要遵循几个原则：

1. 不得重复

由于我们在业务中对于订单编号的要求是唯一的，所以订单编号生成的时候一定要遵循不可重复这一特性，而实际在底层生成订单编号的时候由于业务流水很大，处于一个高并发的状态，并且订单号的生成规则一般是固定的，所以可能会造成在同一时间多个线程读取的生成参数相同，从而造成生成的订单号相同（当然这是开发人员应该注意的问题）。

其次就是业务的长时间积累可能导致新生成的订单号会与过去很久的订单号产生重复，所以在设计订单号的时候一定要充分考虑到不可重复性的原则（后面讲到订单号设计中的变量部分会详细讲到）。

2. 安全性

编号不能透露公司的运营情况，比如日销、公司流水号等信息，以及商业信息和用户手机号，身份证等隐私信息。并且不能有明显的整体规律（可以有局部规律），任意修改一个字符就能查询到另一个订单信息，这也是不允许的。

类比于我们高考时候的考生编号的生成规则，一定不能是连号的，否则只需要根据顺序往下查询就能搜索到别的考生的成绩，这是绝对不可允许。

3. 具备一定的可读性

位数要便于操作，因此要求订单号的位数适中，且局部有规律。这样可以方便在订单异常，或者退货时客服查询。

过长的订单号或易读性差的订单号会导致客服输入困难且易错率较高，影响用户体验的售后体验。因此在实际的业务场景中，订单号的设计通常都会适当携带一些允许公开的对使用场景有帮助的信息，如时间，星期，类型等等，这个主要根据所涉及的编号对应的使用场景来。

而且像时间、星期这些自增长的属于作为订单号的设计的一部分元素，有助于解决业务累积而导致的订单号重复的问题。

三、编号设计中的常用变量

在遵循涉及原则的基础上，我们常会使用一些变量来进行编号的设计，这也是为了满足订单编号的局部可读性带来的业务优势，通常会有以下几类：

1. 时间

如20220525105959这种类型的年月日时分秒，编号中使用这个变量就把重复的可能性降低到一秒内的不重复。

常用的时间变量还有很多变种类型，如取年份的后2位数、如20220525只保留到天。通常在快递取件码的设计中会使用月、日、周等+其他元素的设计，这是为了方便取件码可以快速重复使用，因为快递取件码通常有效期不会超过一个月就会原路退货然后被销毁。

2. 时间戳

时间戳是一个10位数的数字，代表的是当前时间距离1970年1月1日UTC/GMT的午夜）开始所经过的秒数。也是经常用来代表时间的一种方式，时间戳也可以精确到毫秒，形成一个13位数的数字。

3. 类型

如订单类型、售后类型、商品类型、支付类型等等，不同类型的可以使用不同参数进行。通常支付类型的应用场景是，线上支付和线下支付共用一套业务后台，所以为了方便区分会加入支付类型这个参数用于区分线上线下。

类比还有店铺代码、支付的机器代码、操作员代码等等。

4. 用户ID

对一些涉及到用户的编号规则时候，可以使用到用户ID作为变量来进行设计，如淘宝的订单号中最后几位数就使用了用户ID，不过要注意不能使用完整的用户ID，需要进行一些规则的设计再使用。

5. 商家ID

对电商系统中，可以把商家ID脱敏后也作为一个变量设计到编号规则中。

6. 手机号

使用用户的手机号中的某些位数作为编号中的一个变量；使用类似于手机号部分号码这种重复度较高的属性设计订单编号的时候，切记不能只有一个变量，否则很容易出现订单编号重复。

7. 平台形态

如果是多终端多平台的系统，那么可以考虑在编号中把平台作为一个变量考虑进去。如小程序平台用01,安卓app使用01，PC版本使用03,第三方平台04类型这样的规则。

8. 其他业务属性

可以根据业务场景，把一些业务属性的信息也作为变量设计进去。

9. 随机数

随机数就是系统根据程序在一定规则内随机生成的字符，可以为数字也可以是字符串，一般可以用来降低重复；随机数在订单生成中的使用频率非常高，常常是前面几位都是一些显式的规律性数字，比如订单生成的时分秒，然后最后加上四位随机数从而组成订单号。所以读者在设计订单编号的时候，如果不知道如何加密，就可以简单的插入几位随机数即可。

10. 序列位

代表顺序的数字，如10,11,12这样的。

11. 验证位

一般放在最后，根据前面的多位字符按照一定的规则计算最后得到的一个数字，一般为1位，主要目的是提高编号的安全性；身份证的最后一位就是校验位，其计算原理也是通过前面几位数字加密算法算出来的，感兴趣的读者可以去了解一下身份证的生成规则。

12. 地区信息

对有区域性质的编号规则里面可以考虑把区域作为变量考虑进去，如某地区分店、某地区线下的售货机等。

13. 数据库数据的自增ID

每条数据录入系统时候，一般情况都有一个唯一的ID，这个ID也可以作为编号的一种变量进行使用。

四、编号实践方案分享

1. UUID

通⽤唯⼀识别码，是⼀种软件建构的标准，亦为开放软件基⾦会组织在分布式计算环境领域的⼀部分。其⽬的是让分布式系统中的所有元素，都能有唯⼀的辨识信息，⽽不需要通过中央控制端来做辨识信息的指定。

1. 1~8位采⽤系统时间，在系统时间上精确到毫秒级保证时间上的惟⼀性。
2. 9~16位采⽤底层的IP地址，在服务器集群中的惟⼀性。
3. 17~24位采⽤当前对象的HashCode值，在⼀个内部对象上的惟⼀性。
4. 25~32位采⽤调⽤⽅法的⼀个随机数，在⼀个对象内的毫秒级的惟⼀性。

通过以上4种策略可以保证惟⼀性。在系统中需要⽤到随机数的地⽅都可以考虑采⽤UUID算法。但是呢直接使用这个作为单号。虽然具有唯一性，安全性，但是却没有任何的可读性而言。因此在这种情况下，UUID只是能作为系统中间的标识码，可以在业务中数据流转的时候配合订单号使用，绝不可直接给予客户和业务人员使用。

2. 时间戳+随机数

对于一些编号需求不是很大的场景，如果可读性也没什么场景的要求，可以简单的使用时间戳和随机数进行拼接作为编号规则使用；如时间戳1635302466+随机数2313，则编号为16353024662313。

3. 淘宝订单号的生成规则

一共19位数，前面13位数为根据时间戳和内部定义序列，后面6位数为跟购买者ID相关的用户位。

4. 有赞商家端的订单号

日期+时分秒+随机数。

5. 时间+时间戳+用户+序列位

时间：取时间的年份后2位+月份+日期形成如211027。

时间戳：取时间戳的后6位数

用户：取用户ID的后5位数，序列位2位数随机。

6. 综合各种变量

下单渠道1位+支付渠道1位+业务类型1位+时间信息4位+下单时间的Unix时间戳后8位（加上随机码随机后的数字）+用户userid后4位共19位并不一定需要把19位全加上。

7. 预先生成

系统预先生成不重复的编号，业务系统要使用时候按顺序取数即可。这种编号一般系统拥有一套成熟的加密规则，不属于常规的订单生成规则，一般用于加密程度较高的业务。

本文由 @卖干货的产品小谢 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。