Spring 7：Scoped Values 会不会把 ThreadLocal 烧掉？
先把三层东西分开。JEP 444 的虚拟线程是运行时调度；JEP 446 的 Scoped Values 是动态作用域中的不可变绑定；JEP 453 的 Structured Concurrency 是把子任务生命周期收回一个代码块。它们确实共同解决“线程很多、上下文怎么传、任务怎么收”的问题。可这不等于 Spring 7 已经把 ThreadLocal 从地球上删除，也不等于 @ConcurrencyLimit(20) 就是某个官方注解。公开检索能确认 Spring 7 的发布和安全修复资料，但没有核到原帖所写的这个注解与包名。
Scoped Values 的好处是边界清楚：值在 where(...).run(...) 期间可读，嵌套作用域可以重新绑定，跑出代码块就结束。它尤其适合 request id、trace id、当前用户这类“沿着调用链向下传、读多写少”的上下文。ThreadLocal 并非一出现就是罪人；它适合可变状态、可复用对象、显式清理的局部缓存和第三方库兼容。把 ThreadLocal 全换成 Scoped Values，可能把一个能用的接口改成一个需要改很多调用方的接口。
结构化并发也不是“以后不用 Future 了”。它的价值是：在一个 scope 里 fork 航班和酒店任务，其中一个失败，另一个可以被取消，退出 scope 时不会留下孤儿线程。可它要求任务确实能被同一个生命周期管住；把一个执行十分钟的后台作业塞进一次 HTTP scope，照样会把请求绑死。短生命周期和长生命周期不是一回事，代码写得整齐，系统时钟照样会走。
原帖把 @ConcurrencyLimit 当成虚拟线程时代的数据库保险丝，这个方向有工程价值，但需要先确认注解来源、适用 JDK、限流作用域、等待队列、异常传播和取消语义。我的收尾钉子是 Spring 官方 release note、源码包和一段真实迁移示例。框架升级不是把钥匙从口袋换到门牌，门上的锁、房间的边界、谁负责关门，都要一起设计。
来源：
- https://openjdk.org/jeps/444
- https://openjdk.org/jeps/446
- https://openjdk.org/jeps/453
- https://spring.io/projects/spring-framework