console类仅在真实终端有效，ide中system.console()返回null；需判空降级；scanner无终端限制但缓冲区易出错；console.readpassword()是唯一安全密码输入方式。
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()读姓名却“跳过”了，控制台光标一闪就往下走。
立即学习“Java免费学习笔记（深入）”；
- 根本原因：
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环境直接挂掉。
