个人信息脱敏——静态规则还是动态识别

个人信息脱敏最怕的不是漏，是自以为脱干净了——正则跑一遍满屏绿色，回头发现一个 CSV 附件里的手机号原封不动躺在共享盘上。静态规则和动态识别这两条路线，很多人一上来就争哪个更高级，方向就偏了。先想清楚数据要去哪儿，再谈用什么手段。

静态规则认的是长相，不是意思

静态规则说白了就是一套匹配加替换：正则抓手机号、身份证、邮箱，字段名字典匹配 id_card、password 这类列名，命中就抹掉。它最大的好处是确定性——同一份输入跑十次结果一样，出了问题能倒查是哪条规则、哪次改动。审计问起来，你有记录可翻。代价也直白：它只认长相。手机号少一位、中间加个横杠、被 URL 编码、拆成三列（前三位、中间四位、后四位），规则当场就瞎。误伤同样常见，一串十几位的订单号被判成身份证，打完码客服对不上单，还得回来找你。

动态识别聪明，但说不清的地方最要命

动态识别是让模型从上下文里认实体：谁是人名、哪串是证件号、这条备注里提到的是谁。自由文本多的场景——客服聊天记录、邮件正文、投诉工单——它确实比正则能打，这些东西压根没有固定格式。麻烦在两个地方：一是结果不好解释，模型说这不是敏感信息，你没法像正则那样指着规则条文讲道理；二是模型版本一换、阈值一动，输出就跟着变，留档复现都困难。还有成本，拿识别扫大文件，机器时间是实打实要花钱的。字段很短的场景它也吃亏，单独一列 name，没有上下文，模型判断起来不比字典准。

个人信息脱敏真正的分界线，是数据流向哪里

判断该用哪套，第一步不看技术，看这份数据要去哪儿。留在内网测试库、进日志检索、交给外包做标注、导出给合作方做报表、发到群里给人看——风险等级完全不是一回事。日志这头的诉求是还得能查问题，全打码等于自断手脚，得保留可关联的形态；测试库这头要格式和关联关系都在，不然 bug 复现不了；对外导出那一份，就该做成不可逆的。先把这个分级写下来：可识别原值、部分保留、不可逆替换、哈希化，四个档落到字段清单上，后面选型才有依据。

哪些字段必须死脱，哪些能松一点

直接标识身份的一类——证件号、银行卡号、护照、生物特征、精确到门牌号的住址，走不可逆替换。手机号、邮箱可以局部打码，中间几位盖掉，留头留尾供核对。姓名建议用映射表换成假名，而且要保持一致性，否则同一个名字在不同表里变成不同代号，联查直接断掉。最容易漏的是访问日志里的 URL 参数：token、session、手机号经常直接挂在 query string 上，JSON 里嵌套一层、base64 编一层，规则覆盖不到就漏出去了。还有扫描件和截图，身份证照片、工单截图上的信息，正则和模型都帮不上忙，只能靠流程上禁止上传、或者单独走人工处理。

组合着用，别指望一步到位

老手的做法一般是这样：规则兜底，识别补漏，人工抽检。入口那层按字段字典强制，明知道那列是手机号，就别管内容长什么样，一律按格式处理；自由文本交给识别扫一遍，拿不准的进灰名单人工看；跑完抽一批样本目测，尤其是新接入的数据源。规则库本身得当活文档维护，业务加一个新表单、新导出功能，字段清单就要同步加。全自动谁都想要，真出事那天，你手里得有一份能说清哪些动了、哪些没动的记录。

脱完还得能还原，这件事最容易埋雷

有个场景躲不开：测试环境要复现线上问题，数据必须保持可关联，那就得留映射表。映射表本身比原始数据还敏感，它等于一把能开所有锁的钥匙。存哪儿、谁能读、留多久、到期怎么销毁，这些得写进内部规范并且真执行，别放在同一台机器上、同一个账号就能读。具体口径以各家内部安全规范和法规原文为准，网上抄来的模板当不了依据。

翻车点随手列几条

数据库导出文件是最经典的漏点，.sql 里明文一行不落；debug 日志和异常堆栈顺手把整个请求体打出来；临时 Excel 和中间结果文件散落在共享盘；脱敏脚本自己把原值写进了错误日志；测试库权限松，谁都能连。还有操作层面的——把所谓脱敏后的表直接发群里，附件转手几次，就没人知道它去了哪儿。

收个尾：多数中小团队先把静态规则做扎实，配上字段字典、抽检和变更记录，见效最快；只有自由文本占大头的业务，才值得上识别模型，而且照样要有规则兜底和人工抽检。别一上来就追模型，也别觉得配完正则就万事大吉——数据流向一变，方案就得跟着改。