异常message乱码根源在于全链路utf-8编码断裂，需确保源头字符串为utf-8、禁用隐式转码、统一日志与传输编码策略，并在接收端强制按utf-8解析。
核心问题不在 Lambda 本身，而在于异常 message 字符串从抛出→捕获→序列化→跨上下文传递→日志/展示的全链路中发生了编码断裂。Lambda 只是执行容器，它不修改字符串编码，但若上游源头或下游消费端未统一 UTF-8，message 中的多语言文本（如“切换失败：参数无效”）就会变成“???”或乱码字符。
确保异常 message 的原始字符串始终为 UTF-8 字节流
所有进入异常构造器的字符串，必须来自 UTF-8 编码的源头：
- 用户输入、配置文件、数据库字段读取后，显式用 UTF-8 解码再组装 message —— 不依赖平台默认编码
- 若从 properties 文件加载错误文案，确保 Messages_zh_CN.properties 等文件保存为 UTF-8 无 BOM（VS Code 右下角点击编码 → “Save with Encoding” → UTF-8）
- 数据库连接 URL 中强制指定字符集，例如 MySQL JDBC：
jdbc:mysql://host/db?useUnicode=true&characterEncoding=utf8mb4
避免在 Lambda 内部对 message 做隐式编码转换
Lambda 表达式中若手动拼接或处理异常 message，极易引入双重编码或误转义：
- 禁用 URLEncoder.encode(msg, "UTF-8") 后再 throw new RuntimeException(...) —— 这会让 message 变成 %E5%88%87%E6%8D%A2%E5%A4%B1%E8%B4%A5，下游 decode 失败即乱码
- 不要用 new String(msg.getBytes("ISO-8859-1"), "UTF-8") 类似逻辑“修复”编码 —— 这是典型补丁式错误，掩盖了源头问题
- 直接使用原始字符串构造异常：
throw new IllegalArgumentException("语言切换失败：" + detail);
统一异常透传与日志落盘的编码策略
当异常跨线程、跨服务或写入日志时，message 易被中间层错误解码：
- 日志框架（Logback / Log4j2）配置中明确声明编码：
... - 若通过 REST API 向监控系统上报异常，请求头必须包含：
Content-Type: application/json; charset=utf-8 - 微服务间用 gRPC 或 Dubbo 时，确保序列化协议（如 Protobuf）不干预字符串字节 —— Protobuf 的 string 字段本质是 UTF-8 编码的 bytes，只要发送方没乱 encode，接收方就不会乱
接收端不做自动编码猜测，只信任并强制按 UTF-8 解析
异常 message 到达前端、运维平台或告警系统后，禁止调用任何“智能检测编码”的工具（如 jschardet、Tika）：
- Java 后端打印日志时，System.out.println(e.getMessage()) 默认走控制台编码 —— 改用 SLF4J + UTF-8 encoder 输出
- 前端 JS 展示错误提示时，直接使用 error.message，不要经过 decodeURIComponent() 或 unescape()
- ELK 日志平台需确认 Logstash input 插件配置 charset => "UTF-8"，且 Kibana 索引模板中字段 mapping 为 "type": "keyword" 或 "text"，不启用 analyzer 干预原始字节
