合规评审、数据导出申请、日志字段设计，最容易吵起来的不是要不要处理，而是「这算脱敏还是匿名化」。口径不一致，评估结论和对外承诺就会打架。这篇不背法条，只给一条判断线：处理后可不可逆、能不能重新识别到具体人、谁能拿到还原能力；再配一张对照表和一套自查顺序，让你在评审会上能当场说清用的是哪一种。
合规评审、数据导出申请、日志字段设计，最容易吵起来的往往不是「要不要处理」，而是「这算脱敏还是匿名化」。两个人嘴里都说自己做了脱敏，实际一个只是把手机号中间四位遮了，另一个把整列换成了随机串并把映射表删了，沟通结果天差地别。这篇不背法条，只给一条判断线：处理后可不可逆、能不能重新识别到具体人、谁能拿到还原能力。
口径不一致，评估结论和对外承诺就会打架。对内部同事说「已经匿名了」，对合作方也这么写，一旦对方拿残留字段组合出个人，麻烦就落在提出结论的人身上。下面先给判断线，再给对照表，最后给一套能在评审会之前跑完的自查顺序。想核对站内已有的模型与接口相关字段说明，可以到 模型资料库（/models） 顺一遍术语口径。
先抓一条判断线：可逆不可逆、能不能对上人
别急着分辨五个词的字面差别，先问三件事：处理完还能不能还原成原文、靠什么还原、还原能力在谁手上。这三个问题回答完，大部分争论当场就能收敛。如果回答不上来，说明处理方案本身还没设计清楚，不是术语问题。
- 处理结果可逆，并且能通过某种映射或密钥对回具体个人：落在加密、假名化、去标识化这一侧。
- 处理结果不可逆，且在设计上无法再对回具体个人：才够得上匿名化。
- 只是把字段挪到另一张表、换个系统存，但原表还在且能关联：这不叫匿名化，叫换了个存放位置。
- 同一份数据在不同环节可能属于不同等级，导出前和导出后要分别判断，别用一句话概括全过程。
一张对照表：五种处理各管什么、不管什么
下表按「保护对象、可逆性、还原能力在谁手里、常见使用场景」四个维度摆放。注意这只是一种便于沟通的归纳口径，具体定性仍要看你们的数据流转文档和适用要求。表中不写任何数值，实际字段规模与示例数据到 指南中心（/guides） 相关内容里对照看。
| 术语 | 主要面向 | 可逆性 | 谁握有还原能力 |
|---|---|---|---|
| 脱敏 | 看数据的人：导出、工单、演示环境，把可见内容遮掉或替换 | 通常不可逆或按需可逆 | 一般无人持有完整还原路径 |
| 加密 | 存储与传输环节，防的是被拿走后的直接读取 | 可逆 | 持有密钥的一方，密钥管理成为关键 |
| 假名化 | 用代号替代身份，业务侧照常处理 | 可逆 | 持有映射表或对照关系的团队 |
| 去标识化 | 剥离或泛化直接身份字段，降低关联可能性 | 多数情况可逆或部分可逆 | 掌握残留字段与辅助数据的一方 |
| 匿名化 | 目标是彻底不可对回个人 | 要求不可逆 | 理想状态下无人持有还原能力 |
从表里能看出一个常被忽略的点：加密和假名化其实都属于「有钥匙就能回去」的阵营，跟脱敏、匿名化不是一回事。把加密后的字段给外部看，如果配套的解密工具或密钥也跟着走，这层保护基本等于没有。判断前不妨先画一条数据流，把每个节点的接收方和权限标出来。
最容易踩的四个误判
下面几种情况在评审会上出现频率很高，多数不是技术做错了，而是命名和说明写错了，导致预期错位。每一条后面配一个「什么情况下不适用」，方便你判断自己是不是例外。
- 把加密当脱敏：报表里字段是密文，但旁边就是解密入口或密钥说明，接收方实际能还原。不适用的情况：接收方确实没有任何密钥与工具，且密文只在受控环境内展示。
- 把假名化当匿名化：用户表还在、映射关系还在，出了问题照样能对回人。不适用的情况：映射表已按流程销毁且无备份，同时残留字段也不足以重识别。
- 只处理一个字段：手机号遮了，订单号加收货地址加时间戳组合起来仍能定位到具体人。不适用的情况：这些准身份字段已经被泛化到无法区分个体的粒度。
- 口径与用途脱钩：同一份数据给内部分析和给外部合作方，强度要求本来不同，却套用同一个说法。不适用的情况：两边的接收范围、留存时长和再传播限制完全一致。
一个字段的处理方式不等于整份数据的保护等级，判断看的是「整份数据能不能对回人」。
评审前的落地自查顺序
这套顺序不追求一次做完，而是让每一步都有可验证的产出。跑完一轮再开会，争论会从「你觉得算不算匿名」变成「第几步的结论要不要更新」，效率完全不同。涉及对外接口字段的强度设置，可结合 速度测试工具（/tools/speed-test） 观察实际请求里带了哪些字段，避免文档和真实流量对不上。
- 列字段清单把这份数据里所有字段过一遍，标出直接身份字段（如姓名、证件号）和准身份字段（如邮编、设备标识、时间戳）各有哪些，产出物是一张带分类的字段表。
- 写清目的与接收方写明处理目的是什么、谁看、看多久、能不能再传出去。接收方含糊的，先按更严的等级处理，等确认后再放宽。
- 确定可逆性等级对每个处理动作问「需要还原能力吗」。需要还原的，对外说明里就不要写匿名，改写去标识化或假名化更稳妥。
- 对齐文档与对外说明把结论写进数据流转文档和对外说明，措辞与实际做法必须一致。发现不一致，以实际做法为准改措辞，别反过来改做法迁就措辞。
- 定期复评新增字段、新增接收方、新增分析用途，都要重走一遍前四步。复评周期按业务变化速度定，变化快就缩短。
五步里最容易漏的是第一步和第五步：字段清单不全会让后面全建在沙子上，不复评则会让一次合格的处理随着业务扩张慢慢失效。判断标准可以简化成一句：任何时刻，只要有人能不费力地对回具体个人，就别对外说匿名化。
下一步把你手上的字段清单拿去和站内的术语口径对一遍，看看还有哪些字段没有归类。→常见问题
加密和脱敏到底哪个更安全？
不能这么比，两者防的不是一回事。加密防的是存储和传输环节被拿走，前提是密钥管得住；脱敏防的是使用和展示环节被看多，前提是原值别和脱敏结果放在一起。实际项目里通常是存的时候加密、用的时候脱敏，各管一段。
把姓名、手机号删掉是不是就算匿名化了？
不一定。判断标准是还能不能对回具体个人，而不是删了几个字段。时间、地点、订单号、设备标识这些准身份字段组合起来仍可能唯一锁定一个人。真正要往匿名化方向做，得同时评估残留字段的重识别空间，拿不准就按去标识化表述。
这套区分对我日常开发有什么实际影响？
影响在对外措辞和数据流转口径上。测试库、日志、埋点数据如果按匿名化承诺出去，后面被发现能还原，性质和整改成本完全不同。开发侧只要记住一条：凡是有映射表、密钥或原始副本能还原的，文档里就别写成匿名化。
