关于订单号生成

生成规则

• 订单号由数字和字母和连字符-组成（您考虑过英文和拼音发音分不清楚的用户么？连字符起什么作用？）；

• 订单号由时间/年月日时分秒和随机数组成（仅时间20161111112233就14位了啊，随机数你打算再来几位？考虑到支付峰值每秒10万笔订单，系统怎么来随机？再加5位数？）

• 订单号前几位标识商品，比如茅台编码是001，五粮液是002，既有茅台又有五粮液是003，后面由日期+随机码构成（商品标记会有什么意义？即便商品数量只有几十个的情况下，他们的排列组合也很多啊，这个得多少位？）；

• 由下单日期+用户手机号+随机数构成（即便日期只取月和日会占4位，加上11位手机号也15位了，而且日期会重复，每个用户每天可能会下很多单，而

• 且用户手机号不具有唯一性。后来有人提过类似的规则，只不过将用户手机号换成了唯一的user id，但user id还是会很长）；

• 根据卖家和买家的ID+随机数生成订单号(如果是C2C网站，用户体量在几千万上下，这样就需要至少8位来标记用户ID，随机数即便1位的话订单号也得17位，但实际情况有可能买家经常在某个卖家那买东西，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时间戳加随机规则生成的。

例子

根据商品id、用户id、时间、随机数生成订单号

def _order_num(package_id=12345, user_id=56789):    # 商品id后2位+下单时间的年月日12+用户2后四位+随机数4位    local_time = time.strftime('%Y%m%d%H%M%S', time.localtime(time.time()))[2:]    result = str(package_id)[-2:] + local_time + str(user_id)[-2:] + str(random.randint(1000, 9999))    return result