ID 选型：UUID / ULID / NanoID

背景

分布式系统需要无需中心发号的 id。UUID v4 随机；ULID 可排序；NanoID 短且 URL 友好。对外暴露顺序 id 可能泄露业务量。

对个人站与小团队而言，把这类实践写进构建与规则文件，比事后救火便宜。0xKEV 提供浏览器本地工具，方便在不上传的前提下先辨认样本、再决定是否交给自动化。

要点

1. 内部与外部 id 可分离。
2. 不要当密钥。
3. 数据库索引友好性。
4. 碰撞概率与长度。

另外记住：可验证优于「感觉好了」。能量化的用命令与指标；不能量化的至少留下检查清单与复盘记录。

怎么做

1. 明确使用场景。
2. 统一生成库。
3. 测试序列化。
4. 日志截断策略。

建议把上述步骤收成团队检查项或 CI 门禁。首次落地选一个痛点场景试点，跑通后再横向复制，避免一次性铺开导致无人维护。

辨认现状 → 写清目标与非目标 → 小步改 → 验证 → 文档化

和本站工具

UUID、ULID、NanoID。

入口：Tools 首页（本地运算、免注册）。隐私说明见 隐私。处理生产样例前请先脱敏。

安全令牌请用 CSPRNG，不要用普通随机 id 冒充。

落地时把「谁负责、何时复查」写清楚，避免清单成为墙上标语。可用日历提醒做季度回顾，删除过时步骤，补充新的失败案例。与本站其他速记交叉阅读，能把部署、安全与成本视角连成一张实践图。

实践上建议建立「最小可重复检查」：每次改动后用同一组命令或同一份清单验证，把结果贴进变更说明。这样后来者不必猜测你当时是否测过。若涉及自动化，先在预发或本地复现，再放到生产路径；失败时保留现场（日志、配置摘要、版本号），方便复盘而不是只留下一句「修好了」。与安全相关的步骤务必默认拒绝、显式允许；与成本相关的步骤务必带预算与度量。0xKEV 速记栏只记录可核实的工程事实，方便检索与内链，不替代你团队自己的 Runbook。

小结

本文只讨论可执行的工程做法。把边界、验证与文档当作一等公民，工具与自动化才能真正省时间，而不是放大事故面。