应使用console.readpassword()实现密码不回显，因其调用系统api禁用tty回显，返回可清零的char[]保障内存安全；但system.console()在ide、docker等非原生终端中为null，须判空处理。
Java 的 Console 类通过操作系统级终端控制实现密码不回显，其底层并非 Java 自行屏蔽字符，而是调用 native 层禁用 TTY 的回显模式（如 Unix 的 termios 中 ECHO 标志关闭，Windows 的 SetConsoleMode 清除 ENABLE_ECHO_INPUT）。整个过程绕过 Java 字符流缓冲，直接与系统控制台设备交互，因此输入内容不会出现在屏幕，也不会被 shell 历史记录捕获。
为什么 System.console() 在 IDE 里总是 null
IDE（如 IntelliJ、Eclipse、VS Code 内置终端）启动 JVM 时通常不分配真实 TTY，而是使用伪终端或管道重定向 stdin/stdout。而 System.console() 仅在 JVM 直接连接到操作系统原生控制台（如 macOS Terminal、Windows cmd/PowerShell、Linux bash）时才返回有效实例。这是 JVM 规范行为，并非 bug。
- 运行 jar 包必须用命令行：
java -jar app.jar，不能点 IDE 的 ▶ 按钮 - CI/CD 流水线、Docker 容器默认无 console，需显式配置
tty: true或改用其他输入方式 - 开发调试阶段务必判空：
if (System.console() == null) { /* fallback to Scanner + warning */ }
readPassword() 返回 char[] 而非 String 的安全逻辑
String 在 Java 中不可变且可能进入字符串常量池或被 JIT 优化驻留内存，导致密码在堆中长期残留，易被内存 dump 工具提取。char[] 是可变数组，允许显式覆写清零，大幅降低敏感信息泄露风险。
- 正确用法：获取后立即处理，然后调用
Arrays.fill(pwd, '\0') - 避免转 String 后再丢弃原始数组，例如不要写
String s = new String(pwd); Arrays.fill(pwd, '\0')—— 因为new String(pwd)会复制一份明文到堆中，且该 String 可能被意外日志输出 - 若必须传给只接受 String 的旧 API，应在最小作用域内转换，并确保该 String 不参与日志、序列化、缓存等任何持久化环节
跨平台与编码兼容性注意事项
Console 输入依赖系统终端的字符编码和行结束符。Windows 中文路径下运行时，若终端编码（如 GBK）与 JVM 默认编码（UTF-8）不一致，可能导致 readPassword() 返回乱码 char[]；macOS/Linux 一般使用 UTF-8，兼容性更好。
- 建议显式指定 JVM 编码：启动时加参数
-Dfile.encoding=UTF-8 - 避免在路径含中文的 Windows 环境下测试，尤其当终端是旧版 cmd（非 PowerShell）时
- 生产环境不推荐依赖 Console —— 容器、服务化场景基本不可用，应改用配置中心、密钥管理服务（KMS）或加密文件等更健壮方案
这套机制本质是“借力操作系统”，安全边界清晰但环境约束强。它不是万能密码输入方案，而是特定场景下的轻量级终端防护手段。
