UnaryOperator是Java 8中用于同类型一元转换的函数式接口，强调纯函数性：输入输出类型相同、不修改原对象、无外部依赖；恒等转换用identity()最稳妥，逻辑加工需确保可预测与无副作用，配合replaceAll时须注意集合可变性与null安全。
UnaryOperator 是 Java 8 引入的核心函数式接口之一，专用于“输入输出类型相同”的一元转换场景。它不是万能工具，但对同类型变量做恒等转换或轻量逻辑加工时，简洁、安全、可读性强。关键在于理解它的契约：必须返回同类型新值，不修改原对象，也不依赖外部状态。
什么是恒等转换？怎么写最稳妥
恒等转换指“输入什么，就原样返回什么”，看似无用，实则常用于占位、默认行为兜底或链式调用中保持类型流畅通。
- 直接用方法引用 UnaryOperator.identity() —— 这是 JDK 提供的静态工厂方法，语义清晰且零开销
- 避免手写
s -> s或x -> x，虽语法合法，但可读性弱于identity() - 恒等转换不可用于修改原对象字段（如
s -> {s.setName("x"); return s;}），这违反纯函数原则，易引发并发或复用问题
同类型逻辑加工的典型写法
只要输入输出都是同一类型（比如 String→String、Integer→Integer），就可以用 UnaryOperator 封装转换逻辑。重点是让操作可预测、无副作用。
- 字符串清洗：
UnaryOperatortrimAndUpper = s -> s == null ? "" : s.trim().toUpperCase() - 数字归一化：
UnaryOperatortoPositive = i -> Math.abs(i) - 对象字段更新（安全方式）：
UnaryOperator—— 创建新对象，不改原实例withDefaultAge = u -> new User(u.getName(), u.getAge() == null ? 18 : u.getAge()) - 慎用原地修改：若 User 是可变对象，
u -> {u.setAge(18); return u;}虽能编译，但会破坏不可变性假设，下游难以维护
和 List.replaceAll 配合使用的关键细节
replaceAll 是 UnaryOperator 最自然的落地场景之一，但它只支持可变列表（如 ArrayList），且要求操作是纯函数。
- 正确示例：
list.replaceAll(s -> s.trim().replace(" ", "_"))—— 每个字符串被就地替换为加工后的新字符串 - 错误示例：
list.replaceAll(s -> { s += "!"; return s; })看似没问题，但如果 list 是不可变集合（如 List.of(...)），会抛 UnsupportedOperationException - 注意 null 安全：如果列表含 null，而你的 UnaryOperator 没判空（如直接调用
.length()），运行时仍会 NPE —— 这不是接口限制，是你逻辑的责任
什么时候不该用 UnaryOperator
它不是万能替代品。以下情况建议换其他接口或普通方法：
- 需要返回不同类型（如 String → Integer）→ 改用 Function
- 只消费不产出（如打印日志、发通知）→ 改用 Consumer
- 需根据条件决定是否转换（带分支副作用）→ 不适合函数式风格，应拆为 if-else + 明确方法
- 转换逻辑复杂、多步骤、需异常处理 → 封装成独立方法更利于测试和复用，再传方法引用（如
MyUtils::normalizeName）
