InputStreamReader 不适合直接处理 WebSocket 文本帧，因其面向连续字节流、无法识别帧边界、不支持掩码解包和分片重组，易导致阻塞、截断或 UTF-8 多字节被拆分而乱码；正确做法是由 WebSocket 框架完成协议解析后，再用 StandardCharsets.UTF_8 显式解码。
InputStreamReader 本身不适用于 WebSocket 文本帧的字节转换场景，它不是为实时、分帧、协议感知的 WebSocket 数据处理设计的。
为什么 InputStreamReader 不适合直接处理 WebSocket 文本帧
WebSocket 文本帧是按 UTF-8 编码的独立数据单元（frame），可能被分片、中间有控制帧、且需严格遵循 RFC 6455 的解包规则。InputStreamReader 是面向流的字符解码器，依赖底层 InputStream 的连续字节供给，无法识别帧边界，也无法处理分片、掩码、opcode 等 WebSocket 协议层信息。直接用它包装 WebSocket 的原始字节流，会导致：
- 读取阻塞或提前截断（因不知道一帧多长）
- 解码失败（未去除掩码、未校验帧头）
- 乱码或异常（跨帧解码、UTF-8 多字节被拆开）
正确的文本帧处理流程（以 Java 常见实现为例）
标准做法是：先由 WebSocket 实现（如 Tyrus、Jetty、Spring WebSocket）完成帧解析和解码，再将已验证的 UTF-8 字节序列转为 String。开发者通常只需处理 String 或 byte[]，无需手动用 InputStreamReader。
- 使用 @OnMessage 方法接收 String 参数 → 框架自动完成 UTF-8 解码
- 若需 byte[]，检查 opcode == TEXT，然后用 new String(bytes, StandardCharsets.UTF_8) 转换
- 自定义解码器（如 Jetty 的
WebSocketListener）中，从Frame提取 payload 后，调用StandardCharsets.UTF_8.decode(ByteBuffer.wrap(payload))
什么情况下可能“看似”用到 InputStreamReader？
极少数边缘场景，比如你把 WebSocket 收到的完整文本帧字节数组（已去掩码、无分片）写入 ByteArrayInputStream，再包装成 InputStreamReader —— 这纯属绕路，等价于 new String(bytes, UTF_8)，且更慢、更易出错。不推荐。
立即学习“Java免费学习笔记（深入）”；
- 仅当已有遗留代码强依赖 Reader 接口时，才做这种临时适配
- 务必确保传入的 ByteArrayInputStream 包含且仅包含一个合法 UTF-8 序列
- 跳过所有 WebSocket 协议解析步骤，意味着你已自行完成帧提取和校验
关键提醒：编码必须明确指定 UTF-8
WebSocket 协议规定文本帧必须是 UTF-8 编码，但 Java 默认平台编码不可靠。无论用 String 构造函数还是 CharsetDecoder，都必须显式指定 StandardCharsets.UTF_8。
- 错误：
new String(bytes)→ 依赖系统默认编码，可能乱码 - 正确：
new String(bytes, StandardCharsets.UTF_8) - 更安全：
StandardCharsets.UTF_8.newDecoder().onMalformedInput(CodingErrorAction.REPORT).decode(ByteBuffer.wrap(bytes))（可捕获非法 UTF-8）
