关于 ULID 生成器
ULID 生成器创建 26 个字符、按字典序可排序的标识符，是 UUID 在需要按时间就近排序场景下的理想替代。ULID 由 48 位毫秒时间戳加上 80 位随机数组成，既保留全局唯一性，又让新生成的 ID 天然大于旧的 ID，非常适合作为数据库主键、日志追踪号或消息队列的排序键。本工具在浏览器本地用 crypto 生成符合规范的 ULID，可一次性批量产出多个，并支持与 UUID 互相参考对照。所有随机性来自密码学安全源，结果直接在页面复制使用，无需后端参与，是分布式系统与事件溯源中排序友好型 ID 的轻量来源。在事件溯源与日志系统中，排序友好的 ID 还能减少索引碎片并加快范围查询的速度；相比无序的 UUID，它在按时间拉取最近记录时不必额外排序，是高并发写入场景下兼顾唯一性与性能的合理选择，也能与站内 UUID 工具对照使用。
这类标识的核心卖点是「可排序」，理解它的排序依据才能用对。它的前半段编码了生成时刻，因此按字典序排列即等价于按时间先后排列，这让它在需要按时间检索或分页的数据库里比纯随机标识更有优势；后半段是随机部分，用于在同一时刻内区分不同记录。正因为前半段承载时间，生成速度极快时的排序稳定性就取决于实现是否做了单调递增处理。
同一毫秒内生成多条时，顺序是否稳定取决于实现细节。若随机部分完全独立生成，同一毫秒内的若干条记录在排序时先后不定；而做了单调递增处理的实现会保证后生成的排序值更大，从而让「先创建的先出现」这一直觉成立。在使用它作为数据库主键并依赖顺序分页时，应当先确认这一点，否则分页在临界位置可能出现重复或遗漏。
系统时钟回拨会破坏时间有序的前提，这是分布式环境里必须考虑的情况。当服务实例的时间被同步机制向后调整，新生成的标识时间部分可能小于先前生成的，排序随之错乱；若实现没有检测回拨并采取等待或降级策略，还可能在同一时刻生成相同的值。因此在多实例部署下，应先了解标识生成库对回拨的处理方式，而不是假设时钟总是单调向前。
编码形式与大小写需要与存储层对齐。同一组数据可以有不同的字符串表示，有的形式使用全部大写字母数字，有的则包含易混淆字符。若存储层做了大小写不敏感的归一化，两种形式的比较结果会与预期不同；而字符串排序的行为也受数据库排序规则影响，在强调时间有序的场景里，应确认排序规则与编码字符集的顺序一致。
最后，它并不适合所有标识场景，与随机标识各有取舍。随机标识的优势是分布均匀、不泄露生成时间，因此适合不希望外部推断创建时间的场合；时间有序标识的优势是索引友好与便于分页，代价是暴露了生成时刻这一信息。因此选择哪一种，取决于「是否需要按时间范围查询」与「是否介意创建时间外泄」这两个问题的答案。
实现原理
标识由两部分组成：前 48 位是毫秒时间戳，后 80 位是随机值，整体用 26 个可排序字符编码。因此它像 UUID v7 一样按时间有序，但用更短的字符串表达——同样是 128 位信息，可读长度从 36 个字符降到 26 个。代价是字母表不区分大小写，需要额外声明。
同一毫秒内生成两个标识时间前缀相同，仅随机部分不同——因此排序时同一毫秒内的顺序是任意的，不能据此判断先后使用方法
- 打开「ULID 生成器」
- 输入待处理的内容并设置参数
- 根据需要调整输出选项
- 点击「生成」按钮，结果实时显示
- 复制或导出结果
使用场景
- 可排序主键 — 用 ULID 做数据库主键，写入顺序与时间一致，利于范围查询和索引局部性。
- 日志/事件 ID — 给日志或事件流分配能按时间排序的唯一标识，便于追踪先后。
- 分布式生成 — 多个节点无需协调即可生成不冲突且大致有序的 ID。
- 替代自增主键 — 在不暴露记录总量的前提下获得有序 ID，比自增更安全。
- 批量预生成 — 一次生成多条 ULID 用于批量导入或预分配标识。
常见问题
ULID 和 UUID 该怎么选？
需要随机性、跨系统标准兼容选 UUID；需要按时间排序、对数据库索引更友好选 ULID。ULID 的时间前缀让新记录总排在后面，避免随机 UUID 造成的索引碎片。需要 UUID 可用本站的 UUID 生成器。
ULID 一定单调递增吗？
在毫秒粒度上是按时间递增的，但同一毫秒内生成的多个 ULID 顺序由随机部分决定。规范提供了单调模式，可在同毫秒内对随机位递增以保证严格有序。
为什么用 Crockford Base32？
这种编码去掉了 I、L、O、U 等易与数字混淆或拼成脏词的字符，大小写不敏感，更适合人工抄写和在 URL 中使用。
ULID 会暴露生成时间吗？
会。前 10 个字符可解码出毫秒级时间戳，这在需要排序时是优点，但若不希望泄露创建时间，则应改用纯随机的标识。
26 个字符会重复吗？
时间戳占 48 位、随机部分占 80 位。同一毫秒内要发生碰撞需生成天文数字级别的 ID，实际使用中可视为唯一。
ULID 生成速度快，比 UUID 快吗？
两者基本同量级，差别可忽略。ULID 的时间部分来自系统时钟，随机部分来自一次密码学安全随机调用，本地生成无网络开销，适合每秒生成大量 ID 的高并发场景。若某瞬间（同一毫秒内）要生成海量 ULID，可启用规范的单调模式，让随机位在该毫秒内递增以保证严格有序；工程上通常无需额外缓存或预生成即可满足性能要求。
ULID 真能减少数据库索引碎片吗？
能，这是它相对随机 UUID 的主要优势。前 48 位毫秒时间戳让新 ID 大多落在索引尾部，写入近似追加式，页命中率高、页分裂少，范围查询也更顺手。但它只在毫秒粒度上有序，同一毫秒内多个 ID 的顺序仍由随机部分决定。若需要跨节点全局严格递增，可考虑雪花算法类方案；只要求可排序且唯一时，ULID 通常是更轻、更规范的选择。
ULID 和 UUIDv4 该选哪个做数据库主键？
ULID 按时间有序，作为主键时索引插入顺序友好（B+ 树顺序写）；UUIDv4 完全随机，会导致索引页分裂。需要按时间排序、单机生成选 ULID；需要无时间信息泄露、分布式多节点无需协调选 UUIDv4。