Build Output 里突然冒出一串 编译错误、警告、插件日志全变成天书这是 IntelliJ IDEA 用户最常见也最容易被误判的问题之一。很多人第一反应是项目源码坏了其实大多数时候文件本身没坏坏的是“字节到字符”的解码链路。IDEA 的 Build Output 不是简单的文本框它背后连着 javac、Maven、Gradle、Kotlin 编译器、测试框架和插件进程每个进程都可能按不同编码往外吐字节而 IDEA 控制台又按自己的编码去读。中间只要有一层对不上就会出现编译乱码。这篇内容适合刚装 IDEA 的新手也适合被 Windows 代码页、JDK 默认字符集、CI 日志乱码折腾过的老手。我会按现象拆解、定位思路、配置步骤、完整实操和排查表来讲重点放在可复现、可落地的配置上不讲虚的。1. 先弄明白Build Output 里的“”到底从哪来1.1 编译输出链路谁在写字节谁在解码Build Output 本质上是 IDEA 把外部进程的输出捕获后显示到界面的一个控制台。编译一个 Java 项目时通常不是 IDEA 自己逐字读取源码而是调用 javac、Maven、Gradle、Kotlin 编译器或注解处理器。这些工具在运行时会向标准输出和标准错误流写字节。注意它们写的是字节不是字符串。字节本身没有“中文”或“英文”的属性只有用具体字符集解码之后才会变成人能读懂的文字。问题就出在这里javac 读取源文件时会按照-encoding参数指定的字符集去解析。如果源文件是 UTF-8而 javac 默认按 GBK 读取中文字符串和注释就可能变成乱码甚至编译失败。但另一条路径是 javac 自己输出诊断信息比如“错误: 找不到符号”。javac 输出的诊断信息编码通常受 JVM 默认字符集、系统区域设置和启动参数影响。如果 javac 在中文 Windows 上按 GBK 输出诊断信息而 IDEA 的控制台按 UTF-8 解码那么本来正常的中文错误提示就会变成 。Maven 和 Gradle 又多了一层。Maven 自己会输出构建日志Gradle 会启动 daemon 进程。它们的 JVM 参数、编码设置、插件版本不同输出编码也可能不同。IDEA 捕获这些输出时如果按项目编码去解就可能出现“源码没乱、编译结果没乱只有 Build Output 乱”的怪现象。所以排查时不能只盯着源文件编码必须把“写字节的进程”和“读字节的控制台”分开看。我一般把这条链路拆成四段源文件编码、编译器读取源码的编码、编译器进程输出诊断信息的编码、IDEA 控制台解码显示编码。四段都一致Build Output 才稳定。只要有一段是 GBK另一段是 UTF-8就有概率看到 。这也是为什么有的人改了 File Encodings 就好了有的人改完还是乱因为改的只是其中一段。1.2 “”和普通乱码的区别很多人把所有乱码都叫乱码但从字符层面看 和“锟斤拷”不是一回事。 是 Unicode 里的替换字符码点是 UFFFD通常表示“解码器遇到了无法识别的字节序列”。当 IDEA 控制台按 UTF-8 去解一段根本不是 UTF-8 的字节时非法字节就被替换成 连续出现就变成 。你复制这些 到别处它仍然是 因为原始字节信息已经在解码时丢掉了。“锟斤拷”则常见于 UTF-8 字节被 GBK 解码然后又用 GBK 编码保存再被 UTF-8 解码之类的情况。它看起来像汉字但完全不是原意。还有一种“口口口”或方框是字体缺失不是编码错误复制出来可能是正常汉字。区别方法很简单把乱码复制到支持十六进制查看的编辑器里看码点。如果全是 UFFFD说明解码失败如果是正常汉字但显示成方块说明字体或字形问题如果是“锟斤拷”这类古怪汉字说明发生了多次错误转码。这个判断很重要因为处理方式不同。UFFFD 更适合从字节流和进程编码入手方框更适合换字体锟斤拷更适合检查文件保存编码和历史转码操作。Build Output 里最常见的是 UFFFD因为 IDEA 捕获外部进程输出时经常直接按一种编码解码解不出来就替换。你看到的 越多说明编码错配越严重但源码本身不一定坏。1.3 三类高频触发场景Windows 代码页、JDK 默认字符集、构建工具编码第一类高频场景是 Windows 中文系统的代码页。传统中文 Windows 的控制台代码页是 936也就是 GBK。Java 进程在未指定file.encoding时可能采用系统默认字符集。JDK 17 及以前file.encoding在 Windows 上常跟系统区域走JDK 18 以后默认 UTF-8但很多老项目、老依赖、老脚本仍然按 GBK 写日志。IDEA 如果按 UTF-8 解 GBK 输出就会出 。第二类是 JDK 默认字符集变化。JDK 18 起file.encoding默认值变成 UTF-8这对新项目很友好但会让一些依赖默认字符集为 GBK 的老程序出现行为差异。比如读取一个 GBK 编码的配置文件以前能读现在可能读成乱码。Build Output 里如果出现“文件编码不可映射字符”之类提示往往就是源文件、编译参数和 JDK 默认值三者不一致。第三类是构建工具自身的编码配置。Maven 的project.build.sourceEncoding不设插件可能按平台默认编码处理资源文件Gradle 的compileJava.options.encoding不设javac 可能按系统默认编码读源码。IDEA 的 Build Output 又会把 Maven、Gradle 进程的输出当作外部日志捕获。只要 Maven 输出 GBK、Gradle 输出 UTF-8、IDEA 控制台再按项目编码解就会出现同一次构建里一部分日志正常、一部分日志乱码的奇景。2. 定位思路不动配置先把乱码来源缩小到一层2.1 先看乱码发生在哪个窗口IDEA 里有好几个容易混淆的窗口Build Output、Run 控制台、Terminal、Maven 工具窗口、Gradle 工具窗口、Services 窗口。它们的编码策略并不完全一样。Build Output 显示的是构建过程的输出Run 控制台显示的是程序运行输出Terminal 是你本机 shell 的窗口Maven/Gradle 工具窗口可能走自己的进程和日志解析。先确认乱码只出现在 Build Output还是所有窗口都乱能快速缩小范围。如果只有 Build Output 乱Run 控制台正常那大概率是编译器或构建工具进程输出编码与 IDEA 构建控制台解码不一致。如果 Run 控制台也乱程序里的System.out.println中文也乱那要检查运行配置的 VM options、程序自身的编码和终端字体。如果 Terminal 也乱那更可能是系统代码页或 shell 编码。如果 Maven 工具窗口乱、Build Output 正常则重点看 Maven Runner 的 VM options。我习惯先开一个最小工程再分别触发三种输出故意写一个编译错误看 javac 诊断信息运行一个打印中文的 main 看运行输出在 Terminal 里执行chcp看当前代码页。三个结果一对比基本就知道是构建进程、运行进程还是终端的问题。别一上来就改全局编码改多了反而难回滚。2.2 用最小工程和命令行对照定位编码问题最有效的方法是“命令行对照”。在 IDEA 里新建一个最简单的 Java 工程源文件保存为 UTF-8写一个中文类名或中文字符串再故意制造一个编译错误。然后分别用 IDEA Build 和命令行 javac 编译同一个文件观察输出差异。命令行可以用javac -encoding UTF-8 编码测试.java如果命令行输出正常中文IDEA Build Output 乱码说明源文件和 javac 读取编码没问题问题在 IDEA 捕获输出的环节。如果命令行也乱说明 javac 所在环境的默认字符集或终端代码页有问题。再试一次带-J-Dfile.encodingUTF-8javac -J-Dfile.encodingUTF-8 -encoding UTF-8 编码测试.java对比两次输出就能判断file.encoding是否影响诊断信息编码。Maven 和 Gradle 也可以用同样思路在 Terminal 里执行mvn -version、gradle -version看中文输出是否正常。命令行正常而 IDEA 乱优先改 IDEA 的 Runner 编码命令行也乱优先改系统代码页或 JVM 参数。这个办法看起来笨但能避免瞎猜。我遇到过一种情况IDEA 里 Gradle Build Output 全是 但 Terminal 里执行gradle build完全正常。最后发现是 IDEA 的 Gradle Runner 使用了不同的 JVM那个 JVM 的file.encoding是 GBK。命令行用的是另一套 JDK默认 UTF-8。所以对照时一定要注意 IDEA 和 Terminal 是否用了同一个 JDK。2.3 检查系统与 IDEA 的编码基线chcp、file.encoding、File Encodings先把三个基线值记录下来。Windows 下在 cmd 执行chcp常见结果是 936 或 65001。936 是 GBK65001 是 UTF-8。在 PowerShell 里可以看[Console]::OutputEncoding和$OutputEncoding。然后看 IDEA 的 Help Edit Custom VM Options检查有没有-Dfile.encoding。再打开 Settings Editor File Encodings看 Global Encoding、Project Encoding 和 properties 编码。最后看构建工具的配置比如 Maven 的pom.xml、Gradle 的gradle.properties。这三个基线不要求完全一致但要知道它们分别是什么。比如系统代码页是 936IDEA VM options 是 UTF-8项目编码是 UTF-8Maven 没设编码那 Maven 进程很可能按系统默认 GBK 输出IDEA 按 UTF-8 解就会乱。这时要么把 Maven Runner 的 JVM 也设成 UTF-8要么把 Maven 输出编码和 IDEA 控制台解码调成一致。通常统一到 UTF-8 更符合现代项目习惯。检查时还要注意 IDEA 是用哪个 JDK 启动的。Help About 里能看到 Runtime version。Build Tools Maven Runner 里能看到 Maven 使用的 JDK。Gradle 里能看到 Gradle JVM。不同 JDK 版本的默认字符集可能不同尤其是 JDK 17 和 JDK 18 之间。把这几处记下来后面改配置才有方向。3. IDEA 全局与项目编码的正确配置步骤3.1 File Encodings 三组关键选项怎么设打开 Settings Editor File Encodings。这里有三组关键选项Global Encoding、Project Encoding、Default encoding for properties files。现代项目建议 Global Encoding 和 Project Encoding 都设成 UTF-8。properties 文件历史上按 ISO-8859-1 读取Java 9 以后虽然支持 UTF-8但很多工具仍按传统方式处理。IDEA 里可以设置 properties 默认编码为 UTF-8并勾选“Transparent native-to-ASCII conversion”这样中文会以转义形式保存兼容性更好。这里有个坑不要轻易勾选“自动转换”或批量转换整个项目。IDEA 右下角状态栏可以查看当前文件编码如果某个文件显示 GBK而实际内容是 UTF-8可以点进去选择“Convert”而不是“Reload”。Reload 只是换一种方式读不改变字节Convert 会按你选的编码重新解释并保存。选错 Convert 会把好文件弄坏。批量操作前先提交 Git 或用本地历史IDEA 的 Local History 能救回来但别赌。另外BOM 要谨慎。UTF-8 with BOM 在 Windows 记事本里常见但 javac 对 BOM 的处理在旧版本里可能报“非法字符”。如果项目统一 UTF-8 without BOM就在 IDEA 里设置保存时不加 BOM。团队协作时最好写进.editorconfig避免有人用不同编辑器保存出 BOM。3.2 自定义 VM options 里 file.encoding 要不要加IDEA 本身也是一个 Java 程序。Help Edit Custom VM Options 会打开idea64.exe.vmoptions或对应文件。可以加入-Dfile.encodingUTF-8这会影响 IDEA 启动进程的默认字符集。对于 JDK 17 及以前很多 Build Output 乱码问题加这一行就能缓解。JDK 18 以后默认已经是 UTF-8但加上也无妨前提是不要和项目实际编码冲突。千万不要写成-Dfile.encodingGBK除非你明确知道整个链路都是 GBK否则只会把问题从 Build Output 转移到 Run 控制台或文件读写。改完 vmoptions 要重启 IDEA。重启后再看 Help About 或运行配置里确认file.encoding是否生效。有些机器上 IDEA 可能被系统环境变量JAVA_TOOL_OPTIONS覆盖终端里执行echo %JAVA_TOOL_OPTIONS%可以检查。若有全局-Dfile.encodingGBK它会干扰 IDEA 和构建工具需要清理或改成 UTF-8。还有一点file.encoding不等于sun.jnu.encoding。后者影响文件名编码在跨平台处理中文路径时也会出问题。一般不需要单独设但如果你在 Windows 上编译 Linux 风格路径或处理中文文件名可以观察一下。普通 Build Output 乱码优先处理file.encoding。3.3 编译器 Additional command line parameters 的写法打开 Settings Build, Execution, Deployment Compiler Java Compiler。在“Additional command line parameters”里可以填-encoding utf-8这个参数会传给 javac用来指定读取源文件的编码。它不直接控制 javac 诊断输出编码但能解决“源文件中文被读错导致编译错误乱码或报错信息里中文标识符乱码”的问题。如果你的项目源码是 UTF-8这个参数应该加上。如果是 GBK 老项目就写-encoding gbk但更推荐把项目逐步迁到 UTF-8。Kotlin 项目还要看 Settings Build, Execution, Deployment Compiler Kotlin Compiler。Kotlin 源文件通常要求 UTF-8Kotlin 编译器对编码的处理和 Java 不完全一样。Gradle Kotlin DSL 里也可以设置kotlinOptions。如果 Build Output 里 Kotlin 编译错误乱码先确认文件编码再看 Kotlin 编译器版本和 JVM 参数。注意这个参数只对 IDEA 的 Java Compiler 生效。如果你用 Maven 或 Gradle 接管构建IDEA 可能不直接调用 javac而是调用 Maven/Gradle 的编译任务。这时改 Java Compiler 参数可能没用必须改 Maven 或 Gradle 的编译配置。很多人在这里白折腾就是因为没分清“IDEA 自己编译”和“构建工具编译”。3.4 Maven/Gradle Runner 的编码参数Maven Runner 在 Settings Build, Execution, Deployment Build Tools Maven Runner。VM Options 可以填-Dfile.encodingUTF-8同时在pom.xml里设置properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /properties如果用了 maven-compiler-plugin也可以显式配置plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.13.0/version configuration encodingUTF-8/encoding /configuration /pluginGradle 项目在gradle.properties里加org.gradle.jvmargs-Dfile.encodingUTF-8在build.gradle里加tasks.withType(JavaCompile).configureEach { options.encoding UTF-8 }如果项目是 Kotlin再加tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).configureEach { kotlinOptions { freeCompilerArgs [-Xjvm-defaultall] } }Kotlin 编码一般不需要单独设但 JVM 参数要统一。Gradle daemon 可能缓存旧参数改完最好执行./gradlew --stop再重新构建。Maven 没有 daemon但 IDEA 里的 Maven Runner 可能持有旧进程重启 IDEA 或刷新 Maven 项目更稳妥。4. 实操从乱码到清晰输出的完整修复流程4.1 第一步统一源文件与构建声明编码先确定项目统一编码。新项目直接 UTF-8老项目如果历史文件是 GBK不要一次性全转容易产生大量无意义 diff。可以新建一个分支只改编码相关配置再逐步转换核心文件。检查源文件编码时IDEA 右下角状态栏最方便。批量查看可以用命令行工具比如 Linux/macOS 下file -I src/main/java/com/example/Demo.javaWindows 下可以用 PowerShell 读前几个字节判断 BOM。如果文件开头是EF BB BF说明有 UTF-8 BOM。Java 源文件通常建议无 BOM。然后确认pom.xml、build.gradle、.editorconfig里的编码声明。构建声明不统一后面怎么调 IDEA 都可能反复。还要检查资源文件。很多 Build Output 乱码其实不是 Java 源码而是资源过滤时出错。Maven 的 resources 插件、Gradle 的 processResources 任务都可能按默认编码读取.properties、.xml、.json。如果资源文件是 UTF-8而插件按 GBK 读输出日志就会乱。可以在 Maven resources 插件里设置 encodingGradle 里设置processResources { filteringCharset UTF-8 }。这一步的目标是让“项目声明编码”和“文件实际编码”一致。最怕的是文件实际是 GBK但.editorconfig写 UTF-8IDEA 按 UTF-8 打开显示乱码构建工具按 UTF-8 读也乱。先修正实际文件再改声明顺序不能反。4.2 第二步把编译器诊断信息切到 UTF-8如果源文件已经统一Build Output 里的诊断信息还乱就要处理进程输出编码。IDEA 层面加-Dfile.encodingUTF-8Maven Runner、Gradle JVM 也加同样参数。然后清理构建缓存Build Rebuild ProjectMaven 执行cleanGradle 执行clean build。如果 Gradle daemon 还在先./gradlew --stop。Windows 下还可以在 IDEA 的 Terminal 里临时执行chcp 65001再运行命令行构建看输出是否正常。如果chcp 65001后正常而 IDEA Build Output 仍乱说明 IDEA 捕获进程时没有继承这个代码页。此时重点改 Runner 的 VM options而不是只改 Terminal。IDEA 的 Build Output 不一定走你当前 Terminal 的代码页。对于 javac 直接编译可以在命令行加javac -J-Dfile.encodingUTF-8 -encoding UTF-8 Demo.java观察诊断信息。如果加-J-Dfile.encodingUTF-8后正常就把这个参数固化到构建脚本或 IDEA Runner 里。Maven 可以用MAVEN_OPTSGradle 可以用GRADLE_OPTS。在 CI 里也建议统一否则本地正常、流水线乱码。4.3 第三步处理 Windows 控制台代码页与字体Windows 控制台的编码问题很顽固。cmd 默认代码页可能是 936PowerShell 的$OutputEncoding也可能不是 UTF-8。可以在系统设置里开启“Beta: 使用 Unicode UTF-8 提供全球语言支持”但这会影响所有非 Unicode 程序老软件可能显示乱码或无法运行。我不建议一上来就开这个全局开关先用局部方案。局部方案是在 IDEA 的 Terminal 设置里指定 shell 和环境变量。Settings Tools Terminal可以设置 Environment variables比如LANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-8Windows 下还可以在启动脚本里执行chcp 65001。但要注意chcp 65001只影响当前控制台会话不影响已经在运行的 IDEA 进程。Build Output 是 IDEA 捕获的输出不一定受 Terminal 代码页影响。所以这一步更多是解决 Terminal 里的乱码不是 Build Output。字体问题也要排除。IDEA 控制台字体如果选了一个不含中文字形的英文字体中文会显示成方框。Settings Editor Color Scheme Console Font选择支持中文的等宽字体比如 JetBrains Mono 配合中文回退或者更直接的 Microsoft YaHei Mono、Noto Sans Mono CJK。方框不是编码错误换字体即可。区分方法复制乱码到浏览器搜索如果能搜到正常中文就是字体问题。4.4 第四步用一个最小 demo 验证建一个最小 Java 文件名字用中文内容包含中文输出和故意错误public class 编码测试 { public static void main(String[] args) { System.out.println(中文输出测试); int a 这不是整数; } }保存为 UTF-8。在 IDEA 里 Build观察 Build Output。正常的话应该看到类似“不兼容的类型: java.lang.String 无法转换为 int”中文清晰可读。如果还是 就复制 IDEA Build Output 顶部的命令行。IDEA 通常会在输出里显示实际执行命令比如javac -encoding utf-8 ...。把这条命令放到 Terminal 里执行对比输出。如果 Terminal 正常、IDEA 乱检查 IDEA 的 Console 编码和 VM options。如果 Terminal 也乱检查chcp和JAVA_TOOL_OPTIONS。如果命令行正常但 IDEA 仍乱清理 IDEA 缓存File Invalidate Caches / Restart。缓存偶尔会保存旧的输出编码设置。重启后再 Build。验证通过后不要只修一个文件。把配置同步到 Maven/Gradle、运行配置、测试配置。尤其是 JUnit 测试输出很多乱码只在测试失败时出现。测试框架会捕获标准输出和错误输出如果测试任务的 JVM 参数没设 UTF-8失败信息仍可能乱。Gradle 的test任务也要设置systemProperty file.encoding, UTF-8。4.5 第五步不同构建工具的配置模板Maven 项目可以用以下模板properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding maven.compiler.encodingUTF-8/maven.compiler.encoding /properties build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.13.0/version configuration encodingUTF-8/encoding /configuration /plugin /plugins /buildGradle Groovy DSL 模板tasks.withType(JavaCompile).configureEach { options.encoding UTF-8 } tasks.withType(Test).configureEach { systemProperty file.encoding, UTF-8 } tasks.withType(Javadoc).configureEach { options.encoding UTF-8 }Gradle Kotlin DSL 模板tasks.withTypeJavaCompile().configureEach { options.encoding UTF-8 } tasks.withTypeTest().configureEach { systemProperty(file.encoding, UTF-8) }如果还在用 Ant可以在javac任务里设置encodingUTF-8并在java任务里加 JVM 参数。Ant 现在新项目少但老系统维护时经常遇到。模板不是越多越好核心是三个地方编译任务编码、测试任务编码、运行任务 JVM 编码。三处统一到 UTF-8Build Output 乱码基本就收敛了。5. 常见问题排查速查表与避坑经验5.1 常见现象与对应处理表现象常见原因优先处理Build Output 中 javac 错误中文乱码javac 诊断输出编码与 IDEA 控制台解码不一致IDEA VM options 加-Dfile.encodingUTF-8Maven 构建日志乱码Maven 进程按 GBK 输出IDEA 按 UTF-8 解Maven Runner VM Options 加-Dfile.encodingUTF-8pom 设 sourceEncodingGradle 构建日志乱码Gradle daemon 的 JVM 编码不一致org.gradle.jvmargs-Dfile.encodingUTF-8停止 daemon 后重建Run 控制台中文乱码程序运行 JVM 默认字符集不对Run Configuration VM options 加-Dfile.encodingUTF-8Terminal 中文乱码cmd/PowerShell 代码页或字体问题chcp 65001设置 Terminal 编码和字体测试失败信息乱码Test 任务 JVM 编码未设Gradle/Maven 测试任务设置file.encoding和 encodingTomcat 日志乱码容器日志输出编码与 IDEA 控制台不一致logging.properties 设置 UTF-8启动参数设置 file.encodingCI 日志乱码流水线环境 LANG/LC_ALL 未设CI 脚本设置LANGzh_CN.UTF-8JAVA_TOOL_OPTIONS 统一这个表不是让你一次全改而是按现象定位。改完一项就重启或重建观察变化。编码问题最怕一次改十个地方最后不知道哪个生效。5.2 那些看起来像乱码但不是乱码的情况有些“乱码”根本不是编码问题。比如日志里出现[0m、[32m这种 ANSI 颜色转义序列如果 IDEA 没启用 ANSI 高亮就会显示成奇怪字符。可以在 Grep Console 或 IDEA 设置里开启 ANSI 支持。再比如 Base64 解码后的二进制内容、压缩日志、加密 payload显示出来当然不是可读文本。Build Output 里如果插件打印了压缩数据看到乱码很正常。还有一种是 Unicode 控制字符或零宽字符。源码里如果混入零宽空格、BOM、方向控制符javac 可能报“非法字符”IDEA 显示成小点或问号。这种不是编码错配而是文件里有不可见字符。可以用“Show Whitespaces”或十六进制编辑器查看。删除后再编译即可。字体缺字也很常见。某些符号如 emoji、数学符号、CJK 扩展汉字如果控制台字体不支持会显示成方框。复制到浏览器能正常显示就说明不是编码问题。Build Output 里主要看中文和英文字体影响较小但如果用了特殊符号也可能误判。5.3 多人协作与 CI 环境中的编码一致性团队协作时编码问题往往不是一个人能解决的。建议在项目根目录放.editorconfigroot true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.{java,kt,xml,properties,gradle}] charset utf-8再加.gitattributes防止 Windows 和 Linux 换行符与编码混乱* textauto eollf *.java text eollf *.xml text eollf *.properties text eollfCI 里显式设置环境变量export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 export JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8如果 CI 用 Windows 节点还要注意 PowerShell 的输出编码。可以在脚本开头执行[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8这些设置不保证所有工具都听话但能大幅降低“本地正常、流水线乱码”的概率。尤其是 Maven 和 Gradle环境变量对它们的影响比 IDEA 设置更直接。5.4 我踩过的坑改完还乱码的三个隐藏原因第一个隐藏原因是只改了 IDEA 的 File Encodings没改构建工具 Runner。File Encodings 影响 IDEA 读写文件的默认编码但 Maven、Gradle 是独立 JVM 进程它们有自己的file.encoding。如果 Runner 没设Maven 仍可能按系统 GBK 输出。解决方法是同时改 Maven Runner VM Options 和 Gradle JVM args。第二个隐藏原因是源文件带 BOM。UTF-8 BOM 在 IDEA 里看起来正常但 javac 某些版本会报“非法字符: \ufeff”。Build Output 里可能显示成奇怪的乱码或错误提示。检查文件开头是否有EF BB BF有就去掉。批量去 BOM 要小心别把正常字节删了。第三个隐藏原因是 Gradle daemon 或 IDEA 缓存。改完参数后Gradle daemon 可能还在用旧 JVM 参数IDEA 也可能缓存旧的控制台编码。执行./gradlew --stop再 File Invalidate Caches / Restart。重启后重新构建。我遇到过改完gradle.properties后仍然乱码最后停掉 daemon 才生效。还有一个常见坑是依赖源码 jar 的编码。有些第三方库源码 jar 不是 UTF-8IDEA 反编译或跳转源码时显示乱码但这不影响 Build Output。如果 Build Output 里出现某依赖的注解处理器日志乱码要看那个插件的编码设置而不是项目源码。遇到这种先搜插件文档别硬改项目全局配置。最后再分享一个小技巧遇到 Build Output 乱码时先不要急着改配置把 IDEA 输出顶部的命令行复制出来在 Terminal 里原样执行。命令行输出正常就查 IDEA 控制台解码命令行也乱就查 JVM 和系统代码页。这个对照法能省下大量来回改配置的时间。编码问题本质上就是字节和字符的映射找到是哪一层映射错了问题就解决了一半。