InputStreamReader本身不截断，只按指定编码（如UTF-8）正确解码字节流为含代理对的String；真正导致Surrogate Pair截断的是String.length()或substring()等基于char的操作，应改用codePointCount()和offsetByCodePoints()等码点级方法安全处理。
InputStreamReader 本身不负责“截断”，它只做解码——把字节流按指定编码转成字符流。所谓“Surrogate Pair 截断问题”，其实发生在后续对 String 的操作中（比如 substring），而不是 InputStreamReader 的解码阶段。
InputStreamReader 正确解码替代对
只要指定了正确的编码（如 UTF-8 或 UTF-16），InputStreamReader 就能完整、准确地将包含 Emoji、韩文扩展区字符等需要代理对表示的 Unicode 码点，还原为合法的 Java String。
- 输入是 UTF-8 字节流（如文件或网络响应）→ InputStreamReader 使用 "UTF-8" 构造 → 内部 StreamDecoder 会识别多字节序列，正确组合出 BMP 外的码点，并在 String 中以一对 char（高代理 + 低代理）存储
- 输入是 UTF-16 字节流（较少见）→ 指定 "UTF-16" → 同样能识别并保留代理对结构
- 错误做法：不指定编码，用平台默认（如 Windows 上的 GBK）→ 遇到 UTF-8 编码的 Emoji 字节，直接解码失败，产生 或乱码，根本不会进入代理对处理环节
真正出问题的地方：String.length() 和 substring()
InputStreamReader 解出来的 String 是“干净”的，但开发者常误用 String 的传统方法，导致在业务逻辑中意外切开代理对：
通过 `dcc-mcp-cli` 命令行工具控制实时 DCC 主机（Maya、Blender、Houdini、Photoshop、3ds Max 以及自定义的 Studio 工具）。 针对 ClawHub、OpenClaw、Cursor、Claude 和支持 shell 的 Agent 主机：验证网关健康状态、列出已注册的 DCC 实例、搜索工具、检查 Schema、调用工具——全程无需直接编写或发送 MCP 请求。 若系统中未安装 `dcc-mcp-cli`，需先征得用户同意，再从 GitHub
-
str.length()返回的是 char 数量，不是字符数。一个 ? 占 2 个 char，但只算 1 个字符 -
str.substring(0, n)按 char 索引截取，若 n 落在某个代理对的中间（比如第 99 个 char 是高代理，第 100 个是低代理，而你截到 99），结果末尾就只剩孤立的 high surrogate - 这种字符串写入数据库、渲染到前端或序列化时，可能显示为 、乱码，甚至触发某些校验异常
安全截断 Unicode 字符的推荐方式
避免靠 char 索引硬切，改用基于码点（Code Point）的操作：
立即学习“Java免费学习笔记（深入）”；
- 用
str.codePointCount(0, str.length())获取真实字符数 - 用
str.offsetByCodePoints(0, targetLength)计算截断位置对应的 char 索引（自动跳过代理对边界） - 再调用
substring(0, safeIndex) - 更稳妥：用
str.codePoints().limit(n).collect(StringBuilder::new, (b, cp) -> b.appendCodePoint(cp), (a, b) -> a.append(b)).toString()（Java 8+ 流式处理）
补充：BOM 和编码探测的影响
如果源数据带 UTF-8 BOM（EF BB BF），InputStreamReader 不会自动跳过它。虽然 UTF-8 BOM 本身不影响解码，但若未处理，BOM 会被当作三个无效字符读入 String 开头，干扰 length 和 codePointCount 计算。
- 建议在创建 InputStreamReader 前，先检测并跳过 BOM（尤其读取用户上传文件时）
- 可借助
Files.newBufferedReader(path, StandardCharsets.UTF_8)，它内部已处理常见 BOM
