本地草稿ID

离线场景的 ID 痛点

在离线或本地创建草稿、临时跟进单时，开发者常面临两个问题：UUID 过于冗长（如 550e8400-e29b-41d4-a716-446655440000），且部分业务需要 URL 安全的短 ID。若依赖后端发号服务，又会破坏离线可用性，并引入不必要的网络延迟。

本地草稿 ID 的实现逻辑

该技能通过 nanoid 在本地生成随机字符串 ID，核心能力包括：

• 纯本地生成：无需后端请求，直接在客户端或 Node.js 环境中生成 ID，避免网络依赖。
• 灵活配置：支持自定义字母表（如去掉易混淆的 0O1lI 字符），并允许添加业务前缀（如 dft_），增强可读性。
• 碰撞控制：默认推荐 12～16 位长度，通过扩大字母表和合理长度平衡碰撞概率与可读性（例如 16 位 nanoid 的碰撞概率远低于同长度 UUID）。

关键实现步骤：

1. 统一工厂函数：封装 createDraftId() 方法，统一处理字母表、前缀和长度配置。
2. 自测验证：连续生成 100 个 ID 进行唯一性检查（演示级验证，生产环境需更严格测试）。
3. 文档约束：明确标注「正式单据号仍以服务端为准」，避免误用本地 ID 作为业务主键。

适用边界与安全提醒

• 仅用于草稿/占位：适合本地草稿、临时附件占位，不可用于需全局唯一且持久的正式单据号。
• 禁止当密钥：nanoid 生成的 ID 不具备加密安全性，密码、令牌等敏感场景需使用 crypto.randomBytes() 等加密随机源，并通过服务端生成。
• 与 Sqids 区分：Sqids 用于混淆数字 ID（如将 1234 转为 8Kz1），而本技能生成随机字符串 ID，两者不可混用。