UUID生成的订单号不能直接用，因其含连字符、长度36字符、无业务语义、易混淆（0/O、1/l）、索引效率低；推荐uuid4()转base32编码，得26位全大写无歧义字符串，兼顾唯一性、可读性与存储效率。
UUID生成的订单号为什么不能直接用？
Python的uuid4()生成的是32位十六进制字符串（如'f47ac10b-58cc-4372-a567-0e02b2c3d479'），含连字符、长度固定、无业务语义——直接当订单号用，用户难记、客服难录入、日志里占空间、数据库索引效率偏低。
真正要的是：可读性略好、不重复、不暴露生成时间或机器信息、兼容URL和数据库字段（比如MySQL VARCHAR(32)）。
- 去掉连字符后是32字符，但纯小写十六进制仍易混淆（
0和O、1和l） -
uuid1()带时间戳和MAC地址，有隐私和可预测风险，不适用于对外ID -
uuid4()最安全，但需做轻量转换才能落地
推荐做法：uuid4 + base32编码去重缩略
用base32替代hex，避开易混淆字符，同时压缩长度（32字节uuid → base32后约26字符，且全大写、无符号）。
Python标准库没直接提供base32 UUID封装，但base64.b32encode()能用——注意它输入必须是bytes，且默认补=号，要手动strip：
立即学习“Python免费学习笔记（深入）”；
import uuid
import base64
<p>def gen_order_id():
uid = uuid.uuid4().bytes # 16字节bytes，比hex更紧凑
return base64.b32encode(uid).decode('ascii').rstrip('=')示例输出：'N5TVG4E7M2XKZQJF9P7A3R8W'（26位，全大写、无0/O/1/l，适合打印、短信、扫码）
- 不依赖第三方包，纯stdlib
- 保留uuid4的密码学随机性，碰撞概率仍是2⁻¹²⁸量级
- 比原生hex少6字符，对短链接、嵌入式系统更友好
- 若需固定长度（如32位），可在末尾补随机字母或截断，但不建议截断——会升高冲突率
需要带时间前缀或业务标识怎么办？
纯UUID无法体现“2024年订单”或“APP下单”，但硬拼接字符串（如f"ORD{datetime.now():%y%m%d}{uuid4()}"）会破坏唯一性保障——时间粒度到秒，高并发下同一秒多个请求，仅靠时间前缀无法防重。
正确做法是：时间戳只作可读前缀，核心唯一性仍由UUID保证，并用分隔符隔离：
from datetime import datetime
import uuid
import base64
<p>def gen_tracing_id():
dt = datetime.now().strftime('%y%m%d%H%M') # 精确到分钟，避免秒级重复压力
uid = base64.b32encode(uuid.uuid4().bytes).decode('ascii').rstrip('=')
return f'TR{dt}{uid[:16]}' # TR2405221523N5TVG4E7M2XKZQJF- 前缀控制可读性，后缀保证唯一性；即使前缀重复，后缀仍独立随机
- 截取
uid[:16]不是为了“缩短”，而是避免总长失控（如超50字符）；剩余部分丢弃不影响唯一性，因原始UUID已足够强 - 不用毫秒——
time.time_ns()在容器环境可能不稳定，且增加复杂度得不偿失
数据库和日志里要注意的隐性坑
MySQL中用VARCHAR(32)存base32 ID没问题，但若字段设了utf8mb4，实际每个字符占最多4字节——虽然base32全是ASCII，但引擎仍按最大开销算；更稳妥是显式指定CHARACTER SET ascii或latin1。
另一个坑：Django或SQLAlchemy默认把UUID字段映射为UUIDField，它期望的是标准格式（带连字符），直接塞base32会报错invalid input syntax for type uuid。
- 别用ORM的
UUIDField存自定义ID，改用CharField(max_length=32) - 日志中打印ID时，避免用
str(uuid_obj)——它会还原成带连字符格式，和你库里存的不一致，查问题时容易误判 - 如果要做ID解码回原始UUID（极少数调试场景），得保存原始
bytes或用base32.b32decode(id + '==='[:len(id)%8])补等号再解码
真正麻烦的从来不是生成，而是生成之后怎么让上下游系统都认得、不歧义、不悄悄变形。
