completeOnTimeout是Java 11引入的兜底方法，超时后填默认值且不中断原任务；orTimeout则抛TimeoutException使CompletableFuture异常完成，强制失败处理。
completeOnTimeout 是什么，和 orTimeout 有什么区别
completeOnTimeout 是 Java 11 引入的兜底方法，语义是“超时后先填一个默认值，如果后续有真实结果到达，就自动替换掉”。它不抛异常，也不中断原任务，只是提供一个“占位结果”。
而 orTimeout 是“超时即失败”，会直接把 CompletableFuture 置为异常状态（TimeoutException），后续必须用 exceptionally 或 handle 捕获，否则链路中断。
简单记：一个保流程不断（填默认值），一个保契约不破（显式失败）。
什么时候该用 completeOnTimeout 而不是 exceptionally + orTimeout
当你需要「业务上可接受降级结果」，且下游超时后仍希望继续执行、不阻断整个链路时，completeOnTimeout 更干净。
常见场景包括：
- 查缓存超时，用本地配置兜底
- 调用非核心推荐服务超时，返回空列表或热门默认项
- 聚合多个异步结果时，某个非关键字段缺失不影响主流程
反例：支付扣款、库存预占这类强一致性操作，不能用 completeOnTimeout —— 它不会取消原任务，可能造成“超时后又成功”的双写风险。这种必须用 orTimeout + 显式补偿。
completeOnTimeout 的实际写法和容易踩的坑
基本写法：future.completeOnTimeout("default", 2, TimeUnit.SECONDS)。
但要注意三点：
- 它只对「尚未完成」的
CompletableFuture生效；如果上游已经complete或completeExceptionally，调用无效 - 它不取消原任务 —— 原异步操作仍在后台运行，可能造成资源浪费或副作用（比如发了两次 HTTP 请求）
- 默认值类型必须和 future 的泛型一致，否则编译报错；不要试图用
Object强转，会丢失类型安全 - 如果你用的是
thenCompose后续链，确保默认值能被下游函数正常处理（比如传null进去却没判空，会 NPE）
示例（安全写法）：
CompletableFuture<String> result = CompletableFuture
.supplyAsync(() -> callExternalApi(), ioPool())
.completeOnTimeout("fallback-result", 1, TimeUnit.SECONDS);
如何和线程池、超时配合形成完整兜底链
completeOnTimeout 只解决“结果兜底”，不解决“任务超时控制”。真正健壮的链路要三层防护：
- 最外层：用
completeOnTimeout提供默认值（保障返回不空） - 中间层：给底层异步调用本身设超时（如
HttpClient的connectTimeout、readTimeout），避免线程卡死 - 最内层：用自定义
ExecutorService（比如ioPool()），防止阻塞型 IO 拖垮ForkJoinPool.commonPool
漏掉任何一层，都可能导致：兜底值回来了，但线程池已耗尽；或者超时了，但请求还在后台跑着，下游重复收到回调。
