chcp 65001 仅设置控制台代码页为 UTF-8，Java 编译需 -encoding UTF-8、运行需 -Dfile.encoding=UTF-8，且源文件须存为 UTF-8 无 BOM；三者缺一不可，否则必然乱码。
chcp 65001 后 Java 输出还是乱码？别急，这不是编码没切对
根本原因是 Windows 控制台（cmd/powershell）的 chcp 只改了终端的代码页，而 Java 默认用系统默认编码（通常是 GBK）读取源文件、输出字符串——两者不一致时，控制台按 UTF-8 解码，Java 却按 GBK 编码，结果就是字节错位、显示成方块或问号。
chcp 65001是必须的，但只是第一步；它让控制台能“接收” UTF-8 字节流- Java 编译和运行时仍可能用
GBK处理字符串，尤其当你没指定源文件编码、也没显式设置输出编码时 - IDE（如 IntelliJ）里跑正常，命令行乱码？大概率是 IDE 自动加了
-encoding UTF-8和-Dfile.encoding=UTF-8，而你手动运行时漏了
javac 编译时报 “非法字符：’\ufffd’”？源文件编码没对齐
这个错误说明 javac 读源码时解码失败，把 UTF-8 字节当 GBK 解了。比如中文“你好”在 UTF-8 下是 0xe4 0xbd 0xa0 0xe5 0xa5 0xbd，若用 GBK 解，前两个字节 0xe4 0xbd 在 GBK 中不是合法字符，就变成 \ufffd（替换符）。
- 保存 Java 源文件时，必须用 UTF-8 无 BOM 格式（Notepad++ / VS Code 都可设；记事本默认带 BOM，会额外多出
0xef 0xbb 0xbf，javac不认） - 编译时强制指定源码编码：
javac -encoding UTF-8 Main.java - 如果项目里有中文字符串字面量、注释、甚至类名含中文（不推荐），这步不能省
java 命令运行后中文输出仍是乱码？file.encoding 决定运行时行为
即使源码编译成功，JVM 运行时默认用系统编码（Windows 上是 GBK）处理 System.out.println() 的内容。它把字符串转成字节写入 stdout，而控制台此时是 chcp 65001（UTF-8），自然对不上。
- 必须加 JVM 参数：
java -Dfile.encoding=UTF-8 Main - 注意：
-Dfile.encoding影响字符串到字节的转换，也影响new Scanner(System.in)的输入解码 - 不要只写
-Dfile.encoding=GBK来“迁就”控制台——那等于倒退回旧模式，跨平台时必崩 - PowerShell 用户额外注意：
chcp 65001在 PowerShell 中需配合$OutputEncoding = [System.Text.UTF8Encoding]::new()，否则java输出仍可能被截断或二次乱码
想一劳永逸？别依赖 chcp，改终端或换工具更可靠
靠每次输 chcp 65001 和一堆 JVM 参数，容易漏、难维护，尤其写脚本或 CI 场景下。真正稳定的做法是绕过 cmd 的老旧代码页机制。
- 用 Windows Terminal（微软商店免费下载），默认支持 UTF-8，无需
chcp，java -Dfile.encoding=UTF-8就够 - VS Code 集成终端默认也是 UTF-8，且可配置 Java 扩展自动加参数
- 实在要用 cmd，可在快捷方式目标中加
/k chcp 65001 >nul，但不解决 JVM 编码问题，仍要配-Dfile.encoding - 最隐蔽的坑：某些国产杀毒软件或输入法会 hook 控制台，干扰 UTF-8 输出，表现为偶尔乱码——换终端能快速验证是不是环境干扰
真正卡住人的，往往不是哪个命令没敲对，而是以为改了 chcp 就万事大吉，忽略了 Java 编译、运行、终端三端编码必须严格对齐。少一个环节，就多一个乱码点。
