应根据场景选择UUID版本：默认用v4（安全随机）；需时间序或溯源选v1（node=None避MAC泄露）；需确定性映射选v5（不用v3）；v2已弃用。
Python 的 uuid 模块提供了五种标准 UUID 版本（v1–v5），选哪个取决于你对**唯一性来源、可预测性、隐私性、性能和是否需要可追溯性**的要求。没有“最好”的版本，只有“最适合场景”的版本。
UUID v1：时间+MAC 地址，适合内部系统追踪
v1 由当前时间戳和机器的 MAC 地址（或随机数替代）生成，全局唯一且天然有序（按时间递增）。优点是碰撞概率极低、可排序、能反推生成时间和主机；缺点是暴露 MAC 地址（有隐私风险），且依赖系统时钟稳定性。
适用场景：
• 内部日志 ID、数据库主键（不对外暴露）、需要时间序的事件标识
• 多服务共用同一物理机/容器且需强唯一保障
注意：若担心 MAC 泄露，可用 uuid.uuid1(node=None) 让 Python 自动用随机数代替 MAC。
UUID v4：纯随机，最常用也最安全
v4 完全基于密码学安全的随机数（os.urandom）生成，不依赖时间或硬件信息。不可预测、无隐私泄露风险、实现简单、性能好。
立即学习“Python免费学习笔记（深入）”；
适用场景：
• API 请求 ID、临时令牌、用户会话 ID、公开暴露的资源标识符
• 对可追溯性无要求，只求高概率唯一
这是绝大多数 Web 应用和微服务的默认选择——除非你明确需要时间序或确定性。
UUID v3/v5：基于名字哈希，适合确定性生成
v3 使用 MD5，v5 使用 SHA-1，都是对“命名空间 + 名字”组合做哈希后固定格式化为 UUID。相同输入永远产出相同 UUID，适合构建可重现的标识体系。
区别：
• v3 哈希强度弱、已不推荐新项目使用
• v5 更安全，应优先选用
适用场景：
• 将用户名、邮箱、URL 等业务标识“稳定映射”为 UUID（如用户 ID 固定化）
• 构建去中心化系统中无需协调的命名空间 ID（如 DNS 域名 → UUID）
• 缓存键、配置项 ID 等需要确定性且避免存储原始字符串的场合
示例：uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")
UUID v2：已弃用，不要用
v2 是早期 POSIX 特定变体（含本地组/用户 ID），从未被广泛采用，Python 标准库甚至不提供直接生成函数（仅支持解析）。RFC 4122 明确将其标记为“reserved”，请彻底忽略。
总结建议：• 默认选 v4：安全、简单、通用
• 需要时间序或调试溯源 → 选 v1（并设
node=None 避免 MAC）• 需要“同名同 ID”且可验证 → 选 v5（别用 v3）
• v2 不在考虑范围内
