单据编号生成器

痛点：业务单号的生成痛点

在企业运营中，合同、发票、提成单等业务单号是数据流转的锚点。常见的做法是用 Math.random() 或简单的自增 ID 凑数，但这会带来几个具体问题：

• 可读性差：无法一眼看出单据类型与生成时间。
• 并发冲突：多标签页或多用户同时新建单据时，简单的 localStorage 计数器极易撞号。
• 持久化缺失：刷新页面或冷启动后，序号重置导致单号重复。

本技能（小四原创）提供了一套标准化的单号生成逻辑，核心在于 前缀 + 日期 + 持久化序号 的拼装，并区分了演示环境与生产环境的实现方案。

核心机制与工作流

1. 前缀字典配置：根据单据类型建立映射，如合同为 HT、发票为 FP、提成单为 TC。
2. 单号生成入口：在新建单据时调用 makeDocSerial，该方法负责按格式 {prefix}{yyyyMMdd}{seq:4} 拼装单号，并在界面上以只读且可复制的形式展示。
3. 持久化策略：

- 演示环境：通过 localNextSeq 将序号持久化在 localStorage，确保单次刷新不撞号。
- 生产环境：必须对接后端服务，利用数据库的原子操作（如 SELECT FOR UPDATE 或分布式锁）保证跨节点、跨并发场景下的绝对唯一。

1. 边界处理：默认同日前缀下序号递增，跨日后归零（或按产品约定）；非法前缀需被拒绝。

适用边界与避坑指南

• 禁止随机单号：正式业务（尤其是合同与发票）绝不可用 Math.random()，本技能生成的是可读业务单号，而非仅供前端使用的草稿 ID（如 nanoid）。
• 并发限制：虽然 localStorage 在单浏览器实例内可持久化，但在多标签页同时操作时仍存在微小竞态。生产环境应严格依赖服务端原子取号。
• 归零策略：跨日归零是默认逻辑，若业务需要全局连续，需在服务端进行调整。