System.setIn在单元测试中常失效，因其仅作用于当前线程且需在被测代码读取System.in前调用；若Scanner已缓存原始流或框架跨线程执行，则设置无效。
System.setIn 为什么在单元测试里经常失效
因为 System.setIn 只影响当前线程的 System.in，而很多框架（比如 JUnit 5 的并行执行、Spring Test 的上下文加载）可能在不同线程中触发被测代码，或者被测逻辑早于测试用例调用了 new Scanner(System.in) 并缓存了原始流——这时候再调用 System.setIn 就完全没用了。
常见错误现象：Scanner.nextLine() 依然阻塞、抛出 NoSuchElementException、读到空字符串或旧输入。
- 务必在被测类实际读取
System.in之前 调用System.setIn - 如果被测代码封装了
Scanner实例（如作为静态字段或单例），需在测试前重置该实例，或改用构造注入 - JUnit 5 中避免使用
@TestInstance(TestInstance.Lifecycle.PER_CLASS)+ 静态初始化块混合调用，容易触发时序问题
用 ByteArrayInputStream 安全重定向 System.in
这是最轻量、最可控的方式：把测试输入提前转成字节流，再塞给 System.setIn。注意编码和换行符必须匹配目标平台预期，否则 Scanner.nextLine() 可能卡住。
使用场景：模拟用户逐行输入、含空格的字符串、多行交互式命令。
立即学习“Java免费学习笔记（深入）”；
- 用
new ByteArrayInputStream("hello\n42\n".getBytes(StandardCharsets.UTF_8))，别漏掉\n或\r\n - 如果被测代码用
BufferedReader.readLine()，换行符必须是\n（Unix 风格），Windows 下也认这个；Scanner默认也按\n切分 - 测试结束后建议恢复原始输入流：
System.setIn(originalIn)，尤其在共享 JVM 的测试套件中（如 Maven Surefire 并行执行）
示例：
InputStream originalIn = System.in;
try (InputStream in = new ByteArrayInputStream("test input\n".getBytes(StandardCharsets.UTF_8))) {
System.setIn(in);
// 执行被测方法
} finally {
System.setIn(originalIn);
}
JUnit 5 中配合 @BeforeEach 和 @AfterEach 管理输入流
手动恢复 System.in 容易遗漏，尤其当测试抛异常时。用生命周期钩子更稳妥，但要注意：JUnit 不保证 @AfterEach 在所有情况下都执行（比如 JVM 强制退出），所以不能依赖它做关键清理。
-
@BeforeEach中保存原始System.in并设置新流 -
@AfterEach中无条件恢复，哪怕测试已失败 - 不要在
@AfterEach里加日志或复杂逻辑，避免干扰测试稳定性 - 如果多个测试类都要用，可抽成自定义
Extension，但多数项目直接写钩子更直观
比 System.setIn 更可靠的替代方案
真正难测的交互逻辑，硬塞 System.in 往往是设计信号——说明输入耦合太深。优先考虑重构被测代码，把输入源抽象出来。
- 把
Scanner或BufferedReader作为参数传入，测试时直接传new Scanner(new ByteArrayInputStream(...)) - 定义接口如
InputReader，生产用SystemInReader，测试用MockInputReader - Spring Boot 命令行应用可用
@SpringBootTest(args = {"--input=test"})配合@Value注入，绕过 stdin
强行用 System.setIn 的代价是：每次改输入格式都要动测试 setup，且无法覆盖多线程读取、超时、中断等边界情况。
真正麻烦的从来不是怎么设，而是设完之后——输入流被谁缓存了、在哪被关掉了、有没有其他线程正在读。这些细节不盯住，光换实现方式没用。
