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