optional.ifpresent() 是空安全的触发开关，仅当新值非null且异于旧值时才异步推送；需先比对状态再包装，推送逻辑须异步且健壮，不适用于多条件决策或兜底场景。

用 Optional.ifPresent() 实现“状态变更时异步推送”，关键不在 Optional 本身，而在于把它作为**空安全的触发开关**——只在新值有效（非 null）且与旧值不同时，才发起异步通知。

明确触发条件：有新值、且值已变

Optional 不记录历史，也不感知“变更”。你需要先对比旧状态和新状态，再用 Optional 包装差异结果：

• 比如用户邮箱更新：先判断 oldEmail == null || !oldEmail.equals(newEmail)
• 确认变更后，用 Optional.ofNullable(newEmail) 包装新值
• 调用 ifPresent() 启动异步动作，避免对 null 邮箱发请求

封装异步推送逻辑，避免阻塞主线程

ifPresent() 内部必须调用真正异步的方法，例如：

• 使用 Spring 的 @Async 方法：
  Optional.ofNullable(newEmail).ifPresent(email -> notificationService.sendEmailAsync(email));
• 或手动提交到线程池：
  Optional.ofNullable(newEmail).ifPresent(email -> executor.submit(() -> mailClient.send(email)));
• 注意：不要在 ifPresent() 里写同步 HTTP 调用或数据库操作，否则会拖慢主流程

确保消费逻辑自身健壮，不因副作用失败而中断

异步推送可能失败（网络超时、令牌过期等），但 ifPresent() 不捕获异常。建议：

• 在推送方法内部做 try-catch，记录错误日志，不抛出到 ifPresent 层
• 避免传入可能为 null 的 consumer 对象，例如 logger::warn 前确认 logger 已初始化
• 如需失败重试，应在 sendEmailAsync() 内部实现，而非依赖 Optional

不适用场景提醒

以下情况不适合直接套用 ifPresent()：

• 需要根据旧值+新值共同决策（比如“从 free 升级到 pro 才推送”）→ 应先完成业务判断，再用 Optional 触发
• 推送依赖多个字段（邮箱 + 手机号 + 用户等级）→ 可用 Optional.ofNullable(user).filter(this::isEligibleForNotify).ifPresent(...)
• 需要兜底行为（如新值为空时发短信替代邮件）→ 改用 Java 9+ 的 ifPresentOrElse()