数据脱敏的常用方法有哪些

做数据相关的活，迟早会碰到「这段信息能不能给出去」。给测试库塞一份用户表、把日志发给外部排查、让外包看一眼订单明细，卡住你的往往不是技术，而是不知道用哪种脱敏手段。这篇把常见方法按「保留什么、丢掉什么」拆开讲，配一张选型对照表和自检顺序，让你下次面对具体字段时能直接做决定。

做数据相关的活，迟早会碰到一个绕不过去的问题：这段信息到底能不能给出去。给测试库塞一份用户表、把日志发给外部排查、让外包看一眼订单明细，真正卡住你的往往不是技术难度，而是不知道这种情况该用哪种脱敏手段。脱敏这词大家都听过，但具体到某个字段、某个场景，掩码、替换、泛化、扰动这些词摆在一起，选哪个、为什么选它、选完怎么验，很少有人一开始就理得清楚。

这篇按「保留什么、丢掉什么」把常见方法拆开讲。核心思路很简单：脱敏不是把数据变没，而是在留用价值和去识别性之间找一个平衡点。你保留的信息越多，数据越有用，但越容易被反推到具体的人；丢得越干净，越安全，但可能什么都分析不了。每个方法都是在回答同一个问题——为了这个用途，最少需要保留到什么程度。先把这个想明白，再往下看具体手法。

先想清楚：脱敏不是删掉就完事

新人最容易犯的错，是把脱敏理解成「把敏感列删了或涂黑」。删掉确实最安全，但很多时候数据就废了——测试库没手机号，登录流程没法跑；统计表没年龄，人群画像没法做。所以第一步不是选方法，而是分清楚你手里有哪些字段、它们各自扮演什么角色。这个分类做错，后面选的方法全是白搭。

强标识字段

单独一列就能直接定位到具体个人的字段，比如证件号、手机号、邮箱、银行卡号；这类字段几乎不能原样外流

准标识字段

单独看定位不到人，但几列拼起来就可能缩小到唯一一个人的字段，比如年龄加性别加邮编、出生日期加地区

非敏感字段

本身不指向个人、也不参与拼装定位的字段，比如订单金额、商品类目；判断标准是它能不能帮着缩小人群范围

分完类你会发现，真正难处理的不是强标识，而是准标识。一列邮编不敏感，一列出生日期不敏感，一列性别不敏感，但三列凑在一起，在小样本里往往就能锁定到少数几个人，甚至唯一一个。这是新人最容易漏的一步，也是为什么「把证件号涂黑」之后数据依然不安全的原因。如果对术语边界不太确定，可以先到 /ai-dict/category/safety 把概念对齐再动手。

掩码：改几位字符，其余原样保留

掩码是最直观的一种做法：把字段中间几位换成星号或固定字符，头尾各留一小段。它的好处是格式一眼能认出来，人工核对时对得上号，又看不到完整内容。你平时在 App 里看到的脱敏手机号、脱敏身份证号，基本都是这一类。

• 适用场景：面向人眼展示、客服查单、工单截图、后台列表页这类「需要能对得上，但不想看全」的场合
• 不适用：需要参与统计、聚合或机器比对的字段，掩码后前缀相同的记录会撞在一起，分组统计直接失真
• 落地要点：固定掩码位置可能间接暴露长度信息，敏感度高的字段要考虑连长度一起隐藏，而不是只盖中间几位
• 常见坑：把掩码当成安全措施用在导出文件上，其实被盖住的位数有限，配合其他字段仍可能被反推

判断掩码用得对不对，有个简单办法：把掩码后的字段当成真实字段，试着跑一遍下游要做的计算。如果结果和用原始数据算出来的差别在你可接受范围内，说明掩码位置选得合适；如果分组数、去重数明显变了，说明这个字段根本不该用掩码，应该换替换或泛化。掩码本质上是给眼睛看的，不是给机器算的。

替换与令牌化：换成另一套假值，靠映射表还原

替换是拿一个格式相同、但不指向真人的值顶上去，比如把真实手机号换成一个格式合法的假号码。令牌化更进一步，给每条记录发一个无意义的编号，编号和真实值的对应关系存在单独的映射表里，业务数据里只留编号。两者共同点是：数据还能保持字段之间的关联，但单看这份数据认不出人。

这类方法主要用在测试环境、跨系统联调、需要保持关联关系的分析场景。比如一家 5 人小团队要给测试库造一批订单数据，希望同一个用户的多笔订单还是能关联起来，又不能是真号码，这时候替换或令牌化就比掩码合适——掩码后的号码没法跨表 join，一 join 就乱。

风险不在方法本身，而在映射表。映射表和业务数据放一起，等于没脱敏，谁拿到业务库谁就能还原。建议映射表单独存放、单独授权、单独审计，只有极少数人有读取权。最小权限的具体做法可以对照 /key-rotation-least-privilege 里的思路，虽然那篇讲的是密钥，但「谁能碰、碰了留痕」的原则是通用的。

泛化：把精度降下来，保留分布

泛化的做法是主动降低字段精度：具体年龄换成年龄段，具体地址换成城市，具体时间戳换成日期。它牺牲的是单条精确性，换来的是整体分布还能用。数据分析、建模、对外发布统计口径，基本都是靠泛化来做的。

代价要提前说清楚。精度一降，原本能回答的问题可能就答不了了。比如你本来想分析「某天某个小时的下单高峰」，泛化到日期级别之后这个问题就不存在了。所以做泛化之前要和需求方确认颗粒度，别等分析跑到一半才发现数据不够细，那时候返工成本更高。

• 适合泛化：年龄、收入区间、地理位置、时间戳这类天然可以分档的字段
• 不适合泛化：需要对账、理赔核验、精确匹配的场景，泛化后根本没法逐条对上
• 颗粒度怎么定：从「你要回答的最细的那个问题」倒推，比它再粗一档通常就够了
• 验证方法：泛化后重新跑一遍分布统计，确认各档位人数没有出现异常集中或塌陷

扰动与合成：加噪声，或干脆造一批假数据

扰动是在数值上加一个可控范围内的偏移，单条数据不再准确，但整体分布和统计特征还能保留。它适合那种「我要看趋势和分布，不关心某一条具体是多少」的场景。合成数据更彻底，直接按真实数据的统计特征造一批全新数据，适合开发初期还没有真实数据、又不想承担风险的时候。

两者都有明确的使用边界，越界就会出事。扰动后的数据不能拿去对账或审计，因为每一条都可能和真实值对不上；合成数据不能反过来当成事实依据，它只是长得像真的，没有任何一条对应真实业务。新人常犯的错是把合成数据混进正式库还不打标记，过几个月谁也不知道哪批是真的，排查起来非常麻烦。

这张表不是让你照着对号入座就完事。真正决定选哪个的，是「谁会看到、要用来干什么」这两个问题。同一份用户表，给客服看和给分析师看，选的方法可能完全不同；给内部分析和发给外部合作方，处理强度也不该一样。

哈希与加密：只能比对，或者必须能还原

哈希和加密常被混着说，但它们解决的问题不一样。哈希是单向的，适合「只要判断两条记录是不是同一个人」的场景，比如去重、匹配、统计独立用户数，不需要还原出原始值。加密是可逆的，意味着你要还原，也就意味着要管密钥，而密钥一旦泄露，脱敏就白做了。

• 选择顺序：能哈希就别加密，能单向就别双向，多一层可逆就多一个泄露口
• 哈希必须加盐，否则常见值（比如连号、短号码）能被字典反查出来，加盐能挡住这一类攻击
• 加密方案里，密钥的存放位置和轮换节奏是重点，密钥和密文放在一起等于没有加密
• 哈希适用于匹配和去重，不适用于需要展示或人工核对的场景，因为哈希值没法给人看

判断该用哪种，问自己一句：以后有没有任何一天需要把这个值变回原样？答案是「不需要」，就用哈希；答案是「需要」，再考虑加密，并且要把密钥管理当成一个独立问题认真对待，而不是顺手写在配置文件里。密钥放置和轮换属于另一类话题，站内有专门的文章，这里不展开。

一张对照表：按字段和用途挑方法

把前面的内容收成一张决策表，方便你下次面对具体字段时直接查。用法是先看「用途」这一列，找到最接近的那一行，再看对应的「优先方法」，最后用「注意点」提醒自己别踩坑。表里的场景是举例，不是穷举，遇到表里没有的，回到最上面那个问题——谁会看到、要用来干什么。

还有一点要提醒：任何方法都不是一键套用，也没有哪种方法能覆盖所有字段。同一张表里不同列可能用不同方法，同一个列在不同导出场景下也可能处理方式不同。把方法当成工具，把「用途」当成选工具的依据，思路就顺了。

动手前的自检顺序与常见坑

最后给一套可以直接照着走的动作顺序。别一上来就打开脚本改数据，先把前两步做完，后面的方法选择会轻松很多。这套顺序的重点在于：方法选择是第三步，不是第一步。

1. 列字段清单并分类把所有字段列出来，逐个标成强标识、准标识还是非敏感。标不准的先归到准标识，宁可当敏感处理。
2. 写清用途和可见范围每个字段用一句话写「谁看、用来干什么」。写不出来用途的字段，默认不导出。
3. 按用途选方法回到对照表挑方法，一个字段可能同时需要两种手段，比如先泛化再哈希。
4. 做联合反推验证拿脱敏后的数据，试着用几列拼起来定位到个人，尤其是小样本表，这一步最容易被跳过。
5. 隔离原始数据并限制访问脱敏只发生在导出那一步的话，意义很有限；原始数据要单独存放、单独授权。

几个高频坑再点一下：一是只处理强标识、放过准标识的组合；二是映射表或密钥和业务数据混放；三是脱敏脚本没有版本管理，改了几轮之后没人知道当前这版是怎么处理的；四是把脱敏当成一劳永逸的事，实际上数据量、字段、用途一变，方案就得重新过一遍。脱敏也不是万能的，它能降低风险，但不能消除全部隐私风险。具体能做到什么程度、还剩哪些风险，可以接着看 /data-masking-privacy-limits 里的讨论，结合自己的业务边界来判断。