乱码诊断核心是逆向追踪字节流解码环节：UTF-8中文被GBK误读产生“锟斤拷”，ISO-8859-1读UTF-8出“？”，U+FFFD说明检测到非法序列，“一半正常一半乱码”暴露终端与JVM编码不一致。
识别乱码类型，关键不是“猜字形”，而是逆向追踪字节流在哪个环节被错误解码。Java基础学习阶段，重点掌握三类典型乱码的字节特征和产生路径，就能快速定位问题环节。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
看“锟斤拷”“烫烫烫”这类生僻字组合
这是UTF-8编码的中文被GBK/GB2312强行解码的标志性结果。“中”在UTF-8中是0xE4 0xBD 0xA0三个字节，GBK按两字节一组切分，会得到0xE4BD（对应“锟”）、0xA0E5（对应“斤”）、0xBDA0（对应“拷”）。只要看到连续出现的“锟斤拷”“”“□”，基本可断定：写入是UTF-8，读取用了GBK或系统默认编码。
看“？”“”或空白字符
这类符号多出现在解码时字节序列无法映射到目标字符集的情况：
• 单个“？”常见于ISO-8859-1或ASCII环境下读取UTF-8中文——因为这两个编码不支持中文，遇到不认识的字节就替换成“？”
• “”（Unicode替换符U+FFFD）说明Java已检测到非法字节序列，比如用UTF-8解码一段被截断的GBK字节，或文件开头缺少BOM但内容实际是UTF-8
• 全是空格或长度异常变短，可能是GB2312/GBK写入后用UTF-8读取，导致双字节中文被拆成两个无效单字节，被跳过或替换
看控制台输出是否“一半正常一半乱码”
比如“Hello 世界”，说明前半段ASCII字符（UTF-8与GBK兼容）能正确显示，后半段中文出错——这暴露的是终端或IDE控制台本身的编码设置与JVM解码不一致。
• Windows CMD默认GBK，若JVM用-Dfile.encoding=UTF-8启动，就会出现这种混合乱码
• IntelliJ控制台显示正常但日志文件乱码，说明控制台编码设置对了，但文件写入时没指定Charset，用了JVM默认值
此时不用改代码，先查终端编码（chcp命令）和JVM file.encoding参数是否匹配
