应优先使用 crypto.randomuuid() 生成标准 rfc 4122 v4 uuid，因其原生支持、高熵、格式合规；手工正则替换易出错、旧浏览器熵不足、无法通过后端校验；兼容性不足时需 fallback 至 crypto.getrandomvalues() 实现；uuid 不宜存 localstorage 作设备标识，仅适用于前端临时 id 场景。
直接用 crypto.randomUUID()，现代浏览器原生支持，无需引入库、不依赖时间戳、不拼字符串，生成的就是标准 RFC 4122 v4 UUID。
为什么不用手写 xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx 替换函数
这种正则替换写法看似简洁，但存在三个实际问题：
- 生成的字符串不校验格式合法性，比如可能漏掉连字符、长度不对、
y位没强制为89ab之一 - 在 Safari 16.4 之前、Firefox 90 之前等旧版本中，
Math.random()的熵不足，重复概率显著升高（实测万次内出现碰撞） - 无法通过
UUID.validate()类型检查（如果后续要传给后端做严格校验）
crypto.randomUUID() 的兼容性与降级处理
它从 Chrome 117、Firefox 116、Safari 17.3 开始稳定支持。如果你的项目需兼容更低版本（如微信内置浏览器、部分国产安卓 WebView），得加一层 fallback：
function generateUUID() {
if (typeof crypto !== 'undefined' && crypto.randomUUID) {
return crypto.randomUUID();
}
// fallback：仅当 crypto 不可用时才走手工生成（带格式校验）
return ([1e7] + -1e3 + -4e3 + -8e3 + -1e11).replace(/[018]/g, c =>
(c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
);
}
注意 fallback 里用了 crypto.getRandomValues() 而非 Math.random()，保证即使在旧环境也有足够熵；生成结果仍符合 v4 格式（含连字符、4 和 89ab 位正确）。
别把 UUID 存进 localStorage 就当“设备唯一标识”
这是常见误用。原因很实在：
- 用户清缓存、换浏览器、开无痕模式，
localStorage就没了，UUID 重置 → 同一设备变多个“用户” - 同一用户多设备登录时，你本意是区分设备，但若每个设备都独立生成并存本地，后端就收不到“这个 UUID 对应哪台设备”的上下文
- 真正需要设备级标识的场景（如风控、推送），应由后端签发 token 并绑定设备指纹（UA + 屏幕尺寸 + WebGL 渲染特征等），前端只负责透传
如果你只是给前端动态元素打标、表单临时 ID、请求幂等字段，那用 crypto.randomUUID() 生成一次即用，不存、不复用、不跨会话共享，最干净。
真正麻烦的不是生成，而是什么时候不该生成、生成后往哪塞、塞了谁来维护生命周期 —— 这些地方错一点，调试时就会发现 ID 看似唯一，行为却像随机乱跳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
