经常有朋友问我IDEA 的 Run 控制台里输出中文全是乱码看着头疼网上搜索的解决方案五花八门有的让改这个有的让改那个搞了一圈还是没好。我自己入行那会儿也被这个问题折腾过后来把背后的原理摸清楚了发现大部分乱码场景就那么几个原因对症下药几分钟就能解决。这篇就完整梳理一遍从根因到实操把每一个可能踩的坑都摊开来讲。先说清楚一件事IDEA 的 Run 编译输出台显示中文乱码绝不是什么玄学问题也不一定是 IDEA 本身坏了。它本质上就是“编码不一致”。你写的代码文件是一种编码IDEA 解释这个文件用的是另一种编码JVM 运行时输出的字节流又被控制台用第三种编码去解码只要其中任何一个环节对不上中文就会出现乱码。明白了这个链路你再去排查方向就非常明确。这个内容适合所有用 IntelliJ IDEA 做 Java 开发的朋友尤其是刚接触 Java 没多久的初学者以及被 Windows 中文环境折磨了无数遍的老开发。不管你是用 Maven、Gradle 还是直接跑 main 方法只要碰到 Run 控制台中文乱码下面的方法都能帮上忙。1. 乱码出现的完整链路与根因分析1.1 编译输出台的乱码到底从哪来我习惯把整个过程拆成三段来看。第一段是源文件的写入与读取也就是 .java 文件本身是用什么编码保存的IDEA 在打开这个文件的时候又默认用什么编码去读。第二段是 JVM 在运行时的默认字符集也就是 Java 程序内部处理字符串时用的编码方式这会影响System.out.println(中文)这种语句输出到标准输出流时字节到底是什么。第三段是 IntelliJ IDEA 的控制台窗口它拿到标准输出流里的字节后又是按什么编码去渲染成你看到的文字。这三段只要编码一致一切正常。一旦不一致比如源文件是 UTF-8但 IDEA 项目编码被设置成了 GBK那注释和字符串字面量在读取阶段就已经被解错了后面怎么调都没用。又比如源文件没问题IDEA 读得也对但 JVM 的默认字符集是 GBK控制台却按 UTF-8 解码那么程序里正确输出的中文到了终端就又变成了乱码。这种“三段式”排查思路我强烈建议你先记住。因为很多时候不是你改得不对而是你只改了其中一段另外两段还在互相对不上。网上很多教程只让你改一个地方说改了就好了但换一台电脑、换一个项目就不管用了原因就是它只解决了某一个特定环境下的某一个环节。1.2 Windows 平台为什么最容易踩坑如果你用的是 Windows乱码概率会明显高于 macOS 和 Linux这是因为 Windows 中文版系统的默认编码从来就不是 UTF-8。老一代的中文 Windows 系统无论是 XP、Win7 还是 Win10 早期版本系统区域设置里的默认 ANSI 编码都是 GBK也就是 GB2312 的扩展。Java 在跨平台的时候如果没有显式指定字符集JVM 会从操作系统获取默认字符集。这就导致环境变量和系统字符集是 GBK 的时候IDEA 里的各种默认值可能会跟着变成 GBK。更麻烦的是IDEA 自身是基于 Java 写的JetBrains 在较新版本里默认把 IDE 的默认编码调整成了 UTF-8但很多老项目、或者从 Eclipse 迁移过来的项目源文件可能是 GBK 编码保存的。一边是 IDE 默认 UTF-8一边是项目文件 GBK冲突就来了。你要是在老系统上跑再叠加控制台渲染的字符集问题那真是三层加成乱到没法看。macOS 和 Linux 没这么多事因为它们系统层面默认就是 UTF-8所以这些平台上的 IDEA 基本上不用怎么配置输出中文就正常。这也是为什么很多教程里说“我什么都没改为什么就是好的” — 平台环境不一样结论就完全不一样。1.3 快速判断你的乱码属于哪个环节在动手改配置之前你可以先做一个最简单的判断。在 IDEA 里打开一个包含中文的 .java 文件看一下编辑器里的中文是否正常显示。如果编辑器里中文就是乱码那问题出在“源文件编码 vs IDEA 读取编码”这一段直接去看项目编码和文件编码设置。如果编辑器里中文正常但 Run 控制台里乱码那问题出在“JVM 输出编码 vs 控制台解码”这一段去改 VM 参数和控制台编码。如果两者都正常只有编译日志、Maven/test 输出里的中文乱码那问题又不一样得去看构建工具自身的编码配置。这个判断方法能帮你省掉大量瞎试的时间。我见过很多朋友一上来就改 VM options改了半天没效果最后发现是文件编码错了。也见过反过来文件编码改了一轮结果根本问题在控制台解码。先定位再动手一条路走到底才高效。2. 三种必会的编码配置方式2.1 全局编码、项目编码与文件编码的关系IDEA 里的编码设置分三层理解了它们的优先级你才不会被选项搞晕。第一层是全局默认编码在Settings/Preferences | Editor | File Encodings里设置。这里有一个Global Encoding官方说明是“新建文件时默认使用的编码”但实际上它也会作为 IDEA 在没有找到项目配置时的兜底编码。第二层是项目编码同样在这个界面里有一个Project Encoding。这一项会把整个项目所有文件的默认读取编码都圈定为你选择的那个值。一般来说Project Encoding会覆盖Global Encoding对你的项目生效。第三层是单个文件的编码在 IDEA 右下角的状态栏会直接显示当前打开文件的编码比如UTF-8或GBK你可以点击它来为单独某一个文件指定编码。这一层优先级最高可以覆盖项目编码的设置。实际操作中我建议新建项目一律统一到 UTF-8。Global 和 Project 都选 UTF-8右下角的文件编码也就跟着是 UTF-8。如果你拿到一个别人的项目源文件是 GBK也尽量通过File | File Properties | File Encoding把单个文件或者整个目录转成 UTF-8再做统一。2.2 修改 IDEA 的全局和项目编码打开 IDEA 的Settings界面macOS 上是Preferences在左侧搜索框里输入File Encodings。你会看到如下几个关键位置Global Encoding选 UTF-8Project Encoding选 UTF-8Default encoding for properties files选 UTF-8并且勾上Transparent native-to-ascii conversion很多教程只说选前两项properties文件那一项不怎么提。但你知道吗Spring Boot 项目里的application.properties如果不勾选Transparent native-to-ascii conversion一旦中文写入后保存IDEA 可能会给你存成\uXXXX的转义序列或者直接乱码。这个选项的意思是透明地把本地编码转换成 ascii 存储同时显示时给你还原成中文对国际化资源文件特别友好。设置完以后点击ApplyIDEA 会提示你是否要把文件转为指定编码如果你确认项目里的文件已经保存成 UTF-8 了就可以直接选择“转换为 UTF-8”。如果之前文件被写乱了这里可以尝试用File | File Properties | File Encoding里的“Reload in”重新用正确编码加载。2.3 在 Run/Debug 配置里指定 VM 选项这一步解决的是 JVM 层面的默认字符集问题。在 IDEA 里打开Run/Debug Configurations可以在工具栏左上角的下拉菜单里选Edit Configurations...。找到你运行的入口类比如带main方法的那个类在VM options一栏里填入-Dfile.encodingUTF-8这样 JVM 在启动时file.encoding这个系统属性就会被显式指定为 UTF-8Java 的System.getProperty(file.encoding)也会返回 UTF-8标准输入输出流的默认编码也会跟着变成 UTF-8。这里要注意一点网上很多地方说要设-Dconsole.encodingUTF-8这个参数实际上在某些 JDK 版本里并不生效就是个伪参数。你只需要设置file.encoding就够了它才是真正控制 JVM 内部字符编码的核心属性。填完VM options之后一定要点击Apply保存然后再重新运行你的程序。第一次改完以后如果不重启进程当前运行中的 JVM 进程还是老的编码改动不会生效。这个细节很容易被忽视我看过好几个人改了参数以后忘记重启就直接点运行然后跑来问为什么没用。2.4 新版 IDEA 的 Console 编码设置除了上面说的文件编码和 VM 参数IDEA 还有一个单独针对控制台输出的编码设置位置在Settings | Editor | General | Console。这里有一个Default encoding选项默认值是“使用系统默认”在 Windows 上就会跟随系统使用 GBK在 macOS 上跟随系统使用 UTF-8。你可以直接把这个也改成 UTF-8。改完之后控制台窗口在解码标准输出流时就会优先按照 UTF-8 去处理。这样和我们在 VM options 里设置的-Dfile.encodingUTF-8形成配对输出是 UTF-8解码也是 UTF-8中文就不会乱。总结一下这三处是核心配置项位置建议值Global EncodingSettingsFile EncodingsProject EncodingSettingsFile EncodingsProperties 文件编码SettingsFile EncodingsVM optionsRun/Debug Configuration-Dfile.encodingUTF-8Console 默认编码SettingsEditor三处全部对齐以后绝大多数中文乱码问题都可以解决。如果设置完还乱那就进入下一层的排查。3. 代码、日志与构建工具里的隐藏雷区3.1 你的 Java 代码里可能自己写了 System.out有一种情况特别容易让人怀疑人生配置全改好了IDEA 控制台中文肉眼可见地正常了但过了几天你写了一个新模块print 中文又是乱码。这时候你要看一下代码里是不是在启动阶段写死了默认编码。有些朋友会在代码里调用类似System.setOut(new PrintStream(System.out, true, GBK))的语句或者用了第三方的日志框架在配置里指定了ConsoleAppender的编码为 GBK。这种代码层面写死的编码优先级非常高会绕过 JVM 启动参数直接把输出流改成别的编码。遇到这种情况最好的做法是在代码里搜索setOut、setErr、new PrintStream、OutputStreamWriter这些关键词看看有没有显式指定字符集的地方。如果有统一改成 UTF-8或者干脆不要指定让它继承 JVM 的file.encoding。还有一个点Spring Boot 2.x 以上的版本里如果你自定义了Logback或Log4j2的配置文件里面可能有一个encoder的配置块指定了charset属性。例如常见的logback-spring.xml里会写charsetUTF-8/charset如果你的日志配置没写系统会默认走平台编码Windows 上就是 GBK输出到控制台时中文就乱了。所以检查你自己的日志框架配置文件把输出编码显式指定成 UTF-8也是一个必须做的动作。3.2 Maven 和 Gradle 的编码问题很多人的 Run 控制台里不仅是程序输出乱码连BUILD SUCCESS前面的日志有时候都会乱。比如 Maven 编译时输出的[INFO] 中文提示这种乱码跟 JVM 的file.encoding关系不大而是 Maven 自身在读取 pom 文件时使用了错误的文件编码。解决方案是在pom.xml里显式声明项目编码properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /properties这两行放在项目properties节点下Maven 就会用 UTF-8 来读取源文件和生成报告编译时传给 javac 的-encoding参数也会带上 UTF-8。如果你的项目没有声明那 Maven 在 Windows 上可能按 GBK 处理这样源码里的中文注释和字符串一旦有非 ASCII 字符编译时就会被错误的编码解读轻则乱码重则编译报错。Gradle 项目也有类似的问题。在build.gradle里可以加tasks.withType(JavaCompile) { options.encoding UTF-8 }3.3 系统环境变量 JAVA_TOOL_OPTIONS 的影响这里有个非常隐蔽的坑。Windows 上如果你配置过JAVA_TOOL_OPTIONS环境变量并且里面写入了-Dfile.encodingGBK或类似的参数那 JVM 启动时就会自动读取这个环境变量里的参数然后悄悄覆盖你在 IDEA 的 VM options 里指定的 UTF-8 设置。这个变量的优先级很高因为它是 JVM 在启动早期读取的而且会输出一行类似Picked up JAVA_TOOL_OPTIONS: -Dfile.encodingGBK的提示。如果你之前为了折腾什么工具设过这个变量那它很可能就是你乱码问题反复出现的罪魁祸首。检查方法很简单在命令行里输入echo %JAVA_TOOL_OPTIONS%如果有输出内容那就去 Windows 的系统环境变量里把它删掉或者改成 UTF-8。macOS/Linux 下则是查看 shell 配置文件里有没有 export JAVA_TOOL_OPTIONS。这种环境变量导致的编码问题光在 IDEA 里改设置是没用的因为 JVM 启动时读环境变量的优先级高于 IDE 传入的 VM 参数。我当时排查过一个同事的问题他在 IDEA 配置全对的情况下依然乱码最后发现就是JAVA_TOOL_OPTIONS-Dfile.encodingGBK在作怪删掉之后立竿见影。3.4 代码文件保存时被转成了 GBK还有一种情况比较少见但确实存在。IDEA 默认的项目编码是 UTF-8但如果你的项目是直接从网上下载的源码包或者从别的 IDE 导入的文件可能以 GBK 编码保存。IDEA 打开时检测到文件编码和项目编码不一致通常右下角会有提示但如果你没注意直接点了“确定”跳过了文件就会被以错误的编码加载。这时候你在代码里看到的中文可能长这样浣犲ソ或者锟斤拷。这就是典型的 UTF-8 内容被按 GBK 解码或者反过来解码导致的现象。锟斤拷在中文编程圈里特别有名是 UTF-8 的替换字符UFFFD也就是 被编码成 GBK 以后出现的固定乱码组合。看到这三个字基本就说明文件编码和解码错位了。解决办法是用 IDEA 的File | File Properties | File Encoding选择“Reload in”并指定实际编码先把文件显示正确然后再用“Convert to”转成目标编码。如果你的文件已经保存成了乱码那就需要先手动恢复或从版本控制里重新拉取干净的文件来转。顺带说一句在团队开发里统一文件编码真的很重要。如果你用 UTF-8 保存同事用 GBK 保存git 提交后哪怕内容一样二进制 diff 都会被计算成整个文件都变了。很多团队里莫名其妙的 git 冲突源头往往就是这种编码不统一。项目根目录放一个.editorconfig文件把charset utf-8写进去能省很多事。4. 实操演示一次完整的乱码解决流程4.1 先建一个标准测试用例为了验证你的配置是否生效建议你先写一个最小可复现的测试类。我自己常用的测试代码是这样public class EncodingTest { public static void main(String[] args) { System.out.println(你好世界); System.out.println(系统默认编码: System.getProperty(file.encoding)); System.out.println(控制台编码: System.getProperty(console.encoding, 未设置)); } }这段代码运行后如果你第一行中文能正常显示同时第二行输出UTF-8那就证明你的 JVM 启动参数已经生效了。如果第一行乱码但第二行也显示UTF-8说明输出字节是 UTF-8 的问题在控制台解码那一端去调 Console 编码。如果第一行正常但第二行显示GBK说明 VM options 没生效检查一下你改的是不是当前这个运行配置。在这个最小测试用例的基础上再逐步引入真实项目的代码定位起来就非常清晰。我平时排查同事的乱码问题第一步永远是这个测试类不接受一上来就猜。4.2 按步骤执行修复并验证假设我的环境是 Windows 11 IntelliJ IDEA 2024.1 JDK 17项目之前是 Eclipse 迁移过来的源文件是 GBK那我的修复顺序是第一步先把项目里所有源文件转成 UTF-8。在项目根目录右键选File Properties相关操作或者通过File | File Properties | File Encoding把目录编码改为 UTF-8选择“Convert”转换。转换完以后IDEA 会重写磁盘上的文件中文内容依然不变但存储编码会变成 UTF-8。记得转换前先提交一遍 git防止转换过程出现意外方便回退。第二步设置Settings | File Encodings把 Global、Project、properties 全部设为 UTF-8。第三步打开Run/Debug Configurations在 VM options 里写入-Dfile.encodingUTF-8。第四步在Settings | Editor | General | Console里把默认编码改成 UTF-8。第五步清理构建。菜单栏选Build | Rebuild Project或者干脆把target目录删了重新编译。有时候 javac 已经编译出了带错误编码的 class 文件不重编译的话运行可能还是在跑上一次的旧 class。第六步重新运行测试类验证中文正常。这套流程我用过很多次不仅在自己机器上验证过在帮朋友远程排查时也屡试不爽。只要你的项目不是那种“配置文件把编码写死到骨子里”的极端情况这六步做完基本都能解决。4.3 修改 IDEA 安装目录的 vmoptions 文件还有一种全局生效的方法就是修改 IDEA 自身的 JVM 启动参数而不是某个项目的运行配置。在 IDEA 安装目录的bin文件夹下有一个idea64.exe.vmoptions文件Windows或者 macOS 上位于/Applications/IntelliJ IDEA.app/Contents/bin下的idea.vmoptions。这文件是给 IDEA 这个应用本身用的 JVM 参数。如果你在运行任何项目时连 IDEA 自身的界面、弹窗、日志都出现中文乱码那就需要修改这个文件。在文件末尾加上一行-Dfile.encodingUTF-8然后重启 IDEA。但我必须说清楚这个参数只影响 IDEA 应用本身不影响你运行项目时 JVM 进程的编码。很多新手会搞混这两者以为改了 IDEA 的 vmoptions 就能解决 Run 控制台乱码其实作用和单项目的 VM options 不是一回事。如果你确实是通过Help | Edit Custom VM Options修改的那它解决的是 IDE 自身的问题。项目运行时的进程编码仍然由你项目运行配置里的 VM options 或环境变量决定。5. 日志框架、SSH 终端等扩展场景5.1 Logback 与 Log4j2 的控制台编码配置前面简单提过日志框架这里展开讲。使用 Logback 时控制台输出的编码配置在appender里面。一个标准的consoleappender 长这样appender nameSTDOUT classch.qos.logback.core.ConsoleAppender encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appender注意charsetUTF-8/charset这一行。如果没有写Logback 会默认按System.out所用的编码来输出。在 Windows 上如果 IDEA 的file.encoding是 UTF-8那 Logback 通常就会用 UTF-8 输出但为了防止被环境变量或某些人为设置干扰显式指定 charset 永远是更稳妥的做法。Log4j2 类似在log4j2.xml的Consoleappender 里有一个PatternLayout标签一般写作Console nameConsole targetSYSTEM_OUT PatternLayout pattern%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n charsetUTF-8/ /Console如果你用的是 Spring Boot 的默认日志配置它其实已经内置了 UTF-8 的 charset。但不少自定义配置是从网上抄的旧模板里面没有 charset 这一行出问题也就不奇怪了。5.2 IDEA 自带终端和 SSH 终端的编码在一些实际项目场景里你不是直接在 Run 窗口里看日志而是在 IDEA 的 Terminal 窗口里执行mvn spring-boot:run或者npm run build。这种场景下输出走的不再是 IDEA 控制台的解码逻辑而是终端模拟器的解码逻辑。IDEA 的 Terminal 默认使用的编码跟系统有关。Windows 下如果系统的代码页是 936GBK终端就可能按 GBK 解码。如果你运行的程序输出 UTF-8 字节终端按 GBK 解码中文自然乱码。这种情况下可以尝试在Settings | Tools | Terminal里把Default encoding设置为 UTF-8。有些新版本也支持设置环境变量你可以在 shell 的启动脚本里执行chcp 65001把 Windows 控制台代码页切到 UTF-8。如果你是在 IDEA 里通过 SSH 远程连接 Linux 服务器看日志那终端编码的影响更大。服务器端日志通常是 UTF-8但本地 Windows 终端如果以 GBK 解码就会乱码。最简单的办法仍然是统一用 UTF-8 作为两端编码并且把 SSH 终端的字符集也设置为 UTF-8。5.3 前端 npm run build 的中文乱码看到这里你可能要问了标题说的是“IDEA Run 编译输出台”但如果我用 IDEA 跑前端项目比如npm run build终端输出的中文也乱码这个怎么处理其实这跟前端构建工具没关系主要还是终端解码和进程输出编码不一致。Windows 下运行npm run build如果 webpack 或 vite 输出了中文字符比如报错信息里的中文终端按 GBK 解码时也容易乱码。解决办法有两个方向一个是在系统层面执行chcp 65001把代码页改成 UTF-8另一个是修改前端的构建配置把日志输出强制为 UTF-8。但说实话前端构建工具在 Windows 下的中文乱码根子往往在 Node.js 的进程输出编码上。Node.js 在 Windows 下默认输出到 stdout 时如果环境变量里没有显式设置使用的编码表现和 Java 不同更复杂一些。遇到这种场景我一般直接建议先用chcp 65001切换代码页再把终端的默认编码设为 UTF-8能覆盖大多数情况。5.4 一次运行多个模块时项目之间的编码差异如果你在用多模块 Maven 项目比如一个父 pom 下面挂了好几个子模块有的模块是用旧的老项目迁移过来的 GBK 编码有的模块是新建的 UTF-8 编码这时只改父 pom 的project.build.sourceEncoding会在模块级别产生不一致。Maven 的子 pom 可以覆盖父 pom 的属性所以你要去检查每一个子模块的 pom 里是否写了类似project.build.sourceEncodingGBK/project.build.sourceEncoding的覆盖。我之前帮人排查过一个微服务项目A 模块跑起来中文正常B 模块跑起来中文乱码最后发现就是 B 模块自己的 pom 里写了 GBK。团队协作中这种情况特别常见因为有历史包袱的项目往往习惯性沿用老编码。建议的做法是全局搜一遍所有 pom 文件里的sourceEncoding统一修改为 UTF-8再顺手把 IDE 的编码设置也同步改掉。这样整个项目跑起来控制台就不会因为模块间编码不统一而出现时好时坏的问题。6. 常见问题速查与独家避坑经验6.1 问题排查速查表现象优先级最高的解决方案备选方案编辑器里源代码中文就是乱码用 File Encoding 的 Reload in 指定正确编码重新加载文件检查文件保存编码是否被改过必要时从版本控制重新拉取源代码显示正常但 Run 控制台中文乱码在运行配置 VM options 加 -Dfile.encodingUTF-8改 Console 编码为 UTF-8改了 VM options 但仍乱码检查 JAVA_TOOL_OPTIONS 环境变量检查运行配置是否正确选中当前入口类Maven 构建日志中文乱码pom.xml 添加 sourceEncoding 为 UTF-8Rebuild Project 强制重新编译日志框架输出的中文乱码在 logback/log4j2 配置里显式指定 charsetUTF-8检查 System.setOut 之类的代码IDEA 自身界面中文乱码修改 idea64.exe.vmoptions 加 -Dfile.encodingUTF-8检查系统区域设置尝试 Windows 的 UTF-8 Beta 选项IDEA Terminal 输出中文乱码SettingsTools文件转完编码后 git diff 整个文件都变了确认是不是源文件编码不统一导致用 .editorconfig 统一团队编码6.2 最常见的一个误区为什么我改了没效果乱码问题最坑的一点是“改完了立刻点运行”。IDEA 的运行配置更改有时候需要重启进程甚至需要重建项目。尤其是当你改动的是pom.xml里的 sourceEncoding或者改动的是文件编码时如果不做一次Rebuild ProjectIDEA 会继续使用之前编译的 class 文件。class 文件里字符串已经按旧的编码方式被写入字节码了运行时你再怎么改 VM options 也没用因为字节码里的这批字符串一旦形成解码就已经出错了。所以我的习惯是改配置、做 Clean、做 Rebuild、再运行。这四步缺一不可。很多人问为什么同样的配置在别人那有效到自己这没效果最大的可能性就是你项目里还有老的 class 文件在“捣乱”。6.3 推荐团队使用的统一方案个人机器上折腾完了还要考虑团队协作。我推荐在你的项目根目录加一个.editorconfig文件内容可以很简单root true [*] charset utf-8 end_of_line lf insert_final_newline true这样任何一个开发者用 IDEA、VS Code 或者其他主流编辑器打开项目都会自动遵循 UTF-8 编码和 LF 换行。这能避免很多因为环境差异导致的乱码排查。再加上所有运行配置统一在启动类里设置-Dfile.encodingUTF-8或者通过环境变量、脚本统一设置那整个团队的开发体验就会非常稳定。另外如果你的项目是 Spring Boot强烈建议在application.yml或application.properties里也留意一下日志编码设置。有时候你配置了 logback但配置文件和 application 里的属性冲突也会出现奇怪现象。保持日志配置简单、可读、显式指定编码是长期维护的最优策略。6.4 解不开的乱码问题还可以从 JDK 版本找原因最后再补充一个不太常见但很值得排查的点JDK 版本。Java 18 之前JVM 的默认字符集是 “根据运行环境决定” 的所以它的默认值会随系统而变。但从 Java 18 开始JEP 400 把 UTF-8 设置为 Java 的默认字符集。也就是说如果你用 JDK 18 或更高版本即使不显式设置-Dfile.encodingUTF-8JVM 默认也会按 UTF-8 处理。这算是一个从根本上缓解中文乱码问题的大改动。如果你还在用 JDK 8 或 JDK 11并且恰好用的是 Windows那你的乱码风险就是比 JDK 17 要高。反正我个人的建议是如果你的项目允许升级 JDK尽量升到 17 或 21光是编码这块就能省下不少折腾时间。如果在 JDK 8 上跑老项目文件编码、JVM 编码和控制台编码确实得一项一项核对清楚。别嫌麻烦这一套流程你走过一次之后碰到任何乱码问题就都有底了。说到底中文乱码在 Java 开发里就是编码错位不是致命问题但确实磨人。掌握上面这一套从原理到操作的方法至少能帮你省出半天到一天的时间。以后再碰到同事说 IDEA 又乱码了你也可以直接把这篇思路讲给他听让他少走点弯路。