StringReader和StringWriter适合单元测试，因其是内存中轻量级字符串与流接口的适配器，不依赖外部资源、不抛IOException、行为确定且close/flush为空操作，便于构造输入和断言输出。

在单元测试中，用 StringReader 和 StringWriter 模拟 IO 流是最轻量、最可控的方式——不依赖文件系统、不触发网络、不涉及编码转换，所有操作都在内存中完成，且语义清晰、开销极小。

为什么适合单元测试

它们本质是字符串与流接口之间的“适配器”，把 String 无缝接入 Reader/Writer 体系，让被测代码无需感知数据来源是文件、网络还是内存。测试时可直接构造输入、断言输出，完全绕过外部副作用。

• StringReader 将固定字符串转为可读的字符流，支持 read()、readLine()、skip() 等标准行为，行为确定、无异常边界干扰
• StringWriter 基于 StringBuffer（线程安全、动态扩容），写入后调用 toString() 即得完整结果，close() 和 flush() 是空操作，调用与否不影响结果
• 两者都不抛出 IOException（除非传 null 或非法参数），省去大量 try-catch，测试逻辑更聚焦业务

典型测试场景写法

比如被测方法接收一个 Reader 解析 JSON，或接受一个 Writer 生成模板文本：

• 构造输入：用 new StringReader("{\"name\":\"Alice\"}") 替代文件读取或 HTTP 响应体
• 捕获输出：用 StringWriter writer = new StringWriter() 传入方法，之后断言 writer.toString() 是否符合预期
• 组合使用：如测试一个“读一行、转大写、写一行”的处理器，可链式连接 BufferedReader + StringReader 和 PrintWriter + StringWriter

注意几个关键细节

高效不等于随意，几个易忽略但影响稳定性的点：

• StringWriter 默认缓冲区大小是 16 字符，若写入长文本（如日志块、HTML 片段），建议显式指定初始容量，避免频繁扩容：new StringWriter(4096)
• StringReader 的 read(char[] cbuf, int off, int len) 不会自动填充整个数组，返回值是实际读取长度，测试中需按返回值截取字符串，不能直接 new String(cbuf)
• 无需 close()，但若被测逻辑内部调用了 close()，也不必 mock——它什么也不做，不会中断后续 toString()
• 不支持设置编码，所有字符按 JVM 默认 charset 处理；如需验证 UTF-8 行为，应改用 InputStreamReader(new ByteArrayInputStream(bytes), "UTF-8")

对比其他模拟方式

比起用 Mockito mock Reader/Writer 接口，或创建临时文件再清理，StringReader/StringWriter 更可靠：

• Mockito 容易漏掉某些方法调用（如 ready()、mark()），而真实流有完整契约
• 临时文件引入 I/O、路径权限、清理遗漏风险，且无法覆盖流提前关闭、部分读取等边界情况
• 它们本身就是 JDK 标准实现，行为与生产环境一致，零抽象失真