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()
