thenApply 与 thenAccept 不切换线程，执行线程取决于上游完成状态：上游已完成则在当前线程执行，未完成则由上游线程触发；需用 thenApplyAsync/thenAcceptAsync 并传 Executor 才能真正控制线程。
thenApply 与 thenAccept 默认不切换线程，容易误以为“异步”
很多人看到 thenApply 和 thenAccept 就默认它们会新开线程执行回调，其实不然。这两个方法**本身不带 Async 后缀**，意味着它们的执行线程取决于上游任务是否已完成：
- 如果上游
CompletableFuture已完成（比如用completedFuture构造，或上游已快速返回），那么回调就在**当前调用线程**执行； - 如果上游还在运行中，回调会被注册为监听器，等上游完成时——由**上游任务所在线程**触发执行（例如
supplyAsync用的是ForkJoinPool.commonPool()，那回调也大概率在那个线程里跑）。
这不是“异步回调”，只是“延迟回调”：没有显式调度，没有线程池参与，上下文完全被动继承。想强制换线程？得用 thenApplyAsync 或 thenAcceptAsync，并传入你自己的 Executor。
thenApplyAsync 与 thenAcceptAsync 才真正控制线程归属
thenApplyAsync 和 thenAcceptAsync 的关键差异不在功能，而在**线程调度权是否移交**。它们默认使用 ForkJoinPool.commonPool()，但你可以传入任意 Executor 来指定执行者：
- 传
Executors.newFixedThreadPool(5)→ 回调固定在这 5 个线程里跑； - 传
new ThreadPoolExecutor(...)配合自定义拒绝策略 → 可控性更强； - 不传任何参数 → 依赖
commonPool()，而它可能被其他模块（如并行流）抢占，导致回调延迟或饥饿。
注意：thenApplyAsync 返回 CompletableFuture<u></u>，thenAcceptAsync 返回 CompletableFuture<void></void>，类型签名没变，但执行线程已脱离上游控制。
混用同步/异步回调时，线程上下文会断裂
常见错误是链式调用中一半用 thenApply，一半用 thenApplyAsync，结果发现 ThreadLocal 值丢失、事务上下文未传播、MDC 日志标签断掉——因为每个 Async 调用都可能跳到新线程：
-
thenApply→ 复用上游线程 →ThreadLocal通常还在； -
thenApplyAsync→ 换线程 → 原线程的ThreadLocal不自动传递； - 若上游是 Web 容器线程（如 Tomcat 的
http-nio-8080-exec-3），而回调进了commonPool，那 Spring 的RequestContextHolder就失效了。
修复方式不是禁用 Async，而是显式桥接上下文。例如用 CopyOnInheritableThreadLocal，或在 thenApplyAsync 前手动把关键 ThreadLocal 值封进闭包里传进去。
不要靠方法名判断执行时机，要看是否带 Async 后缀 + 是否传 Executor
最常被忽略的一点：方法签名里的 “Async” 是唯一可靠线索。哪怕你写的是 thenApplyAsync(() -> {...})，如果传入的 Executor 是单线程且队列满，它依然会阻塞等待——“Async” 只表示“尝试异步”，不保证“立即并发”。反过来，thenApply 看似“同步”，但在上游未完成时，它根本不会执行，谈不上同步还是异步。
真正影响线程行为的只有两个变量：是否带 Async 后缀、是否显式传 Executor。其余全是表象。调试时别盯着日志时间戳猜线程，直接打 Thread.currentThread().getName() 才算数。
