不推荐通过反射读取 bufferedreader 的 cb 字段，因其是私有实现细节，jdk 9+ 模块封装和 jdk 17+ 强化封装会导致 inaccessibleobjectexception；应改用 ready()、自定义缓冲读取器等公开 api。

不推荐也不建议通过反射读取 BufferedReader 内部的 cb 字符缓冲区。这不是设计意图，且在不同 JDK 版本中该字段名、访问性甚至存在性都可能变化（比如 JDK 9+ 模块系统限制、JDK 17+ 进一步强化封装），极易导致运行时异常或兼容性问题。

为什么不能依赖 cb 字段

BufferedReader 的 cb 是私有实现细节（private char[] cb），属于内部优化机制，官方 API 从未承诺其稳定性。从 JDK 9 开始，java.io 包被置于默认强封装模块下，反射访问非开放字段会触发 InaccessibleObjectException（除非用 --add-opens 手动开包，但这违背可移植原则）。

替代方案：用公开 API 获取缓冲状态

真正需要“知道缓冲了什么”时，应借助标准、稳定的方式：

js2java

JavaScript 到 Java 全栈翻译助手，专为前端开发者学习 Java 或快速实现后端业务逻辑而设计。当用户提到以下场景时必须使用此技能： - "帮我把这段 JS 代码转成 Java" - "用 Java 怎么写这个逻辑" - "我习惯用 JS 写，想翻译成 Java" - "教我 Java，我要写后端接...

下载

• 检查是否 ready()：调用 reader.ready() 判断下一次 read() 是否能立即返回数据（不阻塞），这是判断缓冲区是否有待读内容的正确方式；
• 手动控制缓冲逻辑：若需精细控制字符缓存，建议自己封装一层带缓冲的读取器（如用 char[1024] + InputStreamReader），而非侵入 JDK 内部；
• 调试时临时观察：仅限开发调试，可用 IDE 的变量查看器（如 IntelliJ 的 “View as → char[]”）直接展开 BufferedReader 实例，无需写反射代码。

如果坚持用反射（仅测试/学习场景）

仅作技术演示，实际项目中请规避：

• 需先获取 cb 字段：Field cbField = BufferedReader.class.getDeclaredField("cb");
• 设为可访问：cbField.setAccessible(true);
• 获取值：char[] buffer = (char[]) cbField.get(reader);
• 注意：还需配合 nextChar 和 markedChar 等字段才能理解当前有效范围，而这些字段同样无契约保证。

更健壮的做法：封装自定义缓冲读取器

若业务真需暴露缓冲区状态（例如实现断点续读、调试协议解析），推荐自行实现：

• 组合 Reader，维护自己的 char[] buf 和 int pos, limit；
• 提供 getBufferSnapshot()、getAvailableCount() 等明确语义的方法；
• 完全可控、可测试、跨 JDK 版本稳定。

反射读 cb 是绕过抽象的捷径，但代价是脆弱性和维护黑洞。Java 的 IO 设计哲学是“用接口，而非实现”，尊重这一点，代码才真正可靠。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南