JavaConsole与Scanner输入对比解析

Java的Console类是唯一能安全实现密码不回显输入的标准工具，但它仅在真实系统终端中有效，IDE或构建工具环境下会因System.console()返回null而失效，必须预先判空并设计降级方案；相比之下，Scanner虽兼容性强、可在任何环境运行，却因缓冲区机制容易导致next()与nextLine()混用时跳过输入，且完全无法隐藏敏感信息——用它读密码等于明文暴露；二者底层读取方式不同，混用会引发流状态错乱，因此一个程序应严格选择其一：终端脚本优先Console（兼顾安全与体验），教学或快速开发选Scanner（注意缓冲区陷阱），而高频输入场景则建议升级为BufferedReader。

Console类只能在真实终端里用，IDE里基本失效

Java的Console类依赖底层操作系统的原生终端支持，它通过System.console()获取实例，但这个方法在多数IDE（如IntelliJ、Eclipse）的内置终端或Maven/Gradle运行环境下会直接返回null。不是bug，是设计如此——它只认系统级tty。

常见错误现象：NullPointerException出现在调用console.readLine()或console.readPassword()之前，因为根本没拿到Console对象。

• 验证是否可用：必须先判空，Console console = System.console(); if (console == null) { /* 切换方案 */ }
• 真正能用的场景：命令行直接执行java YourApp、Linux/macOS终端、Windows PowerShell（非cmd有时也不稳）
• IDE调试时想用密码输入？别硬扛，换成Scanner加提示语，或者改用System.in.read()手动读字节（不推荐）

Scanner适合交互式输入，但默认吃掉换行符导致next()和nextLine()混用崩溃

Scanner没有终端绑定限制，任何环境都能跑，但它内部的缓冲区行为容易让人踩坑：每次调用nextXXX()（如nextInt()、next()）后，输入流里的换行符\n仍留在缓冲区，紧接着调用nextLine()就会立刻返回空字符串。

典型错误现象：nextInt()读年龄后，nextLine()读姓名却“跳过”了，控制台光标一闪就往下走。

• 根本原因：next()系列方法只读目标token，不消费分隔符；nextLine()则专吃从当前位置到换行符之间的所有内容
• 解法只有两个：要么统一用nextLine()再自己转类型（Integer.parseInt(sc.nextLine())），要么在nextXXX()后补一句sc.nextLine()清掉残留换行符
• 性能差异不大，但Scanner比Console多一层词法解析开销，高频输入（如游戏循环）建议用BufferedReader替代

Console能安全读密码，Scanner不能——别拿nextLine()假装掩码

Console.readPassword()是Java唯一提供“输入不回显”能力的标准API，它直接绕过Java层缓冲，把字符写入终端驱动前就屏蔽显示。而Scanner.nextLine()哪怕你输的是密码，也会明文打在屏幕上。

使用场景很明确：只要涉及账号密码、API密钥、SSH口令这类敏感输入，Console是底线选择；否则一律算安全违规。

• 注意readPassword()返回char[]而非String，这是为了方便用Arrays.fill(pwd, '\0')及时擦除内存，避免GC前被dump
• 别试图用System.out.print("*")模拟掩码——用户按退格键时星号不会删，体验错乱，且依然明文传输
• 如果System.console()为null（比如IDE里），只能降级：提示用户“请在终端中运行”，或改用GUI弹窗（Swing/JFX）

别在同一个程序里混用Console和Scanner读stdin

两者都从System.in读，但Console用的是底层FileDescriptor.in直连，Scanner则包装了InputStreamReader并自带缓冲区。一旦先后调用，缓冲区状态会错乱，比如Scanner已预读几字节但未消费，Console再去读就丢数据。

这不是竞态，是流状态不可逆——Java没提供“把字节吐回流”的标准接口。

• 一个进程只选一种：脚本工具类用Console（需终端），教学示例/快速原型用Scanner（兼容性好）
• 如果必须动态切换（比如检测到终端才启用密码输入），得在启动时就决定策略，后续全程隔离输入逻辑
• 真要混合？唯一办法是彻底不用System.in，改用new FileInputStream(FileDescriptor.in)手动管理，但代价远超收益

事情说清了就结束。最常被忽略的其实是System.console()的null检查——很多人写了readPassword()却忘了兜底，结果线上脚本在CI环境直接挂掉。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaConsole与Scanner输入对比解析》文章吧，也可关注golang学习网公众号了解相关技术文章。