4. Tokenization 原理：令牌生成机制、映射表、反转与不可逆

好，咱们进入 Tokenization 最核心的部分。说白了，脱敏不是把数据藏起来，而是给它换一张“脸”。这张“脸”怎么画、怎么存、能不能再换回来——就是这一章我要跟你聊透的东西。

我记得刚入行那会儿，有个同事直接把身份证号用 MD5 哈希了一下就敢往外传。结果业务方拿到哈希值，发现没法做精确匹配，因为哈希值太长了，而且每次不一样？其实不是长度问题，是映射关系丢了。嗯，这章咱们就一个个说清楚。

4.1 令牌生成机制

令牌（）就是原始数据的替身。生成方式大概分三种，我列个表给你看：

生成方式	原理	典型场景	风险点
随机生成	完全随机字符串，与原数据无任何数学关联	测试数据、非关联脱敏	长度/格式可能不匹配原字段
加密生成	用 AES/SM4 对称加密原数据，输出密文作为令牌	需要还原的合规场景	密钥管理复杂，密文长度膨胀
哈希+截断	对原数据加盐哈希，再截取固定长度作为令牌	无逆向需求的标识替换	碰撞风险、彩虹表攻击

我个人习惯，优先选随机生成。为什么？因为它跟你原始数据之间没有“推理通道”。举个例子，你在测试环境拿到的令牌是 c3f8a9b1，就算你是顶级黑客，也没法从它反推出手机号。当然代价是——你没办法再从令牌变回原始值，除非你有映射表。

加密生成的令牌有个坑：密文长度至少翻倍。比如 18 位身份证号，AES 加密后是 32 字节 hex 字符串。你想象一下，如果对千万级数据做 Tokenization，存储和传输开销会多大。所以除非明确要求“必须能还原”，否则我建议你慎用。

哈希截断呢？我曾经帮某电商做订单 ID 脱敏，他们要求令牌保持原有格式（数字+字母，12 位）。用 SHA256 取前 12 位 hex，结果两周后运维发现存在碰撞——两个不同订单生成了一样的令牌。原因很简单：截断后的哈希空间太小。后来我改成了“随机值+轮询碰撞检测”，才彻底解决问题。

4.2 映射表：Tokenization 的“户口本”

映射表是整个 Tokenization 系统的心脏。没有它，令牌就是孤魂野鬼；有了它，你才能把数据和令牌串起来。

映射表长什么样？一般是个 KV 存储。Key 是令牌，Value 是原始数据。也可能反过来存——看你的查询方向。

-- 常见的映射表结构（使用 MySQL）
CREATE TABLE _map (
     VARCHAR(64) PRIMARY KEY,
    raw_value TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    expires_at TIMESTAMP NULL
);
-- 注意：raw_value 本身可以用列的加密功能再次保护

映射表有几种存储模式，我帮你梳理一下：

• 内存模式：Redis / 本地 HashMap。查询极快（微秒级），但停机丢数据（除非持久化）。适合令牌寿命短的小批量场景。
• 关系数据库：MySQL / PostgreSQL。支持 SQL 查询、索引、事务。适合大规模、长期存储。
• 分布式 KV：HBase / Cassandra。吞吐高、支持水平扩展。适合海量数据、高频查询。
• 文件 + 索引：CSV 文件 + B-tree 索引。离线场景常用，但不宜用于在线服务。

我在某个大型政务项目中遇到过麻烦：他们用 MySQL 存了三亿条映射记录，但每次查令牌对应的原始数据要全表扫描——因为 字段没建索引。嗯，后来加了 UNIQUE INDEX，查询从 3 秒降到 0.1 毫秒。所以映射表的索引设计，从一开始就要规划好。

4.3 反转与不可逆

Tokenization 和“脱敏”经常被画等号，但别忘了：有些场景下业务需要从令牌还原回原始数据。比如银行做交易审核，不能只看令牌，必须看到真实的身份证号。这就引出两个概念：可逆 Tokenization 和 不可逆 Tokenization。

特性	可逆 Tokenization	不可逆 Tokenization
映射表	必须保留	可选保留或直接丢弃
还原能力	持有密钥/映射表就能还原	无论什么条件都无法还原
安全性	依赖映射表保护强度	即使映射表泄露也无法还原（无映射表）
典型应用	跨系统数据交换、联合查询	测试数据、数据共享、对外发布

我个人建议：能用不可逆，就别用可逆。原因很简单——少一个被攻击的点。但现实往往不允许。比如做医保数据分析，保险公司需要看到每个患者的就诊时间线，但患者姓名可以用不可逆令牌，而身份证号则需要可逆令牌，因为出险理赔时必须验证真实身份。

不可逆的实现方式主要有两种：

• 使用密码学安全的哈希函数（SHA-256/BLAKE2b），加上足够长的盐，截断到令牌长度。注意一定要加盐，否则彩虹表分分钟打穿。
• 使用 HMAC 算法，密钥由业务方和脱敏方共同持有。即使映射表丢失，没有密钥也无法伪造令牌。

多说一句“反转”的实际含义。在 Tokenization 语境里，反转（Reverse）通常指通过映射表查回原始数据。这跟加密解密完全不一样：加密解密是数学运算，而 Tokenization 反转是查表操作。正因为如此，Tokenization 天然就比加密更适合做“格式保留”脱敏——你令牌可以保持手机号 11 位数字，而加密后一定是乱码。

4.4 核心流程总览

我把整个 Tokenization 的核心逻辑画成了一张图。你看一遍就能明白数据是怎么流动的。

这张图画了三种关键路径：

• 生成路径：原始数据进令牌生成器，产出令牌，同时写入映射表（可逆场景）。
• 不可逆路径：生成令牌后直接丢弃映射记录，令牌变成“无根之木”，永远无法还原。
• 反转路径：业务需要时，拿着令牌去映射表里查对应的原始值——前提是映射表还在且未被销毁。