chcp 65001 仅作用于 Windows 控制台窗口层，不影响 JVM 内部编码；Java 输出中文乱码需同时满足：控制台代码页为 65001、JVM 启动参数 -Dfile.encoding=UTF-8、源文件以 UTF-8 编码保存。
chcp 65001 在 Windows 控制台里到底管不管用
管用，但只管「控制台窗口自己」这一层，不管 Java 进程的编码逻辑。很多人执行了 chcp 65001 看到命令行提示变成「活动代码页：65001」就以为万事大吉，结果 System.out.println("中文") 还是显示为 ??? —— 因为 JVM 启动时已经按系统默认代码页（通常是 936）读取了控制台句柄，chcp 并不会重置 JVM 内部的字符流编码。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须在启动 Java 程序前执行
chcp 65001，且不能在 IDE 内置终端里随便敲一下就完事；要确认当前 cmd/powershell 窗口确实是这个代码页（可用chcp不带参数验证） - 如果用的是 PowerShell，
chcp有时会被绕过，优先用传统 cmd 启动 - 某些旧版 JDK（如 8u202 之前）对 UTF-8 控制台支持不完整，即使代码页正确，
System.console()仍可能返回 null 或乱码
IDE 的文件编码和控制台编码不是一回事
IntelliJ 或 Eclipse 里把文件编码设成 UTF-8，只影响源码保存和读取，不影响 System.out 输出到控制台时的字节编码方式。真正起作用的是 JVM 启动参数和终端本身的代码页是否对齐。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- IntelliJ：进
Help → Edit Custom VM Options，加一行-Dfile.encoding=UTF-8；再进Settings → Editor → File Encodings，确保三处都设为 UTF-8（Global、Project、Default encoding for properties files） - Eclipse：右键项目 →
Properties → Resource → Text file encoding设为 UTF-8；同时在Run Configurations → Common → Encoding选 UTF-8 - 关键点：IDE 控制台（Console view）底层仍是调用 Windows 控制台 API，所以仍依赖
chcp 65001+ JVM 参数双重生效
Java 9+ 的 Console 类在 Windows 上基本不可靠
System.console() 返回 null 是常态，不是 bug。它只在「真实 tty 终端」下工作，而 Windows GUI 启动的 cmd、IDE 内置终端、WSL 调用方式都不满足条件。别指望靠它做交互式中文输入输出。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 替代方案用
Scanner+System.in，但必须显式指定编码：new Scanner(System.in, "UTF-8") - 如果要用
System.out输出中文，确保启动命令里带上-Dconsole.encoding=UTF-8（部分 JDK 支持）或更通用的-Dfile.encoding=UTF-8 - 避免在 Windows 上测试
Console.readLine()，它大概率直接抛NullPointerException
最简验证流程：绕过 IDE 直接跑 jar
很多乱码问题其实卡在 IDE 的封装层里。用最原始的方式验证，能快速定位是环境问题还是代码问题。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
javac -encoding UTF-8 Hello.java编译（注意必须加参数） - 生成 jar 后，在干净的 cmd 窗口里执行：
chcp 65001 && java -Dfile.encoding=UTF-8 -jar hello.jar - 如果这时还乱码，八成是 JDK 版本太老（如 JDK 8u181 以下），或者系统区域设置里「Beta: Use Unicode UTF-8…」被勾选又没重启——这个选项会破坏传统 Win32 控制台 API 行为
Windows 控制台乱码的本质，是三个编码层没对齐：源文件保存编码、JVM 字符串处理编码、控制台显示编码。少对一环，就显示为 或 ???。别迷信某个开关能一键解决，得一层层确认。
