Stream API 高性能脱敏清洗关键在于分层处理：先 filter 筛选，再 map 按字段分级脱敏（掩码/哈希/占位），结合空值防护与惰性求值，避免中间集合膨胀。
用 Stream API 对大规模用户变量数据做高性能脱敏清洗，关键不在“写得炫”，而在“选得准、链得稳、控得住”。它不是把所有字段一股脑 map 一遍，而是结合数据敏感性、业务规则和流的惰性特性，分层处理：先筛再转，边流边脱，避免中间集合膨胀。
明确哪些字段需脱敏、按规则分级
脱敏不是一刀切。手机号、身份证号、邮箱、地址、姓名等，脱敏强度不同——有的要掩码（如 138****1234），有的要哈希（如用 SHA-256 + 盐值），有的需替换为固定占位符（如 “[已脱敏]”）。建议提前定义脱敏策略映射表：
- 手机号 → `s -> s.replaceAll("(\d{3})\d{4}(\d{4})", "$1****$2")`
- 身份证号 → `s -> s.substring(0, 6) + "******" + s.substring(14)`（仅限18位）
- 邮箱 → `s -> s.replaceAll("@.*", "@xxx.com")`
- 姓名 → `s -> s.length() > 1 ? s.charAt(0) + "*" : s`
实际中可封装为 `DeidentifyRule` 接口，按字段名动态路由规则，避免硬编码分支。
用 filter + map 链式处理，避免中间集合
传统方式常先 collect 到新 List 再遍历脱敏，内存占用高、GC 压力大。Stream API 的优势在于惰性求值+无状态转换：
- 用 `filter` 快速跳过无需清洗的记录（如测试账号、系统内置用户）
- 用 `map` 对每个 User 对象生成新副本（不可变设计），只对目标字段调用对应脱敏函数
- 全程不调用 `collect(Collectors.toList())`，直到真正需要落地（如写入文件或数据库）才触发终止操作
示例片段：
users.stream().filter(u -> !u.isTestAccount())
.map(u -> new User(
u.id(),
DEID_NAME.apply(u.name()),
DEID_PHONE.apply(u.phone()),
DEID_IDCARD.apply(u.idCard()),
u.createdAt()
))
.forEach(writeToKafka); // 终止操作，直接流式输出
对敏感字段做空值与格式防护
真实数据常含 null、空字符串、格式异常（如 12 位手机号），直接脱敏会 NPE 或逻辑错误。不要依赖外部校验，应在流内就地防御：
- 用 `Optional.ofNullable(u.phone()).map(DEID_PHONE).orElse(null)` 替代裸调用
- 对身份证号加长度与正则预检：`.filter(s -> s != null && s.length() == 18 && s.matches("\d{17}[\dxX]"))`
- 统一兜底：脱敏函数内部默认返回 `"[N/A]"` 而非抛异常，保障整条流水不中断
必要时启用并行流，但需谨慎评估
当用户数据量超百万且单条脱敏耗时稳定（如纯字符串处理），可改用 `parallelStream()` 提升吞吐。但注意：
- 脱敏函数必须是无状态、线程安全的（不能操作共享 Map 或计数器）
- 若脱敏逻辑含 I/O（如查密钥服务）、锁或随机数生成，反而会因竞争拖慢整体速度
- 小数据量（
推荐做法：在批处理入口加开关参数，线上灰度对比 `stream()` 与 `parallelStream()` 的 P95 延迟与 CPU 使用率。
