Decade
ContextVar底层实现深度解析：从原理到实战
Zhongjun Qiu 元婴开发者
  2026-01-02 00:00:00   2026-01-19 18:30:42    3.5k Words  13 Mins  

核心洞察

Java的ThreadLocal绑在线程上，Python的ContextVar绑在执行上下文上。在协程时代，一条线程会并发执行多个Task，如果继续用ThreadLocal存储上下文，Task之间会互相覆盖。ContextVar通过”协程创建时复制Context”的机制，完美解决了这个问题。本文将深入解析ContextVar的底层实现机制，并与ThreadLocal进行本质对比。

一、为什么需要 ContextVar？

1.1 传统模型的问题

在 async/await + 多任务并发的 Python 程序中：

  • 同一个线程里会并发执行多个 Task / Coroutine
  • 不能用 threading.local() 来隔离上下文

例如：

1
2
3
Thread-1
 ├─ Task-A (user_id=1)
 └─ Task-B (user_id=2)

如果用 threading.local()： - Task-A / Task-B 会互相覆盖变量

1.2 ContextVar 的设计目标

ContextVar 的目标是：

让”上下文变量”绑定到「当前执行上下文（Task / 协程调用链）」而不是线程

这正是你在 LLM 调用链追踪、Agent / Tool 交织、async + 并发场景下需要的特性。

二、ContextVar 的抽象模型

2.1 核心概念

Python 对 ContextVar 的语义定义是：

ContextVar 的值属于一个 Context（上下文），而不是属于变量本身

关键概念有三个：

概念 含义
ContextVar 一个”变量声明”（key）
Context 当前执行环境中的一组变量映射
Context.run() 在某个 Context 下执行代码

2.2 抽象结构

你可以理解为：

1
2
3
4
Context
 ├─ llm_context -> LLMCallContext(...)
 ├─ request_id  -> xxx
 └─ trace_id    -> yyy

这种抽象设计使得 ContextVar 能够在协程/任务链中正确传递和隔离上下文。

三、ContextVar 的底层实现机制

3.1 Context 本质是什么？

在 CPython 中：

  • 每个执行单元（线程 / asyncio Task）都绑定着一个 Context 对象

这个 Context 内部结构可以抽象成：

1
2
class Context:
    data: dict[ContextVar, Any]

重点：Context 不是全局的，也不是线程唯一的，而是 可以被复制、继承、切换的执行上下文。

3.2 Context 是怎么”跟着协程跑”的？

协程创建时

当你创建一个新任务：

1
asyncio.create_task(coro())

CPython 会做一件非常关键的事情：

1
new_task.context = copy(current_context)

也就是说：

  • 新 Task 拷贝父 Task 的 Context
  • 后续修改互不影响

📌 这是 ContextVar 能在 async 场景下正确隔离的根本原因。

3.3 ContextVar.set() 到底做了什么？

1
_llm_context.set(ctx)

不是把值存到 _llm_context 这个对象里，而是等价于：

1
current_context.data[_llm_context] = ctx

也就是说：

  • ContextVar 只是一个 key
  • 真正的值存在于 当前 Context

3.4 ContextVar.get() 怎么取值？

1
_llm_context.get()

内部流程：

  1. 获取当前执行的 Context
  2. 在 context.data 中查找 _llm_context
  3. 找不到则返回 default

3.5 Context 切换是怎么发生的？

Context 切换发生在：

场景 是否切换
async/await 切换 ❌（同 Task 不切）
Task 创建 ✅（复制）
线程切换 ✅
contextvars.copy_context() ✅
Context.run(fn) ✅

CPython 在 调度协程 / 切换 Task 时，会同时切换当前 Context 指针。

四、与 Java ThreadLocal 的本质区别

4.1 核心差异对比

维度 Java ThreadLocal Python ContextVar
绑定对象 Thread Execution Context（Task）
async / 协程安全 ❌（天然不安全） ✅（原生支持）
上下文复制 ❌ ✅（Task 创建时拷贝）
上下文隔离粒度 粗（线程） 细（协程 / 调用链）
嵌套调用 易污染 天然支持
清理风险 高（内存泄漏） 低（作用域自动结束）
控制传播 几乎不可控 可精确控制

4.2 一句话总结

Java 的 ThreadLocal = 线程级上下文绑定 Python 的 ContextVar = 执行上下文（Task / 协程调用链）绑定

在同步、多线程模型里它们”看起来像”；在异步 / 协程模型里，它们的语义是完全不一样的。

五、ThreadLocal 的真实工作方式

5.1 ThreadLocal 并不”存值”

1
ThreadLocal<UserContext> ctx = new ThreadLocal<>();

值并不在 ThreadLocal 里，而是在：

1
2
3
4
Thread
 └─ ThreadLocalMap
     ├─ ThreadLocal A -> valueA
     └─ ThreadLocal B -> valueB

也就是说：

一个 Thread 持有一张 Map，key 是 ThreadLocal 实例

5.2 ThreadLocal 的致命前提

一个请求 = 一个线程

这在： - Servlet 早期模型 - 同步阻塞调用

是成立的。

5.3 在现代 Java 里为什么出问题？

① 线程池复用

1
2
3
Thread-1
 ├─ 请求 A（user=1）
 └─ 请求 B（user=2）

如果你忘了 remove()： 👉 上下文串请求

② 异步模型（CompletableFuture / Reactor）

1
CompletableFuture.supplyAsync(...)
  • 逻辑上下文 ≠ 执行线程
  • ThreadLocal 不会自动传播
  • 甚至传播到”错误的线程”

👉 必须靠： - 手动传参 - TTL（TransmittableThreadLocal） - Reactor Context

六、通俗理解：ThreadLocal vs ContextVar

6.1 大白话区分

ThreadLocal： 👉「这条线程在干活时，用的共享便签纸」

ContextVar： 👉「这一次任务 / 请求 / 对话，自带的随身小本子」

便签纸贴在线程上 小本子跟着”事情”走

6.2 关键差异

“东西是挂在线程上，还是挂在事情上？”

6.3 直观的类比

ThreadLocal 像什么？

办公室里的一张工位桌子 你把 user 信息放在桌上 谁坐这张桌子，看到的就是它

  • 人（任务）会换桌子 ❌
  • 桌子会被复用 ❌

ContextVar 像什么？

每个人随身携带的工牌 不管走到哪、换多少房间 工牌始终跟着这个人

  • 人分裂成多个分身 → 复制工牌 ✔️
  • 人结束 → 工牌作废 ✔️

七、为什么 Java 项目”习惯用 ThreadLocal 存 user”？

一句话真相：

不是 ThreadLocal 特别强，而是 Java 早期模型太单一

  • 同步
  • 阻塞
  • 一请求一线程

在这个世界里：

“线程 ≈ 请求 ≈ 上下文”

所以 ThreadLocal 恰好”凑巧好用”。

八、现代模型的挑战

今天常见的是： - 异步 - 回调 - 消息驱动 - AI Agent / Tool / RAG - 一个请求拆成 N 个子任务

这时候：

“线程”已经不能代表”当前这件事”了

8.1 可以这样跟 Java 同事说：

ThreadLocal 适合”线程就是请求”的时代 ContextVar 适合”一个请求会分裂成很多并发任务”的时代

九、协程级别存储的实现

9.1 能不能实现一个”协程级别的存储”？

是的，完全可以实现”协程级别的存储” 而且 Python 的 ContextVar、Java Loom 的 ScopedValue 本质上就是它。

但有一个关键前提：

这个东西必须由”语言运行时 / 调度器”配合实现 用普通库，最多只能做到”近似模拟”，做不到语义完整

9.2 为什么”协程级别存储”不是 ThreadLocal 升级版？

先用一句通俗的话说清楚本质区别：

ThreadLocal 是：值挂在线程上 协程级存储是：值挂在”当前执行单元”上

关键在于： 👉 谁在控制”当前执行单元”？

  • 线程 → OS / JVM
  • 协程 → 语言运行时调度器

9.3 真正的难点

❗ 难点 1：你怎么拿到”当前协程是谁”？

  • Java（无 Loom）：
    • ❌ JVM 根本不知道”协程”这个概念
    • ❌ CompletableFuture / Reactor 都是库级抽象
  • Python / Go：
    • ✅ 运行时知道当前 Task / Goroutine

👉 没有”调度器视角”，你根本不知道当前是谁在跑

❗ 难点 2：协程切换时，谁帮你切上下文？

协程执行是这样的：

1
2
3
Task A → suspend
Task B → run
Task A → resume

在这三次切换中，你需要：

1
2
切走 A 时：保存上下文
切到 B 时：恢复 B 的上下文

⚠️ 这个时机只有运行时知道。

❗ 难点 3：子协程的”上下文继承”语义

你真正想要的是：

1
2
3
4
父协程
 └─ user = A
     ├─ 子协程 1（继承 A）
     └─ 子协程 2（继承 A）

这一步意味着：

  • 创建协程时，要拷贝上下文
  • 而不是共享同一份

这已经是语言语义设计问题了，而不是工具类问题。

9.4 现实世界的”正确答案”

1️⃣ Python：ContextVar

1
2
3
4
user = ContextVar("user")

user.set("A")
asyncio.create_task(task())  # 自动继承

本质是：

协程创建时，运行时复制 Context

2️⃣ Java 新时代的答案：Loom + ScopedValue

1
2
3
4
5
ScopedValue<User> USER = ScopedValue.newInstance();

ScopedValue.where(USER, userA).run(() -> {
    // 这里 USER.get() == userA
});

关键点： - 作用域级 - 自动回滚 - 绑定的是”虚拟线程 / 执行上下文”

3️⃣ Go：直接内建到 runtime

1
context.Context
  • 显式传
  • runtime 协助
  • 不依赖线程

十、ThreadLocal 的内存泄露风险

10.1 一句话结论

ThreadLocal 的内存泄露，本质不是”没人 remove”， 而是：ThreadLocalMap 的 key 会被 GC 掉，但 value 还被线程强引用着。

也就是常说的：

“key 是弱引用，value 是强引用”

10.2 ThreadLocal 的真实存储结构

ThreadLocal 并不存数据

1
ThreadLocal<User> userCtx = new ThreadLocal<>();

很多人误以为 userCtx 里存了 User，这是错的。

真实结构是：

1
2
3
Thread
 └─ ThreadLocalMap
      ├─ Entry(key=ThreadLocal, value=User)

📌 Thread 持有 ThreadLocalMap 📌 ThreadLocalMap 持有 value 的强引用

10.3 泄露是怎么一步一步发生的？

🧩 第 1 步：你创建了 ThreadLocal

1
2
3
4
void handle() {
    ThreadLocal<BigObject> tl = new ThreadLocal<>();
    tl.set(new BigObject());
}

结构：

1
2
3
4
Thread
 └─ ThreadLocalMap
      └─ key = tl（弱引用）
      └─ value = BigObject（强引用）

🧩 第 2 步：方法结束，ThreadLocal 变量消失

1
2
3
4
5
tl 这个局部变量
↓
没有任何强引用
↓
GC 回收 ThreadLocal 对象

现在变成：

1
2
3
4
Thread
 └─ ThreadLocalMap
      └─ key = null   （弱引用被回收）
      └─ value = BigObject（还在！）

⚠️ 重点来了：value 还活着

🧩 第 3 步：线程还活着（线程池）

在 Web 服务中： - 线程来自线程池 - 线程 生命周期 ≈ 应用生命周期

所以：

1
2
ThreadLocalMap
  → Entry(key=null, value=BigObject)

这个 BigObject： - ❌ 无法通过 key 访问 - ❌ 无法被 GC - ❌ 无法 remove

👉 彻底变成”僵尸对象”

10.4 为什么线程池会把问题放大 100 倍？

如果是一次性线程：

1
线程结束 → ThreadLocalMap 释放 → 一切 OK

但在线程池中：

1
2
3
4
5
线程一直活着
↓
ThreadLocalMap 一直活着
↓
value 一直活着

所以：

ThreadLocal 的内存泄露，本质上是”线程活得太久”

10.5 为什么 ContextVar / ScopedValue 不会这样？

因为它们是： - 作用域级 - 随执行结束自动销毁 - 不绑定”长寿命容器”

它们更像：

函数栈上的变量，而不是线程私有缓存

十一、异步/任务链的正确理解

11.1 核心概念

这里说的”异步 / 任务链”，既不是”子线程”， 也不完全等同于”协程”，而是： 👉「一件逻辑上的事情，被拆成了多个执行片段，在不同时间、可能在不同线程上继续执行」

重点是：逻辑连续 ≠ 执行连续

11.2 三个关键概念

1️⃣ 线程（Thread）

线程是”CPU 执行的载体”

特点： - OS / JVM 调度 - 有独立的栈 - 生命周期通常较长（线程池）

1
CPU ←→ Thread

👉 ThreadLocal 就是绑在线程上的

2️⃣ 协程（Coroutine / Task / Fiber）

协程是”一段可以暂停、恢复的执行逻辑”

特点： - 不一定绑定线程 - 可以在不同线程上恢复 - 生命周期 = 逻辑任务

1
2
3
4
Task A
 ├─ suspend
 ├─ resume
 └─ finish

👉 ContextVar / ScopedValue 绑定的是这个层面

3️⃣ 异步 / 任务链

异步 / 任务链 =「一次逻辑任务的生命周期」

它可能包含： - 同步代码 - 异步回调 - 多个协程 - 多个线程切换

它是”逻辑概念”，不是执行实体

11.3 为什么 ThreadLocal 在这里就不行了？

因为 ThreadLocal 的世界观是：

“当前线程 = 当前事情”

但现实已经变成：

1
2
3
4
当前事情
 ├─ Thread-1（一会儿）
 ├─ Thread-7（一会儿）
 └─ Thread-3（一会儿）

你把 user 放在 ThreadLocal： - 线程一换 - 上下文就断了

11.4 ContextVar / ScopedValue 是怎么理解”任务链”的？

核心一句话：

它们不关心”你在哪个线程”， 只关心”你是不是在同一条执行语义链上”

Python（ContextVar）

1
2
3
4
user.set("A")

await step1()
await step2()
  • await 会挂起
  • 任务恢复时，Context 自动带回来
  • 哪怕换线程，语义不变

Java Loom（ScopedValue）

1
2
3
4
ScopedValue.where(USER, userA).run(() -> {
    step1();
    step2();
});

run 定义了一个作用域： - 在这个作用域内 - 不管怎么切换执行单元 - USER 都是同一个

11.5 非常关键的一点

“异步 / 任务链 ≠ 子线程”

我们直接对比：

概念 是不是子线程？
Thread ✅ 是
协程 / Task ❌ 不是
异步任务链 ❌ 不是

异步任务链是一种”逻辑连续性”，不是执行方式

十二、实战应用：LLM 调用链追踪

12.1 标准实现模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
from contextvars import ContextVar

_llm_context: ContextVar[Optional[LLMCallContext]] = ContextVar(
    "llm_context", default=None
)

@contextmanager
def llm_context(module_name: str, user_id: str = None, conversation_id: str = None):
    ctx = LLMCallContext(
        request_id=str(uuid.uuid4()),
        module_name=module_name,
        user_id=user_id,
        conversation_id=conversation_id,
    )
    _llm_context.set(ctx)  # 设置到上下文变量
    try:
        yield ctx
    finally:
        clear_llm_context()  # 自动清除

12.2 使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
# 在任意函数中获取上下文
def get_llm_context():
    return _llm_context.get()

# 在 Agent / Tool 调用中自然传播
@contextmanager
def llm_context(module_name: str, user_id: str = None, conversation_id: str = None):
    ctx = LLMCallContext(...)
    _llm_context.set(ctx)
    try:
        yield ctx
    finally:
        _llm_context.set(None)

12.3 优势体现

  • 跨协程传播：在 async/await 中自动传播
  • 任务隔离：不同请求/用户上下文互不干扰
  • 作用域管理：使用 contextmanager 自动清理
  • 类型安全：通过类型注解保证类型正确

十三、总结与选型建议

13.1 核心要点回顾

  1. ContextVar 绑定的是执行上下文，而不是线程
  2. 协程创建时自动复制 Context，保证上下文隔离
  3. ThreadLocal 适合同步模型，不适合异步/协程
  4. ContextVar 生命周期 = 逻辑作用域，不会内存泄漏
  5. 异步任务链是逻辑连续的，不是执行连续

13.2 选型建议

选择 ContextVar（Python）

  • ✅ 异步编程环境（asyncio、FastAPI）
  • ✅ 协程/任务链上下文传递
  • ✅ LLM / Agent / RAG 调用链追踪
  • ✅ 需要细粒度上下文隔离

选择 ThreadLocal（Java）

  • ✅ 纯同步调用栈
  • ✅ 线程不切换
  • ✅ 生命周期与线程严格绑定

典型例子： - JDBC Connection 绑定线程 - 事务上下文（早期 Spring） - 线程内缓存

避免使用 ThreadLocal（Java）

  • ❌ 用户身份（user / tenant）
  • ❌ trace / span
  • ❌ 请求上下文
  • ❌ 异步回调
  • ❌ 并发 fan-out

13.3 最终判断标准

你可以在代码评审时问一句：

“这段代码有没有可能换线程执行？”

  • 如果答案是 永远不会 → ThreadLocal 勉强可用
  • 只要有 一点可能 → ThreadLocal 就已经不安全了

13.4 一句话时代总结

ThreadLocal 不是被”废弃”了， 而是它所依赖的”线程 = 请求”的时代结束了。

你现在做的 LLM / Agent / async 系统，如果还用 ThreadLocal 存 user，那基本等于：

在协程世界里，用”工位号”来识别”人”

本文整理自与 AI 的技术对话，深入探讨了 ContextVar 的底层实现机制及其在现代异步编程中的应用。如有疑问或需要补充，欢迎讨论。

ContextVar底层实现深度解析：从原理到实战
2026/01/02/contextvar-deep-dive/
Author
Zhongjun Qiu
Published
2026-01-02 00:00
License
 REWARD AUTHOR
 Comments
Comment plugin failed to load
Loading comment plugin
  1. 核心洞察
  2. 一、为什么需要 ContextVar？
    1. 1.1 传统模型的问题
    2. 1.2 ContextVar 的设计目标
  3. 二、ContextVar 的抽象模型
    1. 2.1 核心概念
    2. 2.2 抽象结构
  4. 三、ContextVar 的底层实现机制
    1. 3.1 Context 本质是什么？
    2. 3.2 Context 是怎么”跟着协程跑”的？
      1. 协程创建时
    3. 3.3 ContextVar.set() 到底做了什么？
    4. 3.4 ContextVar.get() 怎么取值？
    5. 3.5 Context 切换是怎么发生的？
  5. 四、与 Java ThreadLocal 的本质区别
    1. 4.1 核心差异对比
    2. 4.2 一句话总结
  6. 五、ThreadLocal 的真实工作方式
    1. 5.1 ThreadLocal 并不”存值”
    2. 5.2 ThreadLocal 的致命前提
    3. 5.3 在现代 Java 里为什么出问题？
      1. ① 线程池复用
      2. ② 异步模型（CompletableFuture / Reactor）
  7. 六、通俗理解：ThreadLocal vs ContextVar
    1. 6.1 大白话区分
    2. 6.2 关键差异
    3. 6.3 直观的类比
      1. ThreadLocal 像什么？
      2. ContextVar 像什么？
  8. 七、为什么 Java 项目”习惯用 ThreadLocal 存 user”？
  9. 八、现代模型的挑战
    1. 8.1 可以这样跟 Java 同事说：
  10. 九、协程级别存储的实现
    1. 9.1 能不能实现一个”协程级别的存储”？
    2. 9.2 为什么”协程级别存储”不是 ThreadLocal 升级版？
    3. 9.3 真正的难点
      1. ❗ 难点 1：你怎么拿到”当前协程是谁”？
      2. ❗ 难点 2：协程切换时，谁帮你切上下文？
      3. ❗ 难点 3：子协程的”上下文继承”语义
    4. 9.4 现实世界的”正确答案”
      1. 1️⃣ Python：ContextVar
      2. 2️⃣ Java 新时代的答案：Loom + ScopedValue
      3. 3️⃣ Go：直接内建到 runtime
  11. 十、ThreadLocal 的内存泄露风险
    1. 10.1 一句话结论
    2. 10.2 ThreadLocal 的真实存储结构
      1. ThreadLocal 并不存数据
    3. 10.3 泄露是怎么一步一步发生的？
      1. 🧩 第 1 步：你创建了 ThreadLocal
      2. 🧩 第 2 步：方法结束，ThreadLocal 变量消失
      3. 🧩 第 3 步：线程还活着（线程池）
    4. 10.4 为什么线程池会把问题放大 100 倍？
    5. 10.5 为什么 ContextVar / ScopedValue 不会这样？
  12. 十一、异步/任务链的正确理解
    1. 11.1 核心概念
    2. 11.2 三个关键概念
      1. 1️⃣ 线程（Thread）
      2. 2️⃣ 协程（Coroutine / Task / Fiber）
      3. 3️⃣ 异步 / 任务链
    3. 11.3 为什么 ThreadLocal 在这里就不行了？
    4. 11.4 ContextVar / ScopedValue 是怎么理解”任务链”的？
      1. 核心一句话：
      2. Python（ContextVar）
      3. Java Loom（ScopedValue）
    5. 11.5 非常关键的一点
  13. 十二、实战应用：LLM 调用链追踪
    1. 12.1 标准实现模式
    2. 12.2 使用示例
    3. 12.3 优势体现
  14. 十三、总结与选型建议
    1. 13.1 核心要点回顾
    2. 13.2 选型建议
      1. 选择 ContextVar（Python）
      2. 选择 ThreadLocal（Java）
      3. 避免使用 ThreadLocal（Java）
    3. 13.3 最终判断标准
    4. 13.4 一句话时代总结
  1. 核心洞察
  2. 一、为什么需要 ContextVar？
    1. 1.1 传统模型的问题
    2. 1.2 ContextVar 的设计目标
  3. 二、ContextVar 的抽象模型
    1. 2.1 核心概念
    2. 2.2 抽象结构
  4. 三、ContextVar 的底层实现机制
    1. 3.1 Context 本质是什么？
    2. 3.2 Context 是怎么”跟着协程跑”的？
      1. 协程创建时
    3. 3.3 ContextVar.set() 到底做了什么？
    4. 3.4 ContextVar.get() 怎么取值？
    5. 3.5 Context 切换是怎么发生的？
  5. 四、与 Java ThreadLocal 的本质区别
    1. 4.1 核心差异对比
    2. 4.2 一句话总结
  6. 五、ThreadLocal 的真实工作方式
    1. 5.1 ThreadLocal 并不”存值”
    2. 5.2 ThreadLocal 的致命前提
    3. 5.3 在现代 Java 里为什么出问题？
      1. ① 线程池复用
      2. ② 异步模型（CompletableFuture / Reactor）
  7. 六、通俗理解：ThreadLocal vs ContextVar
    1. 6.1 大白话区分
    2. 6.2 关键差异
    3. 6.3 直观的类比
      1. ThreadLocal 像什么？
      2. ContextVar 像什么？
  8. 七、为什么 Java 项目”习惯用 ThreadLocal 存 user”？
  9. 八、现代模型的挑战
    1. 8.1 可以这样跟 Java 同事说：
  10. 九、协程级别存储的实现
    1. 9.1 能不能实现一个”协程级别的存储”？
    2. 9.2 为什么”协程级别存储”不是 ThreadLocal 升级版？
    3. 9.3 真正的难点
      1. ❗ 难点 1：你怎么拿到”当前协程是谁”？
      2. ❗ 难点 2：协程切换时，谁帮你切上下文？
      3. ❗ 难点 3：子协程的”上下文继承”语义
    4. 9.4 现实世界的”正确答案”
      1. 1️⃣ Python：ContextVar
      2. 2️⃣ Java 新时代的答案：Loom + ScopedValue
      3. 3️⃣ Go：直接内建到 runtime
  11. 十、ThreadLocal 的内存泄露风险
    1. 10.1 一句话结论
    2. 10.2 ThreadLocal 的真实存储结构
      1. ThreadLocal 并不存数据
    3. 10.3 泄露是怎么一步一步发生的？
      1. 🧩 第 1 步：你创建了 ThreadLocal
      2. 🧩 第 2 步：方法结束，ThreadLocal 变量消失
      3. 🧩 第 3 步：线程还活着（线程池）
    4. 10.4 为什么线程池会把问题放大 100 倍？
    5. 10.5 为什么 ContextVar / ScopedValue 不会这样？
  12. 十一、异步/任务链的正确理解
    1. 11.1 核心概念
    2. 11.2 三个关键概念
      1. 1️⃣ 线程（Thread）
      2. 2️⃣ 协程（Coroutine / Task / Fiber）
      3. 3️⃣ 异步 / 任务链
    3. 11.3 为什么 ThreadLocal 在这里就不行了？
    4. 11.4 ContextVar / ScopedValue 是怎么理解”任务链”的？
      1. 核心一句话：
      2. Python（ContextVar）
      3. Java Loom（ScopedValue）
    5. 11.5 非常关键的一点
  13. 十二、实战应用：LLM 调用链追踪
    1. 12.1 标准实现模式
    2. 12.2 使用示例
    3. 12.3 优势体现
  14. 十三、总结与选型建议
    1. 13.1 核心要点回顾
    2. 13.2 选型建议
      1. 选择 ContextVar（Python）
      2. 选择 ThreadLocal（Java）
      3. 避免使用 ThreadLocal（Java）
    3. 13.3 最终判断标准
    4. 13.4 一句话时代总结