· 全部指南
UUID 与 ULID 的用途
分布式系统需要无需中央分配器、跨机器唯一的标识符。数据库作主键、日志作 request id、对象存储作文件名、对外 API 替代会泄露业务量的自增整数，都离不开它们。
UUID v4（随机）是多数语言的默认：122 位随机使碰撞概率在实际部署中可忽略。ULID（通用唯一按字典序可排序标识符）用 48 位时间戳 + 80 位随机，编码为 26 字符 Crockford Base32——按创建时间排序，利于 B-tree 索引与日志压缩。
uuid-generator 与 ulid-generator 在浏览器本地批量生成，用于 fixture、压测与 schema 设计，不上传 Towalles 服务器。示例：性能测试灌入一万条假订单，而不打可能成为单写瓶颈的数据库序列。
不关心排序、要到处都有标准库支持时选 UUID v4。需要时间序改善索引局部性或便于日志 grep 时选 ULID。运行环境支持时 UUID v7（时间有序，RFC 草案）可兼顾二者。
版本选择
并非所有 UUID 版本可互换。v1 嵌入 MAC 与时间——客户端生成时有隐私顾虑。v4 纯随机——适合公开资源 ID。v5 对命名空间与名称哈希——确定性，利于幂等导入（uuid5(DNS, "user:alice@example.com") 恒得同一 ID）。
勿把 UUID/ULID 当安全令牌。它们无签名与过期；猜测虽难，授权应使用 token-generator 输出或专用密码学 secret。常见错误：用 Math.random() 造 v4（非 CSPRNG）；去掉连字符却未文档化规范格式；以为大小写对所有数据库无关（标准说不敏感，部分工具仍有分歧）。
存储与展示
PostgreSQL 用原生 UUID，SQL Server 用 uniqueidentifier，无原生类型时用 CHAR(36)。API 统一小写带连字符。ULID 用 CHAR(26) 或 VARCHAR(26)；字典序近似时间序。
在客服工具中向用户展示 ID 并提供复制按钮；避免 ULID 换行断开。URL 中 UUID 虽长但可接受；若在意美观可对外用 slug 别名，内部仍保留不可变 UUID 主键。外键两侧都要索引——仅有 UUID 主键、引用列无索引会导致全表扫描。
迁移提示：给现有 SERIAL 表补 UUID 键——用 uuid-generator 回填、双写过渡期再切换——比原地改序列更少停机。
常见误区
「碰撞不可能」是概率陈述而非保证——高吞吐写入须 UNIQUE 约束并在冲突时重试。对外 API 勿暴露顺序 id INT 泄露量级；应暴露 UUID/ULID 或雪花 ID。
仅用毫秒时间戳在突发流量下会碰撞。纯随机 ID 若无索引友好排序可能碎片化 B-tree——ULID 或 v7 可缓解。日志只打 UUID 而不关联 trace id 会加大跨服务排障难度——资源 ID 应与 OpenTelemetry trace 上下文配对。
Towalles 生成器适合原型；生产发号仍应经服务层 CSPRNG 与数据库约束，而非未经审查就从浏览器标签页复制进 migration 脚本。
按访问模式选标识符
随机 UUID 分散写入；时间有序的 ULID/UUIDv7 改善局部性。公开 API 应坚持一种承诺——无版本化不要中途换格式。
暴露面
若 URL 中的 ID 映射到无私有鉴权的对象，它就是能力凭证。优先做授权检查，而不是只靠「不可猜 ID」。
迁移
在 UUID 旁引入 ULID 时，显式存类型或使用可区分编码。过渡期双写并校验外键。
标识符策略评审
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。