MalformedInputException 是 CharsetDecoder 在严格模式下遇到非法字节序列（如 UTF-8 解码 GBK 数据）时抛出的异常，默认策略为 REPORT，需显式设 REPLACE 或 IGNORE 来避免中断。
为什么 MalformedInputException 总在 CharsetDecoder 里冒出来
这个异常不是你读错了文件，而是 NIO 的解码器在严格模式下撞上了非法字节序列——比如用 UTF-8 去解码一段实际是 GBK 编码的二进制数据，或者文件开头混入了损坏的 BOM 或截断字节。MalformedInputException 是 java.nio.charset 层抛的，和 String.getBytes() 这种“宽松转换”不兼容，它默认拒绝任何无法映射的输入。
- 常见错误现象：
java.nio.charset.MalformedInputException: Input length = 1，尤其在读取日志、配置文件、HTTP 响应体时高频出现 - 根本原因：
CharsetDecoder的onMalformedInput(CodingErrorAction.REPORT)（默认行为）遇到无法解析的字节就直接中断 - 别指望
new String(bytes, "UTF-8")能兜底——它底层用的是宽松解码策略，而ByteBuffer → CharBuffer流程走的是严格解码路径
怎么让 CharsetDecoder 忍一忍，别一错就崩
关键不是绕过异常，而是显式控制解码策略。NIO 提供了三种错误处理动作，最常用的是替换非法字节为 （U+FFFD），而不是炸掉整个流程。
- 设置
decoder.onMalformedInput(CodingErrorAction.REPLACE)，同时配decoder.replaceWith("") - 如果想保留原始字节痕迹，可用
CodingErrorAction.IGNORE（跳过非法字节），但会导致文本错位，慎用 - 示例片段：
Charset utf8 = StandardCharsets.UTF_8; CharsetDecoder decoder = utf8.newDecoder() .onMalformedInput(CodingErrorAction.REPLACE) .replaceWith("\uFFFD"); CharBuffer result = decoder.decode(byteBuffer); - 注意：必须在调用
decode()前设置策略，之后再设无效
Files.readAllLines() 和 BufferedReader 为啥不报这个错
因为它们默认用了宽松的字符集处理逻辑——Files.readAllLines(path, charset) 内部会把异常转成 UncheckedIOException 包装，而 BufferedReader 在构造时若传入 Charset，底层用的是 InputStreamReader，其行为由 JVM 实现决定，默认容忍部分错误（比如忽略单个非法 UTF-8 字节）。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 这不是“更健壮”，而是抽象层级不同：高层 API 隐藏了 NIO 解码器的严格性，代价是可能静默丢数据
- 如果你需要精确控制每个字节如何映射（比如协议解析、安全审计），就必须直面
CharsetDecoder策略 - 性能影响很小：替换策略比 REPORT 多一次字符拷贝，但远低于 IO 开销
跨平台读文件时最容易漏掉的编码陷阱
Windows 记事本保存的 “UTF-8” 文件其实常带 BOM（EF BB BF），而 Java 的 StandardCharsets.UTF_8 解码器不自动跳过 BOM；Linux/macOS 下生成的纯 UTF-8 又可能被 Windows 工具误读成 GBK —— 这些都会触发 MalformedInputException。
立即学习“Java免费学习笔记（深入）”；
- 不要硬写
StandardCharsets.UTF_8，先探测：用juniversalchardet或ICU4J做编码猜测（仅限可信来源） - 对已知含 BOM 的场景，手动 strip：检查前 3 字节是否为
EF BB BF，是则 slice 掉再 decode - 生产环境别依赖用户声明的编码名，HTTP
Content-Type或文件头信息可能撒谎
真正麻烦的不是解码失败本身，而是错误发生在异步 pipeline 里——比如 Netty 的 StringDecoder 或 Kafka 消费者反序列化阶段，堆栈里看不到你自己的 decode() 调用。这时候得提前在 channel handler 或 deserializer 中注入自定义 CharsetDecoder 并统一设好 REPLACE 策略。
