charsetencoder.encode() 返回 bytebuffer 是因需支持分批处理与状态维护，其 position/limit 机制便于流式编码；须调用 flip() 后读取，转 byte[] 应用 flip() 后 array().clone()。
CharsetEncoder.encode() 为什么返回 ByteBuffer 而不是 byte[]
因为编码过程可能需要多次调用、分批处理，且涉及状态（比如 UTF-8 中未完成的多字节序列），ByteBuffer 提供了位置（position）、限制（limit）和剩余空间（remaining()）等控制能力，方便流式编码或复用缓冲区。
常见错误是直接调用 encode() 后忽略 buffer.flip() 就去读内容，结果读到空或乱码：
- 必须在
encode()后调用buffer.flip()才能从头读取已编码数据 - 若想转成
byte[]，应使用buffer.flip(); buffer.array().clone()（注意array()可能包含未使用前缀，clone()+limit()更安全） - 不要复用同一个
ByteBuffer给多个encode()调用，除非手动clear()—— 但更推荐每次新建或用allocate()重置
CharsetDecoder.decode() 报 MalformedInputException 或 UnmappableCharacterException 怎么办
这两个异常分别对应“字节序列不符合该字符集语法”（如 UTF-8 中出现 0xFF 0xFE）和“字节合法但映射不到 Unicode 码点”（如 GBK 中遇到一个只在 GB18030 里定义的汉字）。
真实场景中，你往往不想中断解析，而是希望跳过或替换：
立即学习“Java免费学习笔记（深入）”；
- 用
decoder.onMalformedInput(CodingErrorAction.REPLACE)和onUnmappableCharacter(CodingErrorAction.REPLACE)设置容错策略 -
REPLACE默认插入''（U+FFFD），也可自定义：用decoder.replaceWith("□") - 注意：一旦设为
REPLACE，异常就不会抛出，调试时容易掩盖真实问题；上线前建议先用REPORT模式跑一批样本确认坏数据比例
UTF-8 编码器对 BOM 的处理逻辑很反直觉
Charset.forName("UTF-8") 返回的 Charset 实例默认**不写 BOM**，且解码时也**不识别 BOM** —— 即使输入字节以 0xEF 0xBB 0xBF 开头，decode() 也会把它当普通字符解成 '\uFEFF'（零宽无间断空格）。
这意味着：
- 用
Files.write(path, str.getBytes(StandardCharsets.UTF_8))写出的文件一定没有 BOM - 如果读一个带 BOM 的 UTF-8 文件，
Files.readString(path, StandardCharsets.UTF_8)会把 BOM 当作开头字符，导致字符串首部多出一个不可见字符 - 真要兼容 BOM，得自己检测前三个字节，再用
Arrays.copyOfRange(bytes, 3, bytes.length)截掉后解码
不同 Charset 实例的 Encoder/Decoder 不可跨线程共享
CharsetEncoder 和 CharsetDecoder 都维护内部状态（如 surrogate 配对状态、部分字节缓存），JDK 明确标注它们不是线程安全的。
实际踩坑最多的是单例缓存：
- 别写
static final CharsetEncoder UTF8_ENCODER = StandardCharsets.UTF_8.newEncoder() - 每次编码都应调用
charset.newEncoder()，或用ThreadLocal缓存（但要注意 GC 和内存泄漏） - 尤其在 Netty 或 NIO channel 场景下，一个
CharsetEncoder被多个write()并发调用，大概率出现IllegalStateException: Current state = FLUSHED
最易被忽略的一点：编码器的 reset() 方法不是“清空缓冲”，而是“结束当前编码流程并准备新输入”——它不会丢弃已输出的字节，也不会重置 ByteBuffer 的 position；真正清理缓冲区的动作，得靠你自己管理 ByteBuffer 的 clear() 或重新分配。
