FutureTask被用作任务状态的可观测锚点以提取阶段性指纹。它因具备可执行/查询/取消能力、明确状态机及可重写done()方法而被优选；切面中通过封装TracedFutureTask注入上下文并记录提交、启动、完成、取消四类结构化指纹，需注意线程安全与字段克制。
在接口切面拦截器中用 FutureTask 提取“阶段性指纹”，本质不是让 FutureTask 做日志埋点，而是利用它作为任务状态的可观测锚点——把任务生命周期的关键节点（如提交、开始执行、完成、异常、取消）映射为可采集、可聚合的指纹信息。关键在于不侵入业务逻辑，也不依赖线程名或堆栈，而是从 FutureTask 的状态流转和回调机制中自然提取。
一、为什么选 FutureTask 而非普通 Runnable 或 CompletableFuture
FutureTask 是少数同时满足三个条件的并发组件：
- 实现了 RunnableFuture 接口，天然具备“可执行 + 可查询 + 可取消”三重能力
- 状态机明确（NEW → COMPLETING → NORMAL/CANCELLED/EXCEPTIONAL），且所有状态变更都发生在内部同步块中，无竞态干扰
- 支持重写 done() 方法——这是唯一无需反射、无需 AOP 增强就能捕获“任务真正结束时刻”的钩子
二、在切面中封装并注入带指纹能力的 FutureTask
不要在拦截器里 new FutureTask 后直接 submit；而是把原始 Callable 包装成一个“带上下文快照”的增强版 FutureTask：
- 在切面 preHandle 阶段，从 RequestContextHolder 或 MDC 中提取 traceId、uri、method、用户ID、入口标签等，构造成一个轻量级上下文对象 context
- 创建自定义 FutureTask 子类（如 TracedFutureTask），构造时传入 context 和原始 Callable
- 重写 done() 方法：在 super.done() 后立即记录“完成指纹”，包括 context.id、耗时、isCancelled()、isDone()、getNow(null) 是否为 null、异常类型（若存在）
- 将该 FutureTask 提交到统一异步线程池（避免使用默认 ForkJoinPool，便于监控和隔离）
三、提取四类典型阶段性指纹
每个指纹建议以结构化 JSON 打点，写入本地 ring buffer 或发往日志中间件：
- 提交指纹：拦截器进入时生成，含 traceId、uri、submitTime、线程池队列长度、future.hashCode()
- 启动指纹：需借助 ThreadLocal + 线程池装饰器，在 execute 前 set 标记，run() 第一行清除并打点 —— 含 actualStartTime、是否延迟触发、排队时长
- 完成指纹：在 done() 中生成，含 finishTime、totalCost、resultType（NORMAL / CANCELLED / EXCEPTIONAL）、exceptionClass（如有）
- 取消指纹：仅当 cancel(true/false) 返回 true 时触发，记录 cancelTime、mayInterruptIfRunning、cancelFrom（调用方堆栈简写）
四、注意事项与避坑点
实际落地时容易忽略几个细节：
- FutureTask 的 done() 在任意线程调用（可能是 worker 线程，也可能是 cancel 的调用线程），务必确保日志打点线程安全，避免 MDC 跨线程污染
- 不要在 get() 中提取指纹——它会阻塞，违背“异步提取”初衷；所有指纹必须来自状态变更事件本身
- 如果业务用了 CompletableFuture，它不提供类似 done() 的钩子，需改用 whenComplete 或 handle，但注意它们可能被多次调用（组合场景下）
- 指纹字段要克制，避免记录 request body 或敏感参数；聚焦可观测性必需字段即可
