数据脱敏实战：手机号/身份证/银行卡——三行代码搞定，不侵入业务逻辑
引言 上个月安全审计，我们被点名了三个问题： 订单导出接口把用户手机号明文吐给了客服系统，客服离职后导出名单卖给竞品 前端页面直接展示身份证号全串，截图发朋友圈就是一次个人信息泄露 日志里打印了完整的银行卡号，等保测评直接不给过 整改要求：所有出参中的敏感字段必须脱敏。第一反应是写个工具类 DesensitizeUtil.maskPhone(...)，然后在几十个 Controller 里逐个调用——改了三天，漏了两处，还把一个不需要脱敏的字段误伤了（测试同事的订单列表手机号变成 138****5678 无法回显）。 后来换成注解 + Jackson 序列化器方案：在 DTO 字段上标注解 @Sensitive(type = PHONE)，序列化时自动脱敏，业务代码零改动。原来的三天工作量，现在每个字段只需加一行注解，而且脱敏规则集中在枚举里统一维护。 这篇文章把我们踩过的坑和最终方案完整讲一遍： 三种脱敏方案的对比（Jackson 序列化器 / MyBatis TypeHandler / AOP），各自的适用边界 @Sensitive 注解 + 自定义 Jackson 序列化器....
