根本原因是事件数据在序列化、传输、反序列化全链路中编码不一致，须确保字符串源头→序列化→传递→反序列化→使用全程统一utf-8，禁用隐式转换与双重编码。
多语言系统切换时，自定义事件传递的 payload 数据发生乱码，根本原因不是语言切换本身，而是事件数据在序列化、传输、反序列化过程中编码不一致。关键在于确保“字符串源头→序列化→跨上下文传递→反序列化→使用”全链路统一 UTF-8，且不引入隐式编码转换。
确认 payload 字符串的原始编码
所有参与事件的数据（尤其是用户输入、接口返回、配置项等）必须以 UTF-8 字节流形式进入 payload。避免在构造 payload 前就用错误编码读取文件或数据库字段：
- 若从文件加载多语言文案，确保 lang/zh-cn.php、lang/en-us.php 等文件保存为 UTF-8 无 BOM（VS Code 右下角编码栏手动转存）
- 若从数据库读取多语言字段，连接层必须启用 utf8mb4：MySQL JDBC URL 加
?useUnicode=true&characterEncoding=utf8mb4；PHP PDO 设置PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4" - 前端 JS 中通过
JSON.stringify()打包 payload 时，浏览器自动按 UTF-16 处理字符串，但最终 JSON 文本仍为 UTF-8 编码字节流——只要后续不被错误解码，不会出问题
规范事件总线/消息通道的传输协议
事件总线（如 Vue 的 $emit、React 的自定义事件、微前端通信、WebSocket 或消息队列）本身不处理字符编码，但中间环节可能破坏字节完整性：
- 使用
CustomEvent时，payload 直接传对象，不涉及编码转换：new CustomEvent('lang-change', { detail: { title: '产品介绍' } })—— 安全 - 若通过 postMessage 跨 iframe 传递，
data参数支持任意结构，无需手动 encodeURI 或 escape，直接传对象即可 - 若走 HTTP 接口中转事件（如通知其他服务语言已切换），请求头必须声明：
Content-Type: application/json; charset=utf-8；响应头同理 - 禁用任何对 payload 字符串做
encodeURI/encodeURIComponent后再 JSON.stringify 的操作——这会双重编码，导致接收方解析失败
接收端严格按 UTF-8 解析并校验
事件监听器拿到 payload 后，不假设编码，不尝试自动检测，而是信任来源并统一按 UTF-8 处理：
- 后端 Node.js 接收 JSON 请求体时，确保 body-parser 中间件配置
encoding: 'utf8'；Express 默认已支持 - Java Spring Boot 控制器方法参数加
@RequestBody即可，前提是全局配置了spring.http.encoding.charset=UTF-8 - 前端 JS 接收到事件 detail 后，直接使用，无需
decodeURIComponent或unescape—— 这些只用于 URI 组件，不是 JSON 数据 - 如需日志记录 payload，用
console.log(JSON.stringify(payload, null, 2))，而非拼接字符串，避免控制台环境干扰显示
规避常见“伪乱码”陷阱
有些报错看似乱码，实为其他问题被误判：
- 错误提示
Invalid string length或Unexpected token：大概率是 payload 中混入了不可见控制字符（如 BOM、零宽空格），用payloadStr.replace(/[\u200B-\u200D\uFEFF]/g, '')清理 - 中文显示为
\u4f60\u597d：这是正常 Unicode 转义，说明 JSON 解析成功，只是没被渲染为字符——检查是否误用了JSON.stringify两次 - Vue 模板中插值显示为方块或问号：检查浏览器页面 meta 是否缺失
<meta charset="utf-8">，或服务器响应头未设Content-Type: text/html; charset=utf-8
