应使用 System.console().readPassword() 读密码，因其可屏蔽回显且无换行符残留；但需先判空，因 IDE 终端中返回 null，且 char[] 比 String 更安全。
为什么不用 Scanner.nextLine() 直接读密码
因为 Scanner.nextLine() 会残留换行符，且无法屏蔽输入回显——用户输密码时会明文显示在控制台，存在安全隐患。Java 标准库提供了更合适的替代：System.console().readPassword()。
但要注意：System.console() 在 IDE（如 IntelliJ、Eclipse）的内置终端中返回 null，导致 NullPointerException。真实运行必须通过系统终端（Windows CMD / macOS Terminal / Linux Shell）执行 java PasswordManager。
- 开发调试阶段可用
Scanner+ 提示语临时绕过，但务必标注 TODO 并禁用提交 - 生产级逻辑中，永远优先检查
System.console() != null - 返回的
char[]比String更安全：可手动清空数组，避免内存中长期驻留明文
如何安全存储密码（不存明文）
密码管理工具的核心矛盾是：既要“记住密码”，又不能“存明文”。初学者常误以为 Base64 编码 = 加密，其实它只是可逆编码，毫无安全性。
正确做法是使用带盐哈希（salted hash）。Java 8+ 自带 java.security.MessageDigest 和 java.security.SecureRandom，推荐 PBKDF2WithHmacSHA256 算法：
立即学习“Java免费学习笔记（深入）”；
- 每次生成唯一随机 salt（至少 16 字节）
- 迭代次数设为 65536 或更高（兼顾安全与性能）
- 哈希结果保存为十六进制字符串或 Base64，和 salt 一起存入文件（如 JSON 或简单文本）
- 验证时重新用同一 salt + 迭代次数计算哈希，比对结果而非原始密码
SecureRandom random = new SecureRandom();
byte[] salt = new byte[16];
random.nextBytes(salt);
KeySpec spec = new PBEKeySpec(password, salt, 65536, 256);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] hash = factory.generateSecret(spec).getEncoded();
用 Properties 还是 JSON 存储账号数据
初学者倾向用 java.util.Properties，因为它简单、内置、支持 .properties 文件。但它有硬伤：键值只能是 String，不支持嵌套结构；特殊字符需转义；无类型校验；无法直接表达“一个网站多个账号”这类关系。
对于密码管理这种需要扩展性的场景，轻量 JSON 更合适。不必引入 Jackson 或 Gson 全家桶，用 org.json（单 jar，约 250KB）即可：
- 每个条目是
JSONObject，含site、username、encryptedPassword、salt、createdAt - 整个列表存为
JSONArray，写入passwords.json - 读取时先检查文件是否存在，再尝试解析，捕获
JSONException避免崩溃 - 敏感字段如
encryptedPassword和salt必须 Base64 编码后存，避免 JSON 解析失败
main 方法里直接写业务逻辑会踩哪些坑
很多初学者把所有代码堆在 public static void main(String[] args) 里：读命令、解析参数、调哈希、写文件……看似跑通，但后续加功能（比如导出 CSV、搜索模糊匹配）就会失控。
建议从第一天就拆出三个最小职责类：
-
PasswordEntry：纯数据载体，含 site/username/encryptedPassword/salt/timestamp，重写equals和toString -
PasswordStorage：封装文件读写，只暴露save(List<passwordentry>)</passwordentry>和load()，内部处理 JSON 序列化与异常 -
PasswordService：实现核心逻辑，如add(String site, String username, char[] rawPassword)、find(String keyword)，不碰 I/O 或 UI
这样改需求时，比如要换成 SQLite 存储，只需重写 PasswordStorage，其他部分完全不动。
真正容易被忽略的是异常路径：用户输错两次密码、JSON 文件损坏、磁盘满、salt 解码失败……这些分支不提前设计，后期 debug 会花掉十倍时间。
