uuid4()是默认首选，因其使用os.urandom()生成强伪随机数，无需依赖时间戳或MAC地址，避免隐私泄露与可预测性问题，冲突概率极低（2⁻¹²²），适合通用唯一标识场景。
uuid 模块生成的不是“随机数”，而是基于算法或系统信息生成的唯一标识符；直接调用 uuid4() 是最常用且安全的做法，但要注意它不保证全局绝对唯一（只是概率极低冲突），也不适合用作加密密钥或会话 token。
为什么 uuid4() 是默认首选？
它使用强伪随机数生成器（os.urandom()）构造 128 位 ID，无需网络地址或时间戳，避免了 uuid1() 可能暴露主机信息、uuid3()/uuid5() 依赖输入字符串哈希带来的可预测性问题。
常见错误：误以为 uuid1() 更“可靠”——其实它在容器或虚拟机里可能因 MAC 地址重复或时钟回退导致重复 ID；而 uuid4() 在同一台机器上连续调用百万次，冲突概率仍远低于硬件故障率。
- 不要在高安全场景（如 API token）直接用
uuid4()，它不抗猜测，应配合secrets.token_urlsafe() - 若需可排序的 ID（如数据库主键），
uuid1()或ulid更合适，但得接受时间戳暴露风险 -
uuid4().hex返回 32 位小写十六进制字符串（无短横线），str(uuid4())返回带短横线的标准格式（8-4-4-4-12）
如何避免生成重复 UUID 的假象？
真正冲突几乎不可能发生，但开发中常因误操作“看起来重复”：
立即学习“Python免费学习笔记（深入）”；
- 变量复用：写成
uid = uuid4(); do_something(uid); uid = uuid4()却忘了第二步，反复用同一个对象 - 测试时硬编码：比如单元测试里写死
uuid.UUID('12345678-1234-5678-1234-567812345678')，结果多个测试共用同一值 - Django/SQLAlchemy 等 ORM 默认对
UUIDField使用default=uuid.uuid4（无括号！），这是函数对象；若写成default=uuid.uuid4()（带括号），则迁移时只生成一次，所有记录都用同一个值
uuid3() 和 uuid5() 什么时候该用？
它们是命名空间确定性哈希，输入相同字符串 + 相同命名空间，输出永远一致。适用于需要“可重现唯一 ID”的场景，比如把用户邮箱映射为固定 ID 而不暴露原始邮箱。
关键区别：uuid3() 用 MD5（已不推荐），uuid5() 用 SHA-1（更安全）；命名空间必须是标准 UUID，如 uuid.NAMESPACE_DNS 或自定义 uuid.UUID('...')。
- 示例：
uuid.uuid5(uuid.NAMESPACE_DNS, 'github.com')每次都返回相同 UUID - 不能用于隐藏敏感数据：哈希可被暴力破解，别用它“脱敏”手机号
- 命名空间选错会导致跨系统 ID 冲突，比如两个服务都用
NAMESPACE_X500但对同一字符串计算，结果相同——这有时是优点，有时是坑
真正要小心的不是 UUID 本身，而是把它当随机数用、当密码用、或者没理解 ORM 中 default 参数的调用时机。生成本身很简单，麻烦总在下游怎么用。
