离线状态生成唯一ID：不依赖网络也能保证不重复

在开发移动应用或桌面软件时，经常会遇到一个实际问题：设备没网了，但用户还在操作，比如填写表单、拍照上传、记录笔记。这时候如果需要给每条数据打上唯一标识，该怎么处理？

为什么要在离线状态下生成唯一ID

很多系统依赖服务器分配ID，但在断网环境下，请求发不出去，程序就会卡住。为了避免阻塞，本地就得自己生成ID，等网络恢复后再同步到服务器。这种做法常见于待办事项App、外勤打卡系统、离线POS机等场景。

UUID：最常用的本地方案

目前最普遍的做法是使用UUID（通用唯一识别码）。它能在本地生成一串128位的字符串，重复概率极低。比如一个标准的UUID长这样：550e8400-e29b-41d4-a716-446655440000。

在JavaScript中，可以用第三方库或浏览器原生API生成：

const id = crypto.randomUUID();
// 输出示例："36b8f84d-df4e-4d49-b662-bcde71fc8016"

Node.js环境也可以通过uuid包实现：

const { v4: uuidv4 } = require('uuid');
const id = uuidv4();

时间戳 + 随机数：轻量级替代方案

如果不想引入额外依赖，可以组合时间戳和随机数。例如：

const generateId = () => {
  const timestamp = Date.now().toString(36);
  const random = Math.random().toString(36).substr(2, 5);
  return `${timestamp}-${random}`;
};
// 输出类似："zrobjxq-1a2bc"

这种方式简单高效，适合对唯一性要求不是极端严格的场景。虽然理论上存在碰撞可能，但在普通应用中几乎不会发生。

考虑设备唯一性：避免同一用户多端冲突

如果同一个用户在多个设备上离线操作，仅靠时间戳或随机数可能不够。可以在ID中加入设备指纹，比如设备型号、本地存储的唯一设备ID等：

const deviceId = localStorage.getItem('device_id') || Math.random().toString(36).substr(2, 9);
if (!localStorage.getItem('device_id')) {
  localStorage.setItem('device_id', deviceId);
}

const id = `${Date.now()}-${deviceId}-${Math.random().toString(36).substr(2, 6)}`;

这样即使两个设备同时操作，生成的ID也大概率不会撞车。

同步时如何处理ID冲突

即便本地ID再唯一，也不能完全排除服务器已存在相同ID的极端情况。因此在数据同步阶段，服务端应做好校验机制。一旦发现冲突，可返回错误让客户端重新生成，或由服务端统一重写ID并反馈给前端。

实际项目中，Firebase这类后端即服务（BaaS）平台就默认支持客户端生成ID，并在后台自动协调，开发者无需过多干预。

小技巧：用有序ID提升数据库性能

UUID虽然唯一，但无序特性会影响数据库索引效率。某些场景下可以考虑使用Snowflake算法的变种，在本地模拟生成趋势递增的ID。比如Twitter开源的Snowflake，结合时间戳、机器ID和序列号，既保证分布式唯一，又利于索引维护。

尽管完整实现需要协调节点ID，在纯离线环境下可简化为“时间毫秒 + 进程内计数器”，也能取得不错效果。