Java数据脱敏核心是在应用层按字段类型分级处理敏感信息，如手机号（1381234）、身份证号（11010112）、银行卡号（6228481234）等，通过工具类、注解+AOP、DTO构建或日志专用方案实现，需确保仅作用于展示层且规则统一。
Java中做数据脱敏，核心是在不破坏数据可用性的前提下，隐藏或替换敏感字段的原始值。常见场景如手机号、身份证号、银行卡号、邮箱、姓名等，在日志打印、接口返回、数据库备份、测试数据生成等环节需主动处理，而非依赖数据库或中间件层——因为Java应用层最清楚“哪些是敏感字段”以及“该用什么规则脱敏”。
常用脱敏规则与对应实现逻辑
脱敏不是简单地全量星号替换，要按字段类型和业务要求分级处理：
- 手机号：保留前3位和后4位，中间4位替换为****（如 138****1234）；若需兼容带区号或分隔符的格式（如+86-138-1234-5678），先正则提取纯数字再处理
- 身份证号：18位时保留前6位（地址码）和后2位（校验码），中间10位脱敏（如 110101**********12）；注意区分15位旧号，可统一转18位后再脱敏，或按规则保留前6后3
- 银行卡号：通常保留前6位（BIN号）和后4位，中间用****填充（如 622848****1234）；长度不固定时，优先保证前后可见位数符合PCI-DSS建议（至少首6+末4）
- 邮箱：保留用户名首尾各1字符，@后域名完整保留（如 w***g@xxx.com）；若需更强保护，可将用户名全脱敏为***@xxx.com
- 姓名：双字名脱敏为“*某”，三字及以上为“*某某”（如 张**、王***）；也可统一为单个星号“*”，避免拼音推断；注意处理少数民族姓名、英文名等边界情况
代码层面的主流处理方式
Java中脱敏实现有轻量级和框架级两类路径，按项目成熟度选择：
-
工具类静态方法：封装
DesensitizeUtils，提供desensitizePhone(String)、desensitizeIdCard(String)等方法，调用方显式调用。适合老系统改造或规则简单场景 -
注解 + 反射拦截：自定义
@Desensitize(type = DesensitizeType.PHONE)注解，配合AOP或序列化扩展（如Jackson的JsonSerializer）在JSON输出前自动处理。Spring Boot项目常用此法，侵入性低 - DTO对象构建时脱敏：在Controller返回VO/DTO前，用MapStruct或BeanUtils.copyProperties后，对敏感字段单独赋值脱敏结果。逻辑清晰，调试方便
-
日志脱敏专用方案：使用Logback的
MaskingPatternLayout或自定义Converter，针对MDC、参数占位符（如{}, {}）做正则匹配脱敏，避免敏感信息落盘
关键注意事项与避坑点
脱敏看似简单，实际易出问题：
立即学习“Java免费学习笔记（深入）”；
- 脱敏不能影响业务逻辑判断——比如把手机号脱敏后用于短信校验，必须确保原始值仍可获取（即脱敏仅发生在展示层，非存储或计算层）
- 避免在实体类getter中直接脱敏（如
getPhone() { return DesensitizeUtils.phone(this.phone); }），会导致DAO层、条件查询、缓存key等误用脱敏值 - 注意空值、null、空白字符串、超长/非法格式（如19位“身份证号”）的防御性处理，防止NPE或脱敏异常中断流程
- 测试环境应配置独立脱敏开关（如
desensitize.enabled=true），生产强制开启，开发/测试可关闭便于排查
基本上就这些。脱敏本身不复杂，但容易忽略上下文和一致性——同一字段在日志、API、导出Excel中脱敏方式必须统一，最好沉淀成团队规范文档+基础工具包，而不是每个模块各自实现一套规则。
