本质是异常消息在构造、捕获或日志化时未统一使用utf-8编码，因java默认依赖平台编码（如windows的gbk），导致含中文的message在跨线程传递或输出时失真。
多语言系统动态切换时，线程池内部任务抛出的异常 message 出现操作系统编码乱码，本质不是线程池的问题，而是异常文本在构造、捕获、日志化或跨线程传递过程中，未统一使用 utf-8 编码且缺乏显式字符集声明导致的。java、.net 等主流运行时默认使用平台编码（如 windows 的 gbk），一旦异常消息含中文等非 ascii 字符，又未经规范处理，就极易在日志输出、远程传输或 ui 展示环节失真。
确保异常消息源头使用 UTF-8 字符集
异常本身不存储编码信息，它的 message 是字符串——而字符串的编码取决于其创建方式：
- 手动 throw new RuntimeException("用户未登录")：该字符串字面量在源文件保存为 UTF-8 且编译器正确识别时，JVM/.NET 会按源码编码解析，推荐在 IDE 和构建脚本中强制指定 UTF-8（如 Maven 的
<project.build.sourceencoding>UTF-8</project.build.sourceencoding>） - 从外部读取的提示文案（如 properties 文件、数据库字段）：必须显式指定编码。例如 Java 中加载资源文件时用
new InputStreamReader(inputStream, StandardCharsets.UTF_8)；.NET 中用Encoding.UTF8读取配置字符串 - 拼接生成的消息（如
"操作失败，原因：" + e.getMessage()）：确保参与拼接的所有字符串来源均为 UTF-8 解码所得，避免混入平台默认解码结果
在线程池任务中统一捕获并标准化异常 message
线程池执行的任务是异常传播的“黑箱”，主线程无法直接干预其内部异常输出。因此需在任务边界做拦截：
- 对 Runnable/Callable 包装一层 try-catch，在 catch 块中将原始异常 message 重新构造为 UTF-8 安全字符串，再 re-throw 或记录。例如：
String safeMsg = new String(cause.getMessage().getBytes(StandardCharsets.ISO_8859_1), StandardCharsets.UTF_8);（仅当确认原 message 被错误按 ISO-8859-1 解码时适用） - 更稳妥做法是统一使用
String.format(Locale.ROOT, "%s", msg)或直接新建异常：throw new RuntimeException("[i18n] " + msg, cause)，避免依赖底层 toString() 的隐式编码逻辑 - 若使用 Spring @Async，可通过自定义
AsyncUncaughtExceptionHandler拦截未捕获异常，并对 message 做标准化处理后再交由日志框架
日志框架与控制台输出强制指定 UTF-8
即使异常 message 本身是 UTF-8 字符串，若日志框架或终端未按 UTF-8 渲染，仍会显示为乱码：
- Logback：在
logback.xml的 appender 中添加<encoder><charset>UTF-8</charset></encoder> - Log4j2：配置
PatternLayout charset="UTF-8" - Windows 控制台：启动 JVM 时加参数
-Dfile.encoding=UTF-8，并确保 CMD/PowerShell 已执行chcp 65001 - Docker 容器：基础镜像中设置环境变量
ENV LANG=C.UTF-8，避免 Alpine 默认使用 C locale
避免跨线程传递原始异常对象引发隐式序列化乱码
某些场景下，异常对象会被放入队列、通过 RPC 传递或存入 ThreadLocal —— 若涉及序列化（如 Java RMI、.NET Remoting），默认机制可能丢失编码上下文：
- 禁止直接序列化 Exception 实例用于跨进程通信；改用结构化错误码 + UTF-8 编码的 message 字段（如 JSON 对象
{"code":"AUTH_FAIL","msg":"令牌已过期"}） - 若必须传递异常，重写
writeObject方法，确保getMessage()以 UTF-8 字节数组形式写入，反序列化时用相同方式还原 - ThreadLocal 存储异常时，只存 message 字符串（已标准化为 UTF-8），不存整个 Exception 对象
