生产环境乱码本质是编码链上“字节来源”与“解释规则”不匹配，排查需沿数据流逐层确认：先锁定乱码最早出现位置，再检查JVM与系统默认编码一致性，重点盯住HTTP请求体、数据库读写、文件IO三类高频断点，最后用最小证据快速验证核心假设。
生产环境乱码不是随机发生的，而是编码链上某一处“解释规则”和“字节来源”对不上。排查关键不是猜，是顺着数据流逐层确认：字节从哪来、被谁读、用什么解、传给谁、怎么显示。
第一步：锁定乱码最早出现的位置
同一段中文，在不同环节表现不同，说明问题出在某个转换节点。比如：
- 数据库里查出来是正常中文 → 说明写入和存储没问题
- 接口返回 JSON 里变成“”或“?” → 问题大概率在 Java 后端序列化或响应写出阶段
- 浏览器页面显示“”但源码里是 UTF-8 字节 → 浏览器没按 UTF-8 解，可能是响应头缺失 Content-Type: text/html;charset=UTF-8
- 日志文件里全是问号 → 检查 Logback 或 Log4j 的 appender 配置是否指定了 charset="UTF-8"
第二步：检查 JVM 和系统默认编码是否一致
Java 很多 API（如 new String(byte[])、FileReader、System.out.println）会悄悄使用 file.encoding 值。这个值不等于你写的代码里写的 UTF-8，而取决于启动时的环境。
- 运行 java -XshowSettings:properties -version，看输出里的 file.encoding 是不是 UTF-8
- 检查启动脚本是否显式加了 -Dfile.encoding=UTF-8；没加的话，Linux 容器里常 fallback 到 ISO-8859-1
- 确认容器或服务器 locale 是否生效：locale 命令输出中 LANG 和 LC_ALL 应含 UTF-8，否则 JVM 可能取空值
第三步：重点盯住三类高频断点
90% 的生产乱码集中在这三个地方：
- HTTP 请求体：前端 POST 表单或 JSON，后端没调 request.setCharacterEncoding("UTF-8")（且必须在 getParameter() 前）
- 数据库读写：JDBC URL 缺少 useUnicode=true&characterEncoding=UTF-8，或 MySQL 服务端/库/表字符集不是 utf8mb4
- 文件 IO：用 FileReader（无参构造）读文件 → 它用的是系统默认编码，不是文件真实编码；应改用 InputStreamReader(new FileInputStream(...), StandardCharsets.UTF_8)
第四步：用最小证据快速验证
别改一堆配置再重启，先做三件事验证核心假设：
- 在代码里加一行：System.out.println(StandardCharsets.UTF_8.encode("中文").array().length); —— 输出 3，说明 JVM 内部 UTF-8 正常
- curl 接口，用 -v 看响应头是否有 Content-Type: application/json;charset=UTF-8
- 直接连数据库执行：SELECT CHARSET('中文'), COLLATION('中文'); —— 确认服务端默认编码支持中文
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
