Gradle编译Java项目中文乱码本质是编码链断裂，需分层对齐：源文件必须为UTF-8（IDEA右下角确认并Reload as UTF-8）；build.gradle中配置JavaCompile.encoding="UTF-8"；JavaExec任务中设systemProperty("file.encoding","UTF-8")及jvmArgs含sun.stdout/err.encoding；辅以GRADLE_OPTS或gradle.properties全局配置，并每次clean后构建。
Gradle 编译 Java 项目时出现中文乱码，本质是编码链断裂：源文件、编译器读取、JVM 运行时、控制台输出这四个环节中任一环节编码不一致，就会导致乱码。Windows 系统尤其明显，因为默认系统编码常为 GBK，而现代项目普遍用 UTF-8。关键不是“加一个参数就完事”，而是分层对齐。
确保源文件本身是 UTF-8 编码
这是前提，否则后续所有配置都是徒劳：
- 在 IntelliJ IDEA 右下角检查当前文件编码，显示“UTF-8”才可靠；若显示“GBK”或“windows-1252”，需右键 → Reload as UTF-8（非 Convert），再保存
- 避免用 Windows 记事本直接编辑 Java 文件——它默认保存为 ANSI（即 GBK），极易埋坑
- 推荐用 VS Code 或 IDEA 编辑，并统一设置默认编码为 UTF-8（含 BOM 关闭）
配置 Gradle 编译阶段使用 UTF-8
让 javac 以 UTF-8 解析源码，防止编译时就把中文转成乱码字节写入 class 文件：
- 在 build.gradle.kts 中添加：
tasks.withType<JavaCompile> {
options.encoding = "UTF-8"
}
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 如果是 Groovy 版 build.gradle，写法为：
tasks.withType(JavaCompile) {
options.encoding = "UTF-8"
} - 该配置影响
javac -encoding UTF-8行为，必须存在；仅靠-Dfile.encoding无法替代
配置运行时 JVM 和控制台输出编码
即使 class 文件正确，运行时若 JVM 默认编码或终端输出编码不匹配，依然会乱码：
- 对 JavaExec 类型任务（如 application:run、test、自定义 main 启动）显式传参：
tasks.withType<JavaExec> {
systemProperty("file.encoding", "UTF-8")
jvmArgs = ["-Dsun.stdout.encoding=UTF-8", "-Dsun.stderr.encoding=UTF-8"]
}
- 其中
-Dsun.stdout.encoding和-Dsun.stderr.encoding是解决控制台输出乱码的关键，比单纯-Dfile.encoding更直接有效 - 若用 IDEA 运行，还需在 Run → Edit Configurations → Configuration → VM Options 中补上：
-Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8
全局生效的辅助手段（可选）
避免每个项目重复配置：
- 设置环境变量 GRADLE_OPTS=-Dfile.encoding=UTF-8，对所有命令行 gradle 执行生效
- 在 gradle.properties 中追加：
org.gradle.jvmargs=-Dfile.encoding=UTF-8 - IDEA 全局设置：Settings → Build → Gradle → Gradle JVM Options 填入 -Dfile.encoding=UTF-8
不复杂但容易忽略：每改一处，记得 clean 一下再构建（./gradlew clean compileJava），否则旧 class 文件可能缓存乱码结果。
