Future 是状态容器而非执行代理，submit() 立即返回 Future 作为凭证；任务在工作线程中异步执行，成败均通过 set_result/set_exception 存入 Future；异常不自动抛出，仅 result() 方法触发重抛，未调用则异常被静默存储。

因为 submit() 的设计目标是“异步提交 + 延迟取结果”，它必须把任务执行的**全部可能输出**（包括正常返回值和未捕获异常）统一收口到一个对象里——这个对象就是 Future。

Future 本质是一个状态容器，不是执行代理

submit() 立即返回 Future，并不意味着任务已开始或已完成。它只是给主线程发了一个“凭证”：将来可通过这个凭证查结果、查状态、取消任务。而任务本身被封装进 _WorkItem，由工作线程异步调用 run() 执行。run() 内部做了 try/catch 包裹：

• 若成功，调用 future.set_result(value)
• 若抛异常，调用 future.set_exception(exc)

这个机制确保无论任务成败，Future 都能进入 done() == True 状态，但异常不会自动冒泡——它只是被安全存进 Future 的私有字段里。

异常不传播，是因为没有触发“异常出口”

Java 和 Python 的 concurrent.futures 中，Future 的 result() 方法才是唯一定义了“异常重抛语义”的公开接口。它的实现逻辑是：

• 等待任务完成（阻塞或超时）
• 检查内部是否存有异常
• 如有，直接 raise 原始异常（Python）或包装为 ExecutionException 后 throw（Java）

换言之，Future 不是“吞”异常，而是把异常当作一种合法的执行结果来存储；你不主动打开这个“结果抽屉”，它就一直锁着。

不调用 result() 或 exception()，等于没读取执行反馈

就像发一封挂号信，邮局（线程池）把信（任务）送到了，但收件人（主线程）不拆封（不调 result()），就永远不知道里面是合同还是拒收单（异常）。常见误操作包括：

• 只调用 future.done() 判断状态，却忽略后续取值
• 用 as_completed() 遍历时，只打印 future 而不调 future.result()
• 提交后直接 shutdown()，未等所有 future 完成或检查异常

这些场景下，异常确实不会被感知，但责任不在 Future，而在调用方跳过了结果消费环节。

这种设计不是缺陷，而是权衡

如果 submit() 在异常发生时立刻中断主线程，就违背了“异步非阻塞”原则；如果让每个子线程自行打印堆栈，又会导致日志混乱、无法集中处理。Future 的封装方式把控制权交还给上层：你可以批量检查、按需重试、统一兜底，也可以彻底忽略——只是后者需要承担后果。