哈希、ID与随机数

UUID 含时间吗？比较 v4 与 v7

使用工具

选择 v4 或 v7 要先明确 ID 的用途。两者文字长度相同，但随机为主的 v4 与前缀含时刻的 v7 排序后信息不同。可少量生成并解析已知例子；这不直接决定数据库性能或认证安全。

定位版本的示例

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx  (v4)
xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx  (v7)

UUID 为一百二十八位，常写三十二位十六进制加连字符，第三组首位标版本。图中 x、y 是占位，不是有效输入。长度与标点相符也不等于完整格式有效。

将一个生成 UUID 粘回输入栏，会按 UUID 解析而非件数生成。检查 version、variant；它是单值解析，不是多行批量验证。先确认生成与解析版本一致。

生成五个 v4，用行整理排序。v4 没有此用途的生成时刻字段，字典序不还原生成顺序，偶然相同也非读出时刻。需要时序时应考虑独立创建时间或排序字段。

随机 ID 不同于明显序号，但不能让仅凭 ID 即可访问的设计自动安全。公开标识与权限检查应分离，少量样例不重复也不证明绝对唯一。

解析 RFC 9562 的 v7 示例

017f22e2-79b0-7cc3-98c4-dc0c0c07398f
1645557742000 ms
2022-02-22T19:22:22.000Z

解析可见版本 7、Unix 毫秒 1645557742000 和 UTC。v7 前四十八位为 Unix 毫秒，不同时刻的规范表示排序会反映该时刻部分，与 v4 无此字段不同。

可读时刻不证明生成者或时钟正确。该例就是公开固定值，可被复制或构造。解析时刻只是参考，公开 ID 还需考虑暴露时间是否合适。

同毫秒排序取决于余位生成与状态管理。SheepDev 使用已安装 uuid 库，但不保证跨设备、进程、重启的全球统一顺序。时钟差异也使关键事件顺序不能只靠 ID。

数据库 UUID 类型或自定义二进制布局的比较规则也需核对。行排序正确不证明索引或查询相同，应以受控小数据检查存储、比较器和实际查询。

时间顺序可辅助存储设计，但性能受索引、量、写入模式和查询影响。工具不连 DB 或测性能。先写需要时刻型还是随机标识；若以性能为由，应测试真实工作负载。

记录版本、格式结果、v7 参考时刻及生成或解析操作。格式有效不等于可信，应用唯一性与权限检查需独立保持，区分小实验与运营保证。