Console.readLine() 不能用于密码输入，原因很直接
Console.readLine() 会明文回显用户输入的每个字符，密码直接暴露在终端上。这不是“不推荐”，而是根本不符合安全交互的基本前提——哪怕只是本地调试，也不该养成这种习惯。
真正该用的是 Console.readPassword()，它底层调用系统级 API（如 Unix 的 tcsetattr 或 Windows 的 SetConsoleMode）禁用回显，输入过程完全不可见。
-
readPassword()返回char[]，不是String—— 这是关键：数组可手动清零，避免内存中长期残留敏感内容 - 如果调用
readPassword()时System.console()返回null（常见于 IDE 内置终端、某些 CI 环境），程序不会抛异常，而是静默返回null，必须主动判空 - 不要对
char[]做new String(pwd)或日志打印，清零后也别让它被 GC 前意外泄露
System.console() 为 null 的典型场景和应对方式
Java 的 Console 对象只在 JVM 启动时连接到真实终端（tty）才可用。IDE（IntelliJ/Eclipse）、Maven exec 插件、Docker 默认启动模式、Jenkins 控制台都会导致 System.console() 返回 null。
不能靠 try-catch 捕获异常来兜底，因为根本没异常；也不能硬编码 fallback 到 Scanner —— 那等于放弃安全。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 先检查：
if (System.console() == null) { throw new IllegalStateException("No console available for secure input"); } - 生产部署时，确保用
java -jar app.jar直接运行，而非通过 IDE 或脚本间接启动 - CI/CD 中需要密码（如数据库凭证），应改用环境变量或密钥管理服务，而非交互式输入
readPassword() 的实际使用细节和坑
readPassword() 行为比表面看起来更“重”：它会阻塞直到用户按 Enter，且不支持退格修正（某些终端下 Backspace 显示 ^H 但不影响内部数组），输入体验接近传统 Unix su 或 sudo。
- 参数可选提示字符串：
console.readPassword("Password: ")，但提示本身不隐藏，这是正常设计 - 返回的
char[]长度严格等于用户输入字符数（不含 Enter），空密码返回长度为 0 的数组，不是null - 输入过程中若触发 Ctrl+C，会抛
java.io.IOError（含InterruptedException），需捕获并清理资源 - 别用
Arrays.equals()直接比对两个char[]密码——用java.security.MessageDigest哈希后比对，或至少用Arrays.compareConstantTime()防时序攻击
为什么不用 Scanner 或 BufferedReader 替代
有人试过用 Scanner.nextLine() 加手动关闭回显（比如调 stty -echo），但这在跨平台和权限上全是问题：Windows 没 stty，普通用户无法修改终端模式，而且一旦异常退出，终端可能永久卡在无回显状态。
-
Scanner输入结果是String，不可变对象，JVM 堆里存多久你控制不了 -
BufferedReader同样明文读取，且没有标准方式禁用回显 - 所有绕开
Console的方案，本质都是在模拟一个不完整、不可靠、难测试的安全层
真正的安全交互不是“让密码看起来不显示”，而是从输入源头、内存生命周期、终端控制三端对齐。缺一不可，少一个环节就等于没做。
