标记生成基础：编码原理、数据结构和容量计算

说到溯源标记的生成，很多人第一反应就是“随机生成一串字符完事”。其实没那么简单。我个人习惯把标记生成拆成三个问题：数据怎么编、存成什么结构、占多少空间。搞懂了这三点，后面绑定、查重、扩容都不容易翻车。

1. 编码原理：从比特到标记

溯源标记本质上是一串比特——只不过我们把它变成了人能读写、机器能传输的字符串。那比特怎么变成字符串呢？最常见的路子有三种。

1.1 二进制 & 十六进制

最朴素的编码。把二进制每4位映射成一个十六进制字符（0-9 a-f）。举个例子：128 bit 的 UUID 用十六进制就是 32 个字符，加上4个短横线是 36 个字符。好处是直观，坏处是长度偏长。

我在项目里见过有人直接拿十六进制标记溯源数据，每次传输多费30%带宽。后来我才换成了更紧凑的方案。

1.2 Base64 & URL Safe Base64

Base64 每6位映射成一个字符（A-Z a-z 0-9 + /），输出长度大约是原始字节数的 4/3 倍。128 bit（16字节）用 Base64 只需 24 个字符左右，比十六进制节省了 12 个字符，传输效率提升明显。

但要注意——标准 Base64 包含 '+' 和 '/'，在 URL 里得转义。所以我一般推荐URL Safe Base64，把 '+' 换成 '-'，'/' 换成 '_'，末尾的 '=' 也去掉。这样生成的标记可以直接塞进 URL 路径而不需要额外编码。

1.3 哈希摘要

很多溯源场景并不需要真正的随机数，而是要把原始数据（比如订单ID + 时间戳）映射成一个固定长度的摘要。这时候就用哈希：SHA-256 截断前 64 bit，或者 MD5（不推荐，但遗留系统很多在用）。

哈希的好处是确定性强：同样的输入永远得到同样的标记。适合做内容寻址或者去重。坏处是：你需要考虑碰撞概率——64 bit 的哈希根据生日悖论，20 亿条数据左右才会出现 50% 的碰撞概率。大多数中小系统够用。

编码对比表

编码方式	表示粒度	128 bit 输出长度	字符集	URL 安全
十六进制	4 bit/字符	32 字符	0-9 a-f	是
Base64	6 bit/字符	24 字符	A-Z a-z 0-9 + /	否（需转义）
URL Safe Base64	6 bit/字符	22 字符（去填充）	A-Z a-z 0-9 - _	是
二进制（原始比特）	1 bit/位	128 bit	0/1	否

2. 数据结构：标记怎么存

编码只管了“比特变字符”，但标记在内存和数据库里具体怎么组织，是另外一回事。我归纳为三种主流结构。

2.1 固定长度结构

每个标记占用相同字节数，比如 16 字节（128 bit）的 UUID，或者 8 字节（64 bit）的自增ID。优点是内存布局简单，随机访问快，数据库索引效率高。缺点是灵活性差——你想多塞点信息？得重新设计。

2.2 可变长度结构

常见方案是 TLV（Type-Length-Value）。举个例子：一个溯源标记可以包含版本号（Type=0x01）、产品编码（Type=0x02）、时间戳（Type=0x03）三个字段，每个字段用 1 字节标识类型、1-2 字节标识长度、后面跟实际数据。这样不同场景可以复用同一个标记协议，长度不固定，解析时根据 T 和 L 来跳着读。

2.3 版本号 + 载荷 + 校验

很多大型系统把标记设计成三段式：1 字节版本号 + N 字节载荷（编码后的数据） + 2 字节校验和。校验和可以是 CRC16 或简单的 XOR。这样做的好处是：版本号让你未来能升级协议；校验和能防御传输或存储时数据错位。

数据结构对比

类型	优点	缺点	适用场景
固定长度	内存紧凑，索引高效	扩展性差	标记量级超大且不变更结构
TLV 可变长度	灵活，可扩展	解析慢，碎片化	多品类、阶段迭代的产品
版本+载荷+校验	可演进，容错强	额外 3 字节开销	分布式系统、跨团队协作

3. 容量计算：能存多少、占多少

容量计算是很多人忽略的地方。我见过一个系统上线三个月后标记用完了，不得不改代码重新生成，迁移成本高得离谱。所以一开始就要算清楚。

3.1 最大标记数

如果你用 N bit 来存唯一标识，理论最大不重复标记数是 2^N。但实际要考虑碰撞容忍度。比如 64 bit 大约 1.8×10^19 个，看起来很大？假设每秒生成 1000 万个标记，用 1 年才 3.15×10^14 个，离上限还远。但如果把 64 bit 全用来做随机数，而且你要求近似零碰撞概率，那就得留足够安全空间。我通常按容量安全系数 10%来算：预计最大标记数不超过 2^N / 10。

3.2 存储空间

存储空间包括标记本身的字节数，以及索引、校验和的附加开销。举例：一个 128 bit（16 字节）的标记，如果用 Base64 编码后是 24 个字符（UTF-8 下 24 字节），每存储1亿条标记，仅原始数据就是 2.4 GB。加上索引（B+树节点、主键）通常还要 1.5~2 倍。我在项目里给客户的建议是：标记长度每增加 1 个字符，总存储成本大约上涨 3%~5%（因为索引膨胀）。

3.3 容量速算表

标记比特数	理论最大标记数	URL Safe Base64 长度	1 亿条占用存储（原始）	带索引预估
64 bit	1.8×10^19	11 字符	1.1 GB	~2.2 GB
128 bit	3.4×10^38	22 字符	2.2 GB	~4.4 GB
256 bit	1.1×10^77	43 字符	4.3 GB	~8.6 GB

你看，128 bit 对大多数场景已经绰绰有余了。但如果你用的是 64 bit 且采用随机生成，要小心生日悖论——当标记数达到 2^32（约 42 亿）时，碰撞概率就会超过 50%。所以工业级系统一般推荐 128 bit 起步。