令牌化核心技术：随机令牌、格式保持令牌 (FPE)、密码学令牌
实际做脱敏项目，最常被问的一句话就是：“令牌要怎么生成？”
我刚开始也以为只有一种方式。后来踩了坑才发现——令牌化背后其实是三条完全不同的技术路线。选错了，要么性能崩盘，要么业务没法接。今天把这三种核心算法掰开聊，你以后选型心里就有底了。
1. 随机令牌——最简单的方案
说白了就是生成一个随机字符串，然后跟原始PAN建立一张映射表。我在项目中遇到过很多团队拿UUID直接当令牌，嗯，跑起来确实快。
工作流程： 每次请求都从随机池里取一个不重复的值，存储到 Vault里。
- 优点： 实现极简单、不可预测性高、能抗暴力猜解。
- 缺点： 需要维护映射表；如果表丢了，令牌就彻底失效；查询延迟比本地计算高。
- 典型场景： 支付系统里对外的替代卡号、匿名化数据湖。
避坑：我这里吃过亏——随机池必须做碰撞检测。我曾在高并发下只用简单随机算法，结果一天之内重复率飙升到千分之三。后来加上了位图去重，才彻底解决。
2. 格式保持令牌 (FPE)——让业务系统零修改
你想想看，如果你的下游系统硬性要求PAN必须是16位数字，且最后一位是Luhn校验位。随机令牌一上去，校验失败——系统直接报错。这就是FPE登场的地方。
FPE核心是保留原文的格式特征：长度、字符集、校验位。我建议把它理解成一种“有约束的加密”。用FF1或FF3算法实现，本质是对输入进行带格式的伪随机置换。
// 伪代码：使用FF1保持16位PAN格式
plainPAN = "4111111111111111"
tweak = "20240401"
= fpe_encrypt(plainPAN, tweak)
// 结果仍是16位数字，Luhn校验通过
// example: "3892645712324587"| 对比维度 | 随机令牌 | FPE令牌 |
|---|---|---|
| 格式是否保持 | 否 | 是 |
| 是否可逆（有密钥） | 是（需查表） | 是（直接解密） |
| 映射表依赖 | 强依赖 | 无表（依赖密钥） |
| 性能（1万次/秒） | ~200μs（查表） | ~8μs（纯计算） |
| Luhn校验保留 | 一般不支持 | 原生支持 |
注意：FPE不是万能药。我曾经在一个项目里把FPE用于信用卡CVV格式保持，结果财务系统对CVV做了取模运算，把我们的令牌当真实卡号算错了。选FPE前，一定要确认下游系统到底需要保留哪些格式特征，不是只保留位数就够了。
3. 密码学令牌——可逆且去中心化
第三种方案更“硬核”。它不依赖映射表，而是直接用对称加密（如AES）把PAN变成密文。如何让密文长度和格式可控？配合Base64编码或自定义编码表。
我个人的习惯是：表上化解决不了的去中心化场景，才用密码学令牌。比如分布式多数据中心，你不可能让每个节点都同步一张映射表，那就用密钥算出来。
- 加密算法： AES-256-GCM（提供认证标签，防止篡改）
- 令牌生成： 密文 + 签名，再缩放到业务允许的字符集
- 特点： 无状态、可审计、适合跨系统交换
- 注意事项： 密钥管理是最大的挑战。密钥轮换会导致历史令牌全部失效，需要引入版本号。
经验：我在做银行核心系统替换时，遇到了一个遗留系统只接受12位数字令牌。密码学令牌生成的密文很长，根本放不下。最后我们外层套了一层Base32 + CRC校验截断，才把44字符的AES密文压缩成12位可逆令牌。虽然破坏了部分安全性，但业务能跑起来。——这个取舍在金融项目里很常见。
三种技术的取舍与选择逻辑
光讲原理不够，我把决策树画在了下面的图中。你先看业务需要不需要保留格式？需要的话走FPE。不要求格式但要求彻底去中心化？走密码学令牌。可以接受中心化查询且性能敏感不高？走随机令牌最稳妥。
选型清单——我的个人经验库
根据这几个维度快速判断：
- 下游系统能否接受长度变化？ 不能→先看FPE；能→考虑随机/密码学。
- 是否需要离线验证令牌真实性？ 需要→密码学令牌 (有密钥即可验证)；不需要→随机令牌查表。
- 令牌的生命周期多长？ 长期使用→FPE或密码学 (不怕表丢失)；短期查询→随机令牌更省心。
- 合规审计要求？ 要求全面可审计→密码学令牌+加密日志；只要求脱敏→随机或FPE即可。
最后提醒一句：我见过很多方案把三种算法混用也没问题。比如用FPE对PAN做一级令牌，再用随机令牌对一级令牌做二级调度。选型不用非此即彼，按你实际的业务约束来就好。