ULID / NanoID 生成器
批量生成 ULID 与 NanoID，ULID 可解析时间戳、UUID 互转，支持同毫秒严格递增的单调模式。
UUID v4 好处是不用协调、撞库概率趋近于零，坏处是完全无序——做数据库主键时插入位置随机，B+ 树页分裂频繁，按时间排序还得额外存一列。ULID 就是冲着这个来的：48 位毫秒时间戳 + 80 位随机数，128 位与 UUID 等宽，但按字典序排序就是按时间排序。
本工具批量生成 ULID 与 NanoID，随机源都是 crypto.getRandomValues（密码学安全）。ULID 的 Crockford 字母表去掉了 I/L/O/U 四个易混字符；解析方向贴入任何 ULID 都能读出毫秒级生成时间并给出 UUID 写法（同一 128 位的两种表示），手抄的 o/i/l 误写可以自动纠正。需要主键场景时打开「单调递增」：同一毫秒内生成的 ID 严格递增。
ULID 的结构与可排序性
ULID 固定 26 字符：前 10 字符编码 48 位毫秒时间戳（可用约 8.9 万年），后 16 字符编码 80 位随机数，整体按 Crockford Base32 编码。因为时间在高位于前，任何按字符串排序的系统（数据库 ORDER BY、文件名列表）得到的都是时间序——这是它相对 UUID v4 最实际的优势。
什么时候用 NanoID
NanoID 是「短 ID」路线：21 字符时碰撞概率已与 UUID v4 相当（约 each 10^-21 量级），更短的长度适合短链、分享码、前端临时 key 这类对长度敏感的场景。它不带时间信息、不可解析，选型原则很简单：要按时间排序选 ULID，要短选 NanoID，要最广泛兼容选 UUID。
常见问题
- 单调模式是什么？什么时候需要？
- 同一毫秒内普通 ULID 的随机段是独立随机的，生成的顺序与大小关系不保证。单调模式在同一毫秒内对上一条的随机段 +1，保证严格递增。以 ULID 做数据库聚簇主键、且同毫秒内会写入多条时需要它，否则插入仍可能页分裂。
- ULID 能转成 UUID 吗？
- 两者的 128 位可以互相映射（本工具提供 ULID → UUID 写法）。但注意 UUID 有版本位与变体位的约定，强行按 UUID 解析 ULID 会得到「不符合规范」的版本号；互转适合存储层统一用 16 字节列的场景，不适合拿去做协议兼容。
- 生成是在本地进行的吗？会重复吗？
- 全部在浏览器内用 crypto.getRandomValues 生成，不上传。重复概率：同一毫秒内 2^80 个随机空间，工程上视为不会重复；单调模式在同一毫秒内严格递增则从机制上排除了同毫秒重复。