thenApply用于转换结果并返回新CompletableFuture，thenAccept用于消费结果且不返回值；二者均遵循异常传递规则，应避免阻塞、明确线程上下文并合理兜底。
在 Java 的 CompletableFuture 中，thenApply 和 thenAccept 是两个常用且语义清晰的异步结果处理方法：前者用于**转换结果并返回新 CompletableFuture**，后者用于**消费结果但不返回新值**。选对方法，能避免阻塞、提升链式可读性，也减少不必要的空值或异常风险。
thenApply：做“加工”，产出新结果
thenApply 接收一个 Function<t u></t>，对上游完成的结果进行转换，并返回一个新的 CompletableFuture<u></u>。它适合需要将原始结果映射为另一种类型或格式的场景，比如解析 JSON、格式化字符串、计算衍生值等。
- 上游失败（exceptionally completed），则新 future 也会以相同异常完成，不会执行函数
- 函数内部抛出异常，该异常会作为新 future 的完成异常（包装为
CompletionException） - 返回值为
null是允许的（除非下游逻辑明确不允许），新 future 会以null完成
示例：
CompletableFutureCompletableFuture
return new User(id, "Alice"); // 返回新对象，类型已变
});
thenAccept：做“消费”，不改变结果流
thenAccept 接收一个 Consumer<t></t>，只对上游结果执行副作用操作（如打日志、发通知、存缓存），不产生新结果，返回的是 CompletableFuture<void></void>。它适合“做完就结束”的轻量级后续动作，且不希望打断原有结果链。
- 不能用于构造新 future 链（因为返回
Void），若需继续链式调用，应改用thenApply或thenCompose - 同样遵循异常传递规则：上游失败或 consumer 抛异常，都会导致当前 future 异常完成
- 常见误用：在
thenAccept里试图 return 值或想把它接在另一个thenApply前——这会导致编译错误或逻辑断裂
示例：
userFuture.thenAccept(user -> {System.out.println("User loaded: " + user.getName());
cache.put(user.getId(), user); // 纯副作用，无返回
});
组合使用：先转换再消费，或按需分支
两者可自然嵌套或并行使用。例如：先用 thenApply 将 ID 转为用户对象，再用 thenAccept 记录审计日志；也可对同一 future 同时注册多个 thenAccept（各自独立执行）。
- 避免在
thenApply里写副作用逻辑（如发消息），否则会污染转换语义，也影响复用性 - 若消费后还需基于结果发起新异步任务（如调用远程服务），应使用
thenCompose，而非thenAccept+ 手动创建 future - 调试时可插入
thenAccept(System.out::println)快速观察中间结果，不影响类型流
注意线程上下文与异常处理
默认情况下，thenApply 和 thenAccept 在上游 future 完成的**同一线程**中执行（即 non-async 版本）。若需指定线程池，应使用带 Executor 参数的重载方法（如 thenApplyAsync(fn, executor)）。
- 未显式指定 executor 时，不要假设它一定在 ForkJoinPool.commonPool() 中运行——尤其当上游是
supplyAsync且用了自定义池时 - 建议始终用
exceptionally()或handle()显式兜底，而不是依赖 try-catch 包裹 lambda（lambda 内异常会被吞掉并转为 CompletionException） - 慎用
get()阻塞等待，它破坏了异步初衷；优先用链式回调表达业务逻辑
