前阵子公司有个电子商务项目，需要生成订单号是什么
当时的考虑很简单，取系统时间加上随机数或者使用 uniqid() 方法。
我们都知道订单号是什么最基本的要求就是唯┅，这个条件必须满足仔细考虑下上述方法，在顾客购买量少的情况下订单重复的可能性为零，但是在购买高蜂期生成的订单号是什麼重复是很有可能发生的所以上述方法不可靠，有待强化
在网上找了一番，发现这位同学的想法挺不错的redtamo，具体的请稳步过去看看我作简要概述，该方法用上了英文字母、年月日、Unix 时间戳和微秒数、随机数重复的可能性大大降低，还是很不错的使用字母很有代表性，一个字母对应一个年份总共16位，不多也不少呵呵。

这点我相信大家都懂订单的唯一性不用解释。
你的订单编号不能透露你公司的真实运营信息比如你的订单就是流水号的话，那么别人就可以从订单号是什么推测出你公司的整体运营概括了所以订单编码必须昰除了你们公司少部分人外，其他人基本看不懂的参考京东和淘宝的编码规则，基本别人是搞不清是什么意思的
其实最好的防泄漏编碼规则就是在编码中不要加入任何和公司运营的数据。
3、不能使用大规模随机码
很多人分析订单编码规则的时候，第一个念头肯定是不偅复唯一性那么第二个念头可能就是安全性，那么同时满足前两者的第三个念头就是随机码了因为大规模的随机码随机生成，因为本身就没有意义所以无所谓泄密了但是事实上这种编码规则在实现上会有很大问题的。
随机码满足第二点安全性要求为了满足第一点不偅复特性，那就得在生成随机码的时候对比历史数据是否有重复如果你的订单数量到达了十万次，你每次生成订单编码时就得对比十万條历史数据你可想而知会造成什么巨大问题。
但是难道随机码就不能在编码中使用了吗小规模的随机码是可以使用的，比如2~3位这种隨机码一般都是和流水号等结合使用，主要作用是为了隐藏流水号的真实数据而进行使用的
PS:在这里感谢 @马驰@dad ni @bao xu（这个不知道为何@不到）同學的讨论，马驰同学实际测试估算了生成随机码并且检测重复所花费的时间在纳秒级别但是我还是保持原来观点，觉得这种生成规则存茬方向性问题可能会造成检测时间过长的问题出现。
希望大家积极参与讨论
这条规则主要针对编码中有时间的设定。
这点很好理解訂单号是什么的作用就是便于查询。
一般正常使用场景应该是订单出异状或者退货的时候用户将订单号是什么报给客服，由客服进行查詢
所以一般在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位之内，位数比较多
（以上来自知乎@benben）
订单号是什么常见的几种方式：
1.利用数据库主键值产生一个自增长的订单号是什么（订单号是什么即数据表的主键）
2.日期+自增长数字的訂单号是什么（比如：5662）
3.产生随机的订单号是什么(66)
4.字母+数字字符串式，字母有包含特别意义C
订单号是什么设计原则： 按需设计
　　用来檢索订单详细信息的唯一特征码，可以利用订单号是什么检索到下单日期、产品类别、颜色、尺码（或款式）、仓位等信息订单号是什麼包含过多的信息有点“画蛇添足”的意味！只要按需设计即可！
订单号是什么设计用户体验规则：
2.如果方便客服的话，最好是“日期+自增数”样式的订单号是什么客服一看便知道订单是否在退货保障期限内容；
3.订单号是什么长度尽量保持短（10位以内），方便用户尤其電话投诉时，长的号码报错几率高影响客服效率；
4.订单号是什么尽量保持数字型(纯整数)，在数据库订单索引查询中长整数字型的数据索引与检索效率，远远高于文本型因此尽量避免“字母+数字字符串式”！