ThreadLocal 实现国际化语言隔离的核心是为每个请求线程绑定独立 Locale，需在拦截器/Filter 中解析并 set，在 finally 中 remove；提供 getCurrentLocale() 工具方法；异步场景需手动透传，可结合 TaskDecorator 封装 LocaleAwareExecutor。
在业务框架中用 ThreadLocal 实现国际化语言隔离，核心是让每个请求（即每个线程）持有独立的语言上下文，避免多线程间语言信息互相干扰。关键不在于 ThreadLocal 本身，而在于它如何与 Web 请求生命周期、拦截器、以及国际化工具（如 Spring 的 LocaleResolver）协同工作。
绑定语言信息到当前请求线程
在请求进入框架的最早入口（如 Spring MVC 的拦截器或 Filter）中，从请求头（Accept-Language）、参数（lang=zh_CN）或 token 中解析出用户期望的语言，然后存入自定义的 ThreadLocal<Locale>：
- 定义一个静态 ThreadLocal： private static final ThreadLocal<Locale> localeHolder = ThreadLocal.withInitial(() -> Locale.getDefault());
- 在 preHandle 或 doFilter 中调用 localeHolder.set(resolvedLocale);
- 务必在请求结束时（afterCompletion / finally 块）调用 localeHolder.remove();，防止线程复用（如 Tomcat 线程池）导致脏数据
提供线程安全的语言获取入口
封装一个工具类方法，统一对外暴露当前线程的语言，业务代码无需感知 ThreadLocal 细节：
- public static Locale getCurrentLocale() { return localeHolder.get(); }
- 可进一步扩展为返回带时区的
LocaleContext，或直接返回MessageSource的解析结果（如getMessage(code, args, getCurrentLocale())） - 避免在 service 层硬编码
Locale.getDefault()或依赖 Spring 的RequestContextHolder（后者在异步线程中不可用）
适配异步与线程切换场景
当业务使用 @Async、CompletableFuture 或自定义线程池时，父线程的 ThreadLocal 不会自动传递到子线程，需手动透传：
立即学习“Java免费学习笔记（深入）”；
- 使用
InheritableThreadLocal只能解决父子线程继承，但对线程池无效（因线程复用） - 推荐方案：封装
LocaleAwareExecutor，在提交任务前捕获当前 locale，执行时再 set 进新线程的 ThreadLocal - Spring Boot 2.3+ 可结合
TaskDecorator实现全局透传：executor.setTaskDecorator(runnable -> () -> { Locale l = getCurrentLocale(); try { localeHolder.set(l); runnable.run(); } finally { localeHolder.remove(); } });
与 Spring 国际化体系桥接（可选但推荐）
若项目已用 Spring 的 MessageSource 和 LocaleResolver，可通过自定义 LocaleContext 让其感知 ThreadLocal 中的语言：
- 实现
LocaleContext子类，重写getLocale()返回localeHolder.get() - 在需要动态取值的地方（如
MessageSource.getMessage(...)），显式传入该LocaleContext - 不建议覆盖 Spring 默认的
LocaleContextHolder，易与 WebMvc 冲突；保持双轨并行更可控
