D-U-N-S 用 9 位数标识了全球几亿家企业，中国身份证用 18 位数标识了 14 亿人。同样是在"给事物编号"，设计思路为何天差地别？企业 SKU 只有几千个，却常常用十几位——问题出在哪里？
一、引子
凡事皆需编号：商品要有 SKU，员工要有工号，订单要有单号，客户要有客户号。但"编号"这件事，看起来简单，做起来容易走两个极端：
- 极端一：纯序号，但短到毫无信息量
- 极端二：塞满语义，但长到难以记忆和录入
D-U-N-S 和身份证恰好代表了这两个极端。而绝大多数企业的 SKU，则是在两个极端之间摇摆不定——结果往往既不够短，也不够有意义。
二、两个极端
极端一：D-U-N-S——纯序号的最小化
D-U-N-S（Data Universal Numbering System）是 Dun & Bradstreet 公司为全球企业分配的 9 位唯一标识符。
字段 | 位数
--- | ---
序号 | 8
校验位 | 1
**合计** | **9**
核心设计理念：号码就是一个钥匙，所有信息都在数据库里。
优点：
- 最短：9 位覆盖 1 亿个企业（实际仅需约 4 亿），完全够用
- 最简：纯数字，零编码规则，不会因为业务变化而需要修改号码规则
- 最稳：不需要任何改造，加一位就能扩容 10 倍
代价：
- 离线无意义：看到一个 D-U-N-S 号码，你完全不知道这家公司做什么、在哪里
- 高度依赖数据库：想知道任何信息，必须查库
极端二：中国身份证——语义编码的最大化
中国公民身份证号码 18 位，是语义编码的典型代表。
字段 | 位数 | 有效信息量
--- | --- | ---
行政区划代码 | 6 | ~3,000 种地区
出生日期（YYYYMMDD） | 8 | 365天 × 100年 ≈ 36,500
顺序码 | 3 | 999 人/日/区（含性别）
校验码 | 1 | 校验
**合计** | **18** | **有效编码容量约 10^17**
核心设计理念：号码本身就是一份微型档案。
优点：
- 强自描述：只看号码就能知道籍贯、出生年份、性别
- 离线可用：警察查身份证不用联网，就能判断是否合理
- 强校验：18 位的校验算法可检测所有单位数错误和绝大部分调位错误
代价：
- 长：18 位数字，录错概率远高于 9 位
- 刚性结构：行政区划调整（撤县设区、城市合并）会导致号码不再代表实际意义
- 容量浪费：14 亿人用 10^17 的空间，利用率万分之一不到
两个极端的对比
维度 | D-U-N-S（纯序号） | 身份证（语义）
--- | --- | ---
位数 | 9 | 18
理论容量 | 10^8 | ~10^17
实际覆盖率 | ~40% | ~0.001%
离线可读性 | ❌ | ✅
数据库依赖 | 强 | 弱
扩容成本 | 低（加一位） | 极高（格式固定）
场景 | 企业纯索引 | 公民强防伪+离线识别
两种设计都没有错，它们的差异来源于根本的场景需求不同。D&B 拥有全球企业数据库，企业之间也不需要"看号识人"；而身份证必须在无网络的环境下被公安、银行等机构快速检验。
三、企业 SKU 的困境
回到企业 SKU 的问题上来。
国内很多企业只有几千个 SKU，却用了 12-15 位编码——有的甚至用字母+数字混编。为什么？
常见原因：
- 部门接力：产品部编品类码 → 采购部加供应商码 → 仓储加库位码 → 运营加季节码。每加一段，没人敢删旧的。
- "以防万一"综合征：现在只有 3 个品类，但预留了 3 位（够 999 个）；只有 10 家供应商，但预留了 3 位（够 999 家）。
- 历史包袱：ERP 换过三次，每次加一位前缀标识数据来源。没人敢清理。
- 无顶层设计：没有人对"编号体系"整体负责。各做各的，层层叠加。
结果就是：一个既不能像 D-U-N-S 那么短，又不能像身份证那样真正读得出信息的"驼子"。
四、平衡之道：编码设计六原则
好的编码设计，需要在六个维度上找到平衡。
原则一：唯一性（最底层）
编号的首要使命。必须保证不重复。
- 集中发号 vs 组合字段发号
- 自增序号 vs 雪花算法 vs UUID
原则二：简洁性（最直接）
越短，录入错误越少，存储和传输成本越低。
- 每减少 1 位，误码率下降约 10%
- 每减少 1 位，千亿级数据存储节省数百 GB
原则三：可读性（最有争议）
该不该让号码"本身有意义"？
- 纯序号：机器友好，人记不住
- 语义编码：人友好，但容易扩不动
原则四：可扩展性（最容易被忽视）
今天的编码，三年后还够用吗？
- 纯序号：加一位即可
- 语义编码：每个字段都可能成为瓶颈
原则五：稳定性（最贵重的）
编码规则一旦确定，最好永不更改。改编码方案的代价几乎等于换一套 ERP。
原则六：校验性（成本最低的保险）
在编码中加入校验算法，用极小的成本拦住绝大多数录入错误。
- 身份证的 ISO 7064:1983, MOD 11-2
- Luhn 算法（信用卡号）
- D-U-N-S 的专有校验
五、如何为 SKU 找到平衡点
不同规模的企业，平衡点不同。
小规模（<1000 SKU）
推荐：4-6 位纯数字号 + 1 位校验
0000C ~ 9999C- 10000 个组合，覆盖 1000 SKU 绰绰有余
- 纯数字手输快，校验位防错
- 每年加个几百个 SKU，十年也用不完
中规模（1000～50000 SKU）
推荐：2 位品类缩写 + 6 位序号 + 1 位校验
EL-004205-C
（电子产品 - 第 4205 号）- 只有一段语义，未来品类增减不影响序号层
- 品类用字母而非数字，一眼可区分
- 品类码固定 2 位，用完加 1 位即可（EL→ELE）
- 序号层 6 位 = 100 万，中规模企业很难用完
大规模（50000+ SKU）
推荐：纯 8-10 位序号 + 1 位校验，完全交给数据库
04205817C- 当 SKU 数量大到一定程度，语义编码的人读优势递减
- 没有人能记住 5 万种商品的编码规则
- 全部交给数据库和扫码枪，最短即最优
六、还有几个经验之谈
- 别用字母编码业务含义，除非你确认它永远不变。
今天编A=服装, B=食品，三年后跨境业务来了，C到Z都不够用。不如让字母在序号段里自然增长。 - 永远保留 1 位预留位。
设计时在末尾放一个0，告诉所有人：这位置是留给未来的。到真要扩容那天，变成0-9即可。 - 不要用 UUID 做对外编号。
550e8400-e29b-41d4-a716-446655440000虽然后端很方便，但无论是录入、报修还是客服沟通，都是噩梦。内部用 UUID 关联，外部永远转成短编码。 - 校验位不贵，值得每位编码都配上。
一位校验位几乎不增加存储成本，但能堵住约 90% 的手动录入错误。
七、小结
设计方案 | 适合场景 | 典型位数
--- | --- | ---
纯序号 + 校验 | 大规模、高频次、扫码为主 | 6-10
单语义段 + 序号 + 校验 | 中规模，人为介入较多 | 8-12
纯语义编码 | 防伪、离线验证、强识别需求 | 15-18
多层语义编码 | ❌ 不推荐，除非有明确法规约束 | 12-15
回到最初的问题——为什么 D-U-N-S 能用 9 位覆盖全世界，而企业 SKU 只有几千个却用十几位？
答案不是"D&B 技术更好"，而是：
D-U-N-S 知道自己只是把钥匙，所有信息都在数据库里。 身份证知道自己是一份微型档案，要在离线场景下自证明。 而大多数企业 SKU，既没想清楚自己是钥匙还是档案，也没有人真的对编码体系负责。
编码设计的本质，是在简洁性和自描述性之间找到适合自己场景的平衡点。这两种需求没有优劣，但你不做选择，最终就会被历史惯性替你选——而那通常是最坏的结果。
*作者：喜乐君* *唯有知识让我们免于平庸*
作者：xilejun · v1.0 · 2026-05-22
📖 相关文章
● 风控触发规则仪表板设计案例
● 金蝶云星空 — 采购业务主题与数据表速查 1.1
● [航空] 旅客航司权限控制：两种方法对比与最佳实践
● 业务对象及其到数据的映射：不要把「航班号」拆成两半
● 折腾"龙虾"的人，20年前就"命中注定"了
——————————————————————————————
No comments yet