为什么 ScopedValue 是 SaaS 的分水岭
引言：SaaS 的问题，从来不在"业务复杂"，而在"上下文失控"
在单体应用时代，我们习惯于用 ThreadLocal 解决"上下文共享"问题：
- 当前用户是谁
- 当前租户是什么
- 当前数据源如何选择
这些做法在 同步、单线程、低并发 的世界里运转良好。
但当系统演进到 SaaS + 多租户 + 高并发 + 异步 + 云原生 之后，一个根本性问题浮出水面：
ThreadLocal 所依赖的前提条件，已经不成立了。
ScopedValue 的出现，并不是一个"语法升级"，而是 Java 对这一现实的正式回应。
一、ThreadLocal 曾经是答案，但它不再适合 SaaS
1. ThreadLocal 的隐含假设
ThreadLocal 的设计，隐含了几个前提：
- 一个请求只在一个线程内执行
- 线程的生命周期等于请求生命周期
- 不会跨线程、跨执行单元传播上下文
- 使用者会严格清理上下文
在现代 SaaS 架构中，这四条 全部失效。
2. SaaS 场景下的真实问题
在多租户系统中，ThreadLocal 带来的不是"偶发 bug"，而是系统性风险：
- 租户上下文泄漏到下一个请求
- 异步任务继承错误租户
- 虚拟线程下行为不可预测
- 排查困难，只能靠日志和"运气"
最危险的是：这些问题往往不会立刻暴露，而是以"偶现事故"的形式存在。
二、SaaS 的本质：上下文是"请求级"的，而不是"线程级"的
SaaS 的核心能力不是 CRUD，而是：
在同一套代码、同一进程中，安全地处理多个租户的请求。
这意味着：
- 租户上下文必须与"请求"绑定
- 而不是与"线程"绑定
ThreadLocal 解决的是"线程内共享"，
而 SaaS 需要的是"作用域内共享"。
这正是 ScopedValue 的设计起点。
三、ScopedValue：不是升级 ThreadLocal，而是替换它
1. ScopedValue 的核心语义
ScopedValue 引入了一个全新的模型：
- 上下文只能在明确的作用域内存在
- 作用域结束，上下文立即失效
- 上下文是只读的、不可变的
它解决的不是"怎么存值"，而是：
谁有权在什么范围内看到这个值。
2. 一个关键变化：控制权从"使用者"回到"框架"
ThreadLocal 的清理依赖开发者自觉；
ScopedValue 的生命周期由语言层面保证。
这是从"约定正确"到"机制正确"的转变。
四、为什么 ScopedValue 是 SaaS 的"分水岭"
分水岭之前：SaaS 建立在"约束"和"自律"之上
- 约定不能乱用异步
- 约定必须 finally remove
- 约定不能在子线程用租户上下文
这些约定一旦被打破，问题立即出现。
分水岭之后：SaaS 建立在"语言级保证"之上
ScopedValue 带来的变化是：
- 租户上下文只能存在于请求作用域
- 离开作用域，自动失效
- 异步、并发场景下语义仍然清晰
这使得多租户系统第一次拥有了可证明的正确性。
五、ScopedValue 与现代 Java 并发模型的契合
ScopedValue 并不是孤立出现的，它与以下能力高度协同：
- 虚拟线程（Virtual Threads）
- 结构化并发（Structured Concurrency）
- 请求级上下文建模
这些特性共同指向一个方向：
并发不是"线程技巧"，而是"作用域管理"。
ScopedValue 正是这个方向上的基础设施。
六、在多租户 SaaS 中，ScopedValue 改变了什么
1. 架构层面
- 多租户不再依赖 ThreadLocal
- 数据源路由成为纯函数式决策
- 上下文生命周期清晰可控
2. 工程层面
- 减少隐性 bug
- 降低调试和排查成本
- 更容易支持异步和并发扩展
3. 长期演进层面
- 为 Java 未来并发模型铺路
- 避免技术债随业务增长放大
七、结语：ScopedValue 不是"新特性"，而是"必要条件"
ScopedValue 的意义不在于"你能不能用"，而在于：
当系统规模足够大、并发足够高、多租户足够复杂时，你别无选择。
从这一刻开始，SaaS 架构进入了一个新的阶段：
- 上下文不再是"偷偷共享的状态"
- 而是"受控、可推理的作用域变量"
这，就是 ScopedValue 成为 SaaS 分水岭的原因。