作为一个写过多年业务代码的Java开发者，我越来越觉得异步编程不是“会不会用某个API”的问题，而是“你有没有一套顺手的东西能把并发编排做得干净利落”。之前用Future做并行调用时，get()一堵就是半天，想串行传递结果还得手动写回调，异常处理更是让人头大。直到我把CompletableFuture真正用进生产项目，才体会到什么叫“异步编排神器”。这篇内容我会从核心原理讲到实战编排，再结合一个真实的接口聚合改造案例，把线程池选型、超时兜底、异常吞掉这些坑一次说清楚。如果你正在用Java做后端开发，或者准备面试时被问到异步编程，这篇文章都能给你一些不一样的思路。
1. 从Future到CompletableFuture：异步编程的痛点到底在哪
1.1 Future的三宗罪：阻塞、难组合、异常难缠
很多Java开发者接触并发的第一课就是Future。ExecutorService.submit()返回一个Future，然后你拿着这个Future在合适的地方调用get()取结果。这个设计在JDK 1.5时代算是不错的选择，但你真正在业务代码里用几次就会发现它的问题。
第一宗罪是阻塞。future.get()会一直阻塞当前线程直到任务完成，如果你有多个并行任务，想等它们全部完成再聚合，就得按顺序一个一个get。注意，这不是并行等待，而是串行等待——第一个任务没完成，后面的结果你根本拿不到。有人会说我可以把get放在最后面统一调，问题是如果任务B先完成、任务A后完成，你的代码也只能在那里干等A，白瞎了B已经完成的事实。
第二宗罪是难以组合。业务里的异步场景很少是“发一个任务然后傻等”，更多是这样的链路：先查用户信息，再用用户ID查订单列表，再根据订单列表查物流信息，中间可能还要并发地去查商品详情。用Future实现这种依赖编排，你要么在回调里嵌回调，要么手动维护一个状态机，代码很快就会变成一团乱麻。
第三宗罪是异常处理费劲。Future的异常会被封装在ExecutionException里，你得在get的时候try-catch，而且如果你忘记调用get，任务内部抛出的异常会被静默吞掉——这在生产环境里非常可怕，你根本不知道异步任务失败了。
1.2 CompletableFuture带来的核心转变：从“拉取结果”到“发布回调”
CompletableFuture最大的思想转变在于，它不再要求你主动去get结果，而是让你注册回调，等任务完成之后自动触发后续动作。这就是“拉模式”到“推模式”的转变。
打个比方，Future像你去餐厅点餐，点完之后你得一直盯着出餐口问“好了没”；CompletableFuture则像你留下了手机号，餐好了服务员会主动打电话通知你。这个转变让异步代码从“阻塞等待”变成了“事件驱动”，后续的处理逻辑可以像流水线一样串联起来。
从类结构上看，CompletableFuture实现了两个接口：Future和CompletionStage。Future是传统异步结果的入口，CompletionStage则定义了任务编排的大量方法——串行的thenApply、并发的thenCombine、汇聚的allOf、容错的exceptionally等等。理解了这个双重身份，你就能明白它为什么既能当Future用，又能做复杂的异步流水线。
2. 核心原理拆解：CompletableFuture的方法体系与内部机制
2.1 supplyAsync和runAsync：异步任务的两种开启方式
一切编排的前提是先有异步任务。CompletableFuture提供了两个静态方法用来开启异步任务：supplyAsync和runAsync。
supplyAsync(Supplier<U> supplier)：任务有返回值，适合需要拿到结果继续处理的场景。runAsync(Runnable runnable)：任务没有返回值，适合纯执行动作，比如写日志、发送通知。
这两个方法都有重载版本，可以传入自定义的Executor。我建议凡是生产环境代码，一律用自定义线程池版本，原因后面会专门讲。
// 有返回值 CompletableFuture<UserInfo> userFuture = CompletableFuture.supplyAsync(() -> { return userService.getUser(userId); }, userThreadPool); // 无返回值 CompletableFuture<Void> logFuture = CompletableFuture.runAsync(() -> { logService.recordOperation(userId, "login"); }, logThreadPool);2.2 串行传递的thenApply、thenAccept、thenRun到底怎么选
任务开启之后，最常用的就是串行编排。CompletableFuture设计了一组“then”系列方法，它们之间最大的区别在于：回调入参是什么、回调返回值是什么、需不需要新开线程。
thenApply(Function<T, R>)：接收上一个任务的结果，返回一个新的结果，适合做数据转换。thenAccept(Consumer<T>)：接收上一个任务的结果，但没有返回值，适合做消费型动作。thenRun(Runnable)：既不关心上一个任务的结果，也没有返回值，纯粹是“做完上一件就做下一件”。
我再补充一个容易混淆的点：thenApply和thenCompose的区别。thenApply做的是普通转换，返回的是CompletableFuture<R>里的R，而thenCompose接收的是一个返回CompletableFuture<R>的函数，用于把两个异步任务扁平化串联。你可以这样理解：如果下一个处理逻辑本身也是异步任务，就应该用thenCompose，否则用thenApply。
// thenApply：同步转换 CompletableFuture<String> upperFuture = CompletableFuture .supplyAsync(() -> "hello") .thenApply(s -> s.toUpperCase()); // thenCompose：连接一个异步任务 CompletableFuture<OrderInfo> orderFuture = CompletableFuture .supplyAsync(() -> userService.getUser(userId)) .thenCompose(user -> orderService.getLatestOrder(user.getId()));2.3 thenCombine和thenCompose：两个异步结果怎么合并
真实业务里经常遇到“同时拿两个结果，拼成一个对象返回”的场景。thenCombine就是干这个的，它等两个任务都完成后，把两个结果作为参数传给BiFunction，合并成一个新结果。
CompletableFuture<PriceInfo> priceFuture = CompletableFuture .supplyAsync(() -> priceService.getPrice(skuId), pool); CompletableFuture<StockInfo> stockFuture = CompletableFuture .supplyAsync(() -> stockService.getStock(skuId), pool); CompletableFuture<ProductDetail> detailFuture = priceFuture .thenCombine(stockFuture, (price, stock) -> { ProductDetail detail = new ProductDetail(); detail.setPrice(price); detail.setStock(stock); return detail; });注意thenCombine和thenCompose虽然长得像，但用途完全不同。thenCombine是“两个独立任务的结果合并”，thenCompose是“一个有依赖关系的任务的串联”。一个是横向合并，一个是纵向串联，这两个词在我面试别人的时候经常拿来考察候选人是否真的理解了CompletableFuture的API设计。
2.4 allOf和anyOf：多个任务汇聚的两种语义
当你需要同时发起多个请求，并且要等全部完成时，用allOf。它的返回值是CompletableFuture<Void>，本身不携带结果，但你可以通过join每个任务来获取各自的结果。
List<CompletableFuture<RemoteData>> futures = urls.stream() .map(url -> CompletableFuture.supplyAsync(() -> httpClient.get(url), pool)) .collect(Collectors.toList()); CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join(); List<RemoteData> results = futures.stream() .map(CompletableFuture::join) .collect(Collectors.toList());anyOf则是“谁先完成用谁”，返回的是CompletableFuture<Object>，那个Object就是最先完成的任务的结果。这种语义适合“多个数据源同时查询，取最快的那个返回”的场景，比如容灾场景下同时查主库和备库，谁先返回就用谁的。
2.5 exceptionally、handle和whenComplete：异常处理三件套
CompletableFuture的异常处理是它的亮点之一，但也最容易用错。
exceptionally(Function<Throwable, T>)：只在任务异常时触发，需要返回一个降级结果。handle(BiFunction<T, Throwable, R>)：无论成功还是失败都会触发，通过判断Throwable是否为null来决定走正常逻辑还是降级逻辑。whenComplete(BiConsumer<T, Throwable>)：无论成功还是失败都会触发，但不改变结果值，适合做清理或日志记录。
我最常用的组合是exceptionally做降级兜底，whenComplete做链路日志。有一点需要特别提醒：handle返回的新CompletableFuture会吞掉原异常，如果你在handle里再次抛出异常，异常才会被传播到下游。这个细节在排查线上问题时经常是突破口。
3. 实战编排：六种业务场景的编排模式与代码范式
3.1 场景一：串行依赖（先查用户，再查订单）
这是最常见的链式调用。用thenApply或thenCompose把两个接口串起来，避免一层层嵌套回调。
CompletableFuture<OrderVO> resultFuture = CompletableFuture .supplyAsync(() -> userService.getUser(userId), pool) .thenApplyAsync(user -> orderService.getOrderByUserId(user.getId()), pool) .thenApplyAsync(order -> convertToVO(order), pool);这里有个细节值得注意：我用的是thenApplyAsync而不是thenApply。两者的区别在于，thenApply会沿用上一个任务的执行线程，而thenApplyAsync会把下一个回调提交到指定的线程池。在IO密集型场景中，我倾向于用thenApplyAsync，因为这样能让回调任务也能被线程池统一调度，避免某个工作线程被长任务占死。
3.2 场景二：并行无依赖（同时查商品基础信息、价格、库存）
这是CompletableFuture最“爽”的场景。三个接口互相独立，并发发出，最后聚合。
CompletableFuture<BaseInfo> baseFuture = CompletableFuture .supplyAsync(() -> goodsService.getBaseInfo(goodsId), pool); CompletableFuture<PriceInfo> priceFuture = CompletableFuture .supplyAsync(() -> priceService.getPrice(goodsId), pool); CompletableFuture<StockInfo> stockFuture = CompletableFuture .supplyAsync(() -> stockService.getStock(goodsId), pool); CompletableFuture<GoodsDetailVO> resultFuture = baseFuture .thenCombine(priceFuture, (base, price) -> { GoodsDetailVO vo = new GoodsDetailVO(); vo.setBaseInfo(base); vo.setPrice(price); return vo; }) .thenCombine(stockFuture, (vo, stock) -> { vo.setStock(stock); return vo; });3.3 场景三：批量并发任务（循环处理列表）
批量请求第三方接口时，循环里直接调用同步接口会变成串行，正确做法是循环里创建CompletableFuture，最后统一聚合。
List<CompletableFuture<BatchResult>> futures = idList.stream() .map(id -> CompletableFuture.supplyAsync( () -> remoteClient.batchQuery(id), pool)) .collect(Collectors.toList()); CompletableFuture<List<BatchResult>> allFuture = CompletableFuture .allOf(futures.toArray(new CompletableFuture[0])) .thenApply(v -> futures.stream() .map(CompletableFuture::join) .collect(Collectors.toList())); List<BatchResult> results = allFuture.get(5, TimeUnit.SECONDS);这里我建议用get(5, TimeUnit.SECONDS)而不是join()。join虽然简洁，但一旦超时或异常，它只抛出CompletionException，对调用方不够友好；get可以指定超时时间并抛出TimeoutException，方便你做全局超时兜底。
3.4 场景四：谁能最快就返回谁（接口容灾）
我曾经做过一个物流轨迹查询，对接了多家物流服务商，某家挂了就换另一家。用anyOf可以让最快的服务商先返回，避免因为单点超时导致整个查询失败。
List<CompletableFuture<TrackVO>> futures = providers.stream() .map(provider -> CompletableFuture.supplyAsync( () -> provider.queryTrack(trackingNo), pool)) .collect(Collectors.toList()); CompletableFuture<Object> firstFuture = CompletableFuture.anyOf( futures.toArray(new CompletableFuture[0])); TrackVO track = (TrackVO) firstFuture.get(3, TimeUnit.SECONDS);当然这种模式要配合降级策略，比如最快的返回数据格式不完整时，还是要等待其他来源补齐。anyOf更像是一种“快速发现可用源”的机制。
3.5 场景五：超时控制与降级回退
生产环境最怕的不是慢，而是“没有期限地慢”。CompletableFuture本身没有内置超时机制（JDK 9以后有orTimeout和completeOnTimeout，但很多项目还在JDK 8），所以常规做法是外层用get(timeout, TimeUnit)包裹。
public RemoteData queryWithTimeout() { CompletableFuture<RemoteData> future = CompletableFuture .supplyAsync(() -> remoteClient.query(), pool) .exceptionally(ex -> { log.error("remote query failed", ex); return RemoteData.fallback(); }); try { return future.get(2, TimeUnit.SECONDS); } catch (TimeoutException e) { // 注意：这里要主动取消任务，否则它还在后台跑 future.cancel(true); return RemoteData.fallback(); } catch (Exception e) { return RemoteData.fallback(); } }这个案例里有几个值得记录的要点。第一，exceptionally已经处理了任务内部异常，get这边捕获的是超时和中断异常。第二，超时后调用cancel(true)不是可有可无的——如果不取消，那个慢任务会在后台线程池里继续执行，占着线程不释放，长期积累一样会把线程池拖垮。
3.6 场景六：依赖多个异步结果的复杂编排
稍微复杂的聚合逻辑，比如一个交易详情页要展示用户信息、账户余额、近期交易流水、风控状态，它们之间有依赖也有独立的部分。我的习惯是先把独立任务并发出去，再用thenCombine或allOf把结果一层层拼起来，最后构造出想要的VO。这样代码逻辑清晰，每一步都是一个函数，可读性和可维护性都很好。
4. 线程池选型：为什么默认的ForkJoinPool是个隐藏雷区
4.1 默认线程池的致命短板
CompletableFuture不传线程池时，默认使用ForkJoinPool.commonPool()。这个公共线程池看起来人畜无害，实际上坑很多：
- 线程数默认是
CPU核心数 - 1，对于IO密集型的业务接口来说严重不够。 - 它是JVM级的公共池，所有使用默认线程池的代码共享，一个任务阻塞就可能导致其他无关业务也跟着受影响。
- 控制台看不到任务排队情况，出了问题很难排查。
举个例子，一个接口里并发调用3个远程HTTP接口，如果每个接口耗时500ms，用默认线程池时假设核心数8，线程数7，那同时最多只能支撑7个请求的并发异步任务，多出来的请求全部排队。一旦上游服务变慢，线程全部阻塞，整个应用的公共线程池就废了。
4.2 自定义线程池的配置策略
生产环境我从来不用默认池。自定义线程池的参数怎么配，取决于你的任务是CPU密集型还是IO密集型。对于大部分后端业务接口的异步调用，都是IO密集型，CPU在等待网络返回时是空闲的，所以线程数可以配得比CPU核心数大很多。
一个参考公式：线程数 = CPU核心数 × (1 + 平均等待时间 / 平均计算时间)。假设一次远程调用等待时间800ms，本地计算50ms，那么每个核心大约能跑17个线程，8核机器就是136个线程。当然这是理论值，实际还要结合压测数据。
private final ThreadPoolExecutor asyncPool = new ThreadPoolExecutor( 8, // 核心线程数 32, // 最大线程数 60, TimeUnit.SECONDS, // 非核心线程空闲存活时间 new LinkedBlockingQueue<>(1000), // 队列容量 new ThreadFactoryBuilder() .setNameFormat("async-pool-%d") .build(), new ThreadPoolExecutor.CallerRunsPolicy() );线程工厂我推荐用Guava的ThreadFactoryBuilder或者其他能设置线程名的工厂类。线程名太重要了，线上排查问题打线程快照时，一堆pool-3-thread-1根本看不出是谁的，但是async-pool-8一眼就能定位到具体业务。
4.3 拒绝策略选择与队列大小权衡
CallerRunsPolicy是异步任务场景里一个很“反直觉”但好用的策略：当线程池满了，新任务不丢弃，而是在提交任务的那个线程里直接执行。这样相当于最坏情况下退化成同步调用，但保证了任务不丢失。相比AbortPolicy直接抛异常，CallerRunsPolicy对用户体验更友好。队列大小设为1000意味着在极端流量下，任务先排队而不是直接把请求打爆，为上游限流和降级争取时间。
4.4 线程池里的上下文传递问题
异步任务跨线程执行时，ThreadLocal数据会丢失。比如你用自己的线程池执行异步任务，任务里拿不到主线程设置的登录用户上下文、TraceId，日志就串不起来。我的解法是，在提交任务之前把需要的上下文参数通过构造函数或局部变量传入，不依赖ThreadLocal隐式传递。对于中间件的TraceId，可以用TransmittableThreadLocal这类工具做显式传递，但这又是一个大话题了，这里只说结论：不要奢望线程池自动帮你传递上下文。
5. 真实案例复盘：商品详情聚合接口的耗时优化
5.1 改造前的串行链路与痛点
两年前我维护过一个商品详情页接口，一次请求要聚合五类数据：商品基础信息、价格、库存、优惠活动、商家信息。最初的实现是同步串行调用，每个依赖耗时大约：基础信息60ms，价格300ms，库存250ms，活动350ms，商家信息80ms。我们换算一下，总共是1040ms左右。这还只是稳定状态，如果库存服务或者活动服务抖动，整个接口的耗时轻松超过2秒，用户体验非常差。
这种“一个服务抖动拖垮整个接口”的情况，在串行调用里最要命。五个服务串在一起，整体可用性等于五个服务可用性的乘积。任何一个服务的故障都会被无限放大。所以我当时的优化方向很明确：把五条独立的调用链改成并发执行，整体耗时逼近最慢的那个服务。
5.2 改造后的并行编排代码
五条链路之间没有依赖关系，只有最后聚合那一步需要汇总所有数据。所以改造后的代码结构是五个任务并发发出，等全部完成后组装：
public GoodsDetailVO getGoodsDetail(Long goodsId) { CompletableFuture<BaseInfo> baseFuture = CompletableFuture .supplyAsync(() -> baseClient.getBaseInfo(goodsId), asyncPool) .exceptionally(ex -> { log.error("base info failed", ex); return null; }); CompletableFuture<PriceInfo> priceFuture = CompletableFuture .supplyAsync(() -> priceClient.getPrice(goodsId), asyncPool) .exceptionally(ex -> { log.error("price failed", ex); return null; }); CompletableFuture<StockInfo> stockFuture = CompletableFuture .supplyAsync(() -> stockClient.getStock(goodsId), asyncPool) .exceptionally(ex -> { log.error("stock failed", ex); return null; }); CompletableFuture<ActivityInfo> activityFuture = CompletableFuture .supplyAsync(() -> activityClient.getActivity(goodsId), asyncPool) .exceptionally(ex -> { log.error("activity failed", ex); return null; }); CompletableFuture<ShopInfo> shopFuture = CompletableFuture .supplyAsync(() -> shopClient.getShopInfo(goodsId), asyncPool) .exceptionally(ex -> { log.error("shop failed", ex); return null; }); return CompletableFuture.allOf(baseFuture, priceFuture, stockFuture, activityFuture, shopFuture) .thenApply(v -> { GoodsDetailVO vo = new GoodsDetailVO(); vo.setBaseInfo(baseFuture.join()); vo.setPrice(priceFuture.join()); vo.setStock(stockFuture.join()); vo.setActivity(activityFuture.join()); vo.setShopInfo(shopFuture.join()); return vo; }) .get(1200, TimeUnit.MILLISECONDS); // 整体超时兜底 }5.3 优化后的耗时数据与资源消耗
改造后用同样的压测轮次对比，优化前P99耗时约1.5秒，优化后P99下降到480ms左右，主要逼近最慢的那个“活动服务”耗时350ms，加上聚合和网络损耗，480ms是个合理结果。如果你愿意，还可以对活动服务本身再做缓存优化，但那就超出CompletableFuture的范畴了。
资源消耗方面，这个接口的线程利用率明显变高。5个任务并发执行时占用5个线程最多约400ms，而串行时虽然只占1个线程但口持续了1000多毫秒。从“占用时间”这个维度看，并发方案其实是把时间换成了空间，用更多线程换更短的总耗时。这也是为什么线程池大小配多大、线程池给谁用，需要认真规划的原因。
5.4 别忘了响应体里的部分成功语义
并行聚合之后有一个很容易被忽略的问题：如果其中一个服务失败了，整体接口怎么办？完全失败返回错误？还是部分成功、降级字段返回默认值？上面的代码里我用exceptionally返回null，这样某个字段失败不会影响整体接口，但前端拿到的JSON里会出现空字段，需要前端做非空判断。如果你希望某个强依赖失败时整体失败，就不要在那个future上加exceptionally，让异常冒泡到get那一层统一处理。这个取舍一定要在开发前和产品对齐，不要上线后才发现前后端理解不一致。
6. 常见踩坑与排错经验：吞异常、阻塞、线程池打满
6.1 异常被静默吞掉，日志里什么都没有
CompletableFuture有个非常让人头疼的行为：任务内部的异常如果不被处理，它不会打印任何日志，而是静静躺在那个Future对象里，只有当你调用get或join时才会抛出来。如果你在代码里创建了一个future但忘记取结果，异常就彻底消失了。
我的排查经验是，凡是异步任务内部一定要写日志，即使你认为上游不会异常。另外，全局兜底方面可以在任务入口用try-catch包裹，把异常信息完整记录下来。例如：
CompletableFuture.supplyAsync(() -> { try { return remoteClient.query(); } catch (Exception e) { log.error("query failed, param={}", param, e); return fallback; } }, pool);6.2 主线程提前返回，异步任务直接被“丢弃”
不是所有框架都会等待CompletableFuture完成再返回响应。在Spring Web MVC里，如果你的Controller方法直接返回对象，而CompletableFuture还在后台跑，那么响应已经发出去了，异步任务结果没人接。这一点跟“异步”两个字的语义有关：异步不等于响应也异步，除非你使用DeferredResult或WebFlux。
如果你在非Web场景，比如一个定时任务里启动异步任务，主线程执行完了整个方法，JVM还在运行，线程池里的任务会继续执行；但如果你的main方法结束了，非守护线程会不会被强制终止，取决于JVM退出逻辑。最稳妥的做法是：任务结束后显式调用线程池的shutdown()，或者在主流程结束前future.join()等待任务结果。
6.3 线程池被打满，ForkJoinPool的线程数不够
很多踩坑案例都是这样开始的：某一天线上突然大量请求耗时飙高，线程快照一打，发现ForkJoinPool.commonPool里的线程全部处于WAITING状态。原因就是某段代码用了不带线程池参数的supplyAsync，都挤到公共池里了，一旦某个上游变慢，公共池被占满，所有依赖公共池的业务一起遭殃。
这个问题的根因就是“共享”。解决方式也很直接：每个业务模块使用自己的线程池，线程池参数根据业务特性独立配置。隔离的意义不只是防止互相影响，更多的是让每个业务的排队情况、拒绝情况能被独立监控和告警。
6.4 get超时后任务还在跑，怎么办
get(timeout, TimeUnit)超时后，CompletableFuture不会自动中断底层任务。它只是让你不再等待，那个任务还在线程池里继续执行。所以必须在捕获TimeoutException后主动调用future.cancel(true)。但这里有个坑：cancel(true)对于非中断敏感的任务并不会真正停止它，只能防止结果被继续依赖。如果任务里访问了外部接口，没有响应中断信号，资源还是会被占用。更严格的做法是在任务内部检查当前线程的中断状态，配合超时取消来实现真正的“停止”。不过绝大多数场景下，我们能做到“不管它，让它跑完但不影响主流程”就够了，关键是不要让超时任务无限积累。
7. 面试与进阶：这些点才是CompletableFuture的拉开差距之处
7.1 基础题：CompletableFuture和Future的区别
很多面试候选人能答出“CompletableFuture支持回调、支持编排”这类标准答案，但你再追问一句“它是怎么实现回调的”，很多人就卡住了。CompletableFuture内部维护了一个依赖栈，后续通过thenXXX注册的回调会被压入这个栈，当任务完成时依次弹出执行。这就是它能够支持几十种编排方式的底层基础。理解这一点，你对API的记忆就不再是死记硬背。
7.2 进阶题：thenApply和thenApplyAsync的区别
这个问题是我筛选候选人是否真正写过异步代码的试金石。thenApply使用上一个任务的执行线程，thenApplyAsync把任务提交到线程池重新调度。前者省一次线程切换，性能略好，但如果上一个任务是公共线程池执行的，你无法控制它在哪个线程上跑；后者更灵活，也更容易出现上下文切换的开销。没有哪个绝对更好，只有合适不合适。
7.3 压轴题：异步任务里的ThreadLocal怎么传递
前面提到过，异步任务跨线程后ThreadLocal会丢失。如果你答“用TransmittableThreadLocal”，我会觉得你有实际经验；如果能进一步说出“用Runnable包装器在提交任务时快照上下文、执行前恢复”，那就说明你真的debug过这个问题。这里有一个简化版的上下文传递思路：
public class ContextRunnable implements Runnable { private final Runnable task; private final Map<String, String> contextSnapshot; public ContextRunnable(Runnable task, Map<String, String> context) { this.task = task; this.contextSnapshot = new HashMap<>(context); } @Override public void run() { Map<String, String> old = ThreadContext.get(); ThreadContext.set(contextSnapshot); try { task.run(); } finally { ThreadContext.set(old); } } }但单纯的包装器对CompletableFuture内部使用的回调链并不完全适用，因为CompletableFuture是直接把函数传给线程池，没有给你包一层的机会。这也是为什么业界会单独造一个TransmittableThreadLocal的原因——它通过Java Agent在JDK层面做了增强。
我记得有一次线上排查登录用户上下文丢失，最终定位到就是CompletableFuture异步线程里取不到RequestContext里的用户ID。当时临时方案是把用户ID作为参数显式传给异步任务，后来才引入中间件方案解决TraceId的透传问题。这个经历让我意识到，异步编程的难点不在API本身，而在于异步之后引入的上下文切割和运维复杂度。如果项目刚起步，尽量控制异步的使用范围，不要为了异步而异步。
最后再说一个多次帮我救场的习惯：给异步任务编好线程名、打好日志、配好告警，不要光看接口平均耗时下降就觉得万事大吉。CompletableFuture只是把复杂度转移了，并没有消除复杂度。你在并发编排上偷的懒，早晚会在某个凌晨的告警群里找回来。
