completablefuture 通过声明式回调机制实现异步任务编排，支持串行（thenapply/thencompose）、并行（allof/thencombine）和条件依赖，内置异常处理（exceptionally/handle），且线程执行可控。
接口回调在异步框架中，本质是“任务完成时自动通知并执行后续逻辑”，而不是让主线程停下来等结果。CompletableFuture 把这种通知机制封装成链式、可组合的函数式方法，让回调不再嵌套、不再难维护。
回调不是硬写if-else，而是声明式注册
传统回调（比如监听器模式）需要手动注册、管理生命周期；CompletableFuture 的回调是声明式的：你只管说“结果出来后我要做什么”，框架负责在合适时机触发。
- thenApply：有返回值的转换，比如把 String 转成 JSON 对象
- thenAccept：消费结果但不返回新值，适合打印日志、发消息
- whenComplete：无论成功失败都执行，适合统一清理或记录耗时
- handle：带异常参数的通用回调，能同时处理结果和异常
回调可串行，也可并行，还能互相依赖
CompletableFuture 不是简单的一次性通知，它支持多级编排，让回调之间形成清晰的数据流。
- 串行：A → B → C，用 thenApply 或 thenCompose（后者用于返回另一个 CompletableFuture 的场景）
- 并行聚合：多个服务调用同时发起，等全部完成再合并，用 allOf + join() 或 thenCombine
- 条件依赖：B 依赖 A 的结果才启动，用 thenCompose，避免线程阻塞或手动调度
异常不再是黑洞，回调自带兜底能力
传统 Future 出错后 get() 才抛异常，容易漏捕获；CompletableFuture 让异常也成为回调链的一部分。
- exceptionally：只处理异常，返回默认值，适合降级逻辑（如查缓存失败就返回空列表）
- handle：统一入口，参数包含 result 和 throwable，适合做统一埋点或日志记录
- 回调链中任意环节抛异常，会跳过后续 thenXXX，直接落到最近的 exceptionally 或 handle 中
回调执行在哪？线程可控，不黑箱
CompletableFuture 默认使用 ForkJoinPool.commonPool()，但你可以显式指定线程池，避免 IO 任务阻塞 CPU 密集型线程。
- IO 类任务（如 HTTP 调用）建议配独立线程池：supplyAsync(() -> callApi(), ioExecutor)
- 计算类任务可用默认池，或自定义 CPU 密集型池
- 回调方法（如 thenAccept）默认在前一个任务结束的线程上执行；加 async 后缀（如 thenAcceptAsync）则交由指定线程池执行
