MalformedInputException虽非受检异常，但频发表明编码处理存在隐患，应优先规避而非捕获；需准确识别真实编码、使用容错解码器并配置REPLACE策略，对不可控文本实施多编码fallback，并在日志中记录完整上下文。
MalformedInputException不是受检异常，它不会强制你写try-catch，但频繁出现说明编码处理逻辑有隐患。核心思路不是“捕获它”，而是提前规避或优雅降级。
确认真实编码再读取
别凭经验猜编码。Windows记事本保存的中文文件大概率是GBK，带BOM的UTF-8开头是EF BB BF，纯ASCII内容用ISO-8859-1也能读通。可用这些方式辅助判断：
- Linux/macOS下运行
file -i filename.txt或enca -L zh filename.txt - 用Notepad++或IntelliJ右下角查看当前识别的编码，并切换预览是否乱码
- 对HTTP响应，优先读
Content-Type头里的charset=xxx
用容错解码器代替硬编码Charset
直接调new String(bytes, UTF_8)看似简单，但它走的是宽松路径；而NIO的CharsetDecoder.decode()默认严格校验，一错就崩。正确做法是显式配置容错策略：
- 设置
onMalformedInput(REPLACE)，非法字节替换成（U+FFFD） - 搭配
replaceWith("□")自定义占位符，便于后续人工排查 - 避免用
IGNORE，跳过字节会导致文本偏移、语义错乱
多编码fallback机制
对来源不可控的文本（如用户上传、爬虫抓取、日志归档），单靠一种编码风险高。建议按可信度排序尝试：
立即学习“Java免费学习笔记（深入）”；
- 首选声明编码：HTTP头、XML声明、BOM标识
- 次选UTF-8 → GBK → ISO-8859-1顺序试探，首个不抛
MalformedInputException的即采用 - 每次尝试都记录原始前32字节的十六进制值，方便回溯分析
日志与监控要带上下文
只打印Input length = 1毫无价值。捕获时务必补充关键信息：
- 出问题的文件路径或URL
- 触发异常的字节快照：
Arrays.toString(Arrays.copyOf(bytes, Math.min(32, bytes.length))) - 当前尝试的charset名称
- 是否已 fallback 过，第几次尝试
