用函数式接口替代硬编码Callback，核心是将变化点抽象为Function、Consumer等参数；统一错误处理可返回Optional或CompletableFuture；按基础层、业务层、应用层分层封装，避免过度泛化。

用函数式接口替代硬编码的 Callback，核心是把“变化点”抽成参数，让调用方决定行为，而不是在每个地方重复写相似的回调逻辑。

把回调逻辑抽象成 Function 或 Consumer 参数

当多个地方都写类似这样的代码：

• api.fetchUser(id, (user) -> { if (user != null) handleSuccess(user); else handleError(); });
• api.fetchOrder(orderId, (order) -> { if (order != null) showOrder(order); else showEmpty(); });

其实差异只在成功/失败后的处理动作。直接把这两个动作声明为参数即可：

• 用 Function<T, R> 处理有返回值的转换（如转 DTO）
• 用 Consumer<T> 处理纯副作用（如更新 UI、打日志）
• 用 BiConsumer<T, Throwable> 统一处理成功与异常分支

统一错误处理 + 默认空安全策略

团队里大量 Callback 重复做 null 判断或 try-catch，说明责任没分清。重构时可让底层 API 自动兜底：

立即学习“Java免费学习笔记（深入）”；

• 返回 Optional<T> 而非裸对象，强制调用方显式处理空值
• 用 CompletableFuture<T> 替代回调，配合 thenApply/exceptionally 分离成功失败路径
• 封装一个 SafeCallback<T> 接口，内置空值校验和日志埋点，让业务只写核心逻辑

用 Supplier + 方法引用简化高频调用

比如登录后总要执行「刷新用户信息」+「更新本地缓存」+「通知 UI」，别每次都 new 一个匿名类：

• 定义 public interface PostLoginAction { void run(User user); }
• 提供常用实现：PostLoginAction refreshAndNotify = user -> { cache.update(user); ui.notifyLogin(user); };
• 调用时直接传方法引用：auth.login(account, refreshAndNotify);

避免过度泛化，按场景分层封装

不是所有 Callback 都适合塞进一个万能接口。建议分三层：

• 基础层：如 Callback<T> 只含 onSuccess(T) 和 onError(Throwable)
• 业务层：如 UserCallback 继承基础层，增加 onExpired()、onRateLimited() 等领域语义方法
• 应用层：在 Activity/Fragment 中用 lambda 或私有方法实现具体行为，不暴露回调细节给 UI 层