自动编号既要方便业务识别，也要保证系统唯一和并发安全。本文说明如何拆分内部标识、业务编号、前缀规则与重号处理。
低代码应用的自动编号不应只追求“看起来整齐”，而应同时解决系统唯一、业务可读、规则可维护和历史可追溯四个问题。稳妥的做法是把系统内部唯一标识与业务人员使用的单号分开：前者负责准确关联记录，后者负责沟通、检索和归档。
订单号、工单号、项目编号和资产编码经常被当成普通文本字段处理。数据量不大时似乎没有问题，一旦多人同时提交、单据跨年度延续或编号规则需要调整，就容易出现重号、跳号、旧记录失去解释等情况。编号设计因此属于数据治理问题，而不只是表单配置细节。
先区分内部标识与业务编号
内部标识用于让系统稳定识别一条记录，通常不需要被业务人员记住，也不应随名称、组织或日期变化。业务编号则面向使用者，可以包含单据类型、日期或组织简称，但其主要作用是沟通和查询。
如果把业务编号直接当作所有关联关系的唯一依据，后续改号会影响工作流、接口和历史引用。更可靠的方式是保留不可变的内部标识，同时把业务编号作为受控字段，并明确是否允许修改、谁能修改以及修改后如何留痕。
编号规则要回答哪些问题
一套可执行的自动编号规则至少要明确编号对象、生成时点、序列范围和异常处理。前缀并非越丰富越好，只有真正有助于识别的维度才应进入编号。
- 编号是在保存草稿、提交审批还是审批通过时生成；
- 序列是全局连续，还是按年度、组织或单据类型分别递增；
- 撤回、作废和删除后是否复用已经占用的号码；
- 批量导入、接口写入和人工补录是否遵循同一规则；
- 规则变更后，旧编号如何继续被解释和检索。
并发与重号需要在系统层处理
多人同时创建记录时，先查询当前最大值再加一并不可靠。两个请求可能读到同一个最大值，从而生成重复号码。编号服务应以原子方式占用序列，并在写入前验证唯一性；如果失败，应明确返回错误而不是静默覆盖。
在明道云等低代码平台中，可以结合自动编号能力、工作流和唯一性校验设计生成链路。若编号来自外部系统，还要确认哪一方是主责来源，避免两套规则同时写入同一字段。
可读性与连续性应保留边界
业务人员常希望编号完全连续，但作废、测试、事务回滚或系统异常都可能形成空号。只要每个号码唯一、生成过程可追溯，空号本身通常不代表业务事实缺失。若合规或审计场景要求解释空号，应额外记录占号时间、来源和结果，而不是通过人工回填掩盖过程。
编号也不宜承载过多会变化的信息。例如把部门、负责人或项目状态全部编码进去，一旦组织调整就会产生误导。可变化属性更适合通过结构化字段筛选和统计。
上线前怎样验证自动编号
验证时应同时覆盖多人并发提交、撤回重提、批量导入、跨年切换、规则升级和接口创建等场景。还要检查列表搜索、打印模板、消息通知和外部系统是否都使用了正确的标识字段。
好的编号方案不是规则最复杂，而是责任清楚、行为一致、异常可解释。先定义内部标识与业务单号的边界，再决定前缀和序列，通常比从一个漂亮的编码格式反推系统逻辑更稳妥。
常见问题
自动编号必须连续且不能跳号吗？
多数业务系统首先要求唯一和可追溯，并不一定要求绝对连续。撤回、作废或事务回滚可能形成空号；如果业务确实需要解释空号，应保留占号记录和结果状态，而不是复用旧号码。
编号中要不要加入部门和日期？
只有当这些信息稳定且能明显帮助识别时才适合加入。部门可能调整，过多日期层级也会让规则复杂。经常变化的属性应保存在独立字段中，通过视图和搜索使用。
低代码应用如何避免多人同时提交造成重号？
应使用平台提供的原子序列或可靠的编号服务，并对业务编号设置唯一性校验。不要采用“查询最大号再加一”的简单做法，因为并发请求可能取得相同结果。
已有编号规则可以修改吗？
可以，但应确定生效时间、旧记录保留方式和外部接口影响。通常不建议批量改写历史编号；新规则从明确日期或版本开始使用，并保留规则版本说明更便于追溯。