去年十月，我在一个两百人的技术群里贴过一段支付回调日志，只想问一句为什么签名校验总过不了。三分钟后有人私信我："楼上日志里有四个真实手机号、一个身份证号，还有一个内网 IP，你自己看着办。"我立刻撤回，但群里早就有人截了图。那次事故最后走了公司内部流程，用户信息被外部接触的可能性没法完全排除。从那以后我给自己定了一条死规矩：任何要离开自己屏幕的文本，先本地过一遍再粘。
一、泄露几乎都不是被黑，是"顺手一贴"
复盘那条日志，我贴出去的不只是手机号。真正容易被忽略的漏点是这些：
- 请求头里的
Authorization和Cookie，很多排障求助图里连着截进去，等于把会话令牌公开。 - URL 查询串里的
mobile=13800001234，比正文里的手机号更容易被漏看，因为它是"配置的一部分"的样子。 - SQL 片段，尤其是
INSERT INTO user_order (...)的完整语句，字段值一览无余。 - 订单号加上收货地址和称呼——三者拼起来足以定位到具体的人，哪怕每个字段单独看都"不算敏感"。
- 测试账号往往是员工自己的手机号，写进代码仓库或截图里就再也撤不回来。
- 截图里的号码，别人用 OCR 也能扫出来，所以打码要打在图上，不能只处理文字。
二、为什么要保留格式，而不是整条涂黑
全部涂掉看着最安全，但同事没法凭它核对是哪一笔单，最后你还是得打开另一个渠道把原值念给他听——脱敏就白做了。通行的做法是保住"能对上号"的那几位，遮住"能认出人"的那几位。我常用的规则：
| 类型 | 遮掩规则 | 脱敏后 |
|---|---|---|
| 手机号（11 位） | 保留前 3 后 4，遮中间 4 位 | 138****5678 |
| 身份证号（18 位） | 保留前 3 后 4，遮中间 11 位 | 110***********1234 |
| 银行卡号 | 只保留后 4 位 | **** **** **** 1234 |
| 邮箱 | 保留 @ 前首字符和完整域名 | z***@example.com |
| IP 地址 | 保留前两段，后两段遮掉 | 192.168.*.* |
身份证这一条最关键：第 7 到 14 位正好是出生年月日，必须落在被遮的区间里；只遮末位校验码的那种"打码"等于没打。手机号遮中间 4 位有一万种可能，配上姓名和城市并非绝对安全，但比完整号码低一个数量级。
三、我的三步流程，最后一步是反查
- 文本先在隐私信息遮掩里过：粘进去，它按格式把手机号、身份证、银行卡、邮箱、IP 一并遮掉，遮掩字符可以换成
#或自定义符号，整段一次处理完再复制出来。全部在浏览器本地完成，内容不出这台设备，这是我敢拿它处理生产日志的前提。 - 图片是另一件事。聊天记录或后台截图只能打在像素上，我用图片马赛克框选敏感区域，可以反复框多个块，颗粒度调到 40px 以上再往外发；同一区域打两遍比追求一次到位更省心。
- 发出去之前做一次反向核对：把处理结果贴进文本信息提取，选手机号、身份证、邮箱、IP 四类各扫一遍，列表应该是空的。这一步是我那次事故之后加的——人眼看三行长日志很容易漏掉藏在 URL 里的那一个号码。
反查有个天然边界，必须说清楚：这类工具按格式匹配数字串，它不认中文姓名、收货地址、门店名和订单号。所以第三步只能兜住"号码漏遮"，兜不住"语义可识别"，最后那遍还得人脑过。
四、哪些做法看着像脱敏其实不是
- Base64 或 URL 编码：完全可逆，没有密钥，等于在原值外面套了层信封。评审时被点到是最亏的一种。
- 只留前后各一位：看着很安全，但如果同时给出了姓名和生日，位数保留下来就够把候选集缩到很小。
- 遮掉的位数不固定：一行遮 3 位、下一行遮 5 位，读的人反而能靠位数推断原始号码长度和号段。
- 靠手删：删掉手机号却留下
"phone":键名附近的空格和对齐痕迹，同样能猜出大致范围；批量场景一律用工具跑，别用 Delete 键。 - 把脱敏当成一次性的截图动作：真正稳的做法是在日志层就替换，输出前统一遮，而不是等排障的人复制时再补。
合规口径上有一条容易混：《个人信息保护法》把"去标识化"和"匿名化"分开写——去标识化后如果不借助额外信息仍无法识别特定个人，那它还是个人信息；匿名化则要求无法识别且不能复原。前面表格里保留后四位的做法属于前者，所以对外发布和对内展示是两件事，不能因为"我已经打过码"就把脱敏结果直接公开到外部社区。
五、常见疑问
Q：脱敏和加密有什么区别？
加密有密钥、可还原，目的是存储和传输时保护；脱敏通常是不可逆的遮掩，目的是展示时少暴露。两者不冲突，日志该加密存储，截图该脱敏再发。
Q：已经发出去的消息还能补救吗？
撤回只对自己可见，别人已经复制或截图的部分收不回来。能做的是评估暴露面：号码是否还能登录、是否需要通知当事人、涉及支付的是否要换卡，越早启动流程越好。
Q：遮成星号之后还能还原吗？
不能，遮掩是单向的。原始数据要自己留好，脱敏结果只用于分享，不要把它当成可逆的中间格式存进数据库。
Q：脱敏后的数据能直接拿去当测试数据吗？
号码类字段可以，但要注意"可用"和"能对上"是两回事：唯一约束、外键关联会因为批量遮掩而冲突。正式建测试库应该走批处理脱敏脚本，而不是逐段贴。
Q：处理的内容会不会被上传？
我选的都是纯浏览器本地完成的路子，文本和图片都不离开设备。涉及生产数据时这一条比效率更重要，值得作为挑选工具的先决条件。
现在回想那条私信，最幸运的地方是提醒我的恰好是同一个人。脱敏这件事的成本大概就是复制粘贴之后多花二十秒，收益是避免一次要花两周走完的调查流程——这笔账怎么算都划算，前提是你把它变成流程里的固定一步，而不是每次临时想起。