ATM系统应采用状态驱动设计，Account类负责余额操作与密码验证，ATM类负责流程控制；避免静态方法堆砌和main函数臃肿；持久化优先选Properties或CSV/JSON而非Java序列化。
如何用Java类模拟ATM核心行为
ATM系统本质是状态驱动的交互流程，不是堆砌功能。关键在于把「取款」「查询」「转账」这些操作封装成Account和ATM两个职责清晰的类，而不是写一堆静态方法。
常见错误是把所有逻辑塞进一个main方法里，导致后续无法测试、无法扩展。正确做法是让Account只管余额增减与校验（比如不允许透支），ATM只管流程控制（插卡→输密→选服务→执行→退卡）。
-
Account应有私有balance字段，提供withdraw(double amount)和deposit(double amount)，内部做金额合法性检查 -
ATM持有一个Account引用（或多个，对应多用户），不直接操作字段，只调用其公开方法 - 密码验证逻辑建议放在
Account里（verifyPin(String input)），而不是在ATM中硬编码判断
用文件存储账户数据是否可行
对简单练习项目，用ObjectOutputStream序列化Account对象到accounts.dat是最快落地的方式，但必须注意几个硬伤：
- Java序列化格式不跨版本，JDK升级后可能读不出旧文件；
Account类加个字段就反序列化失败 - 并发写入会出问题——两个ATM实例同时保存，后保存的会覆盖前一个
- 无法按用户名查账户，只能全量加载再遍历，1000个账户就要遍历1000次
如果真想练数据持久化，改用Properties存纯文本键值对更稳妥：user001.balance=5000.0，用FileReader逐行解析，至少能人工检查和编辑。
立即学习“Java免费学习笔记（深入）”；
为什么不要用Scanner.nextLine()连续读字符串
在ATM菜单循环中，很多人写Scanner sc = new Scanner(System.in);后反复调用nextLine()，结果第二次输入直接跳过——这是nextInt()或nextDouble()留下的换行符没被消费导致的。
根本原因不是Scanner有bug，而是它把输入流看作字符流，nextInt()只读数字不读后面的\n，下一次nextLine()立刻拿到空行。
- 统一用
nextLine()读所有输入，数字用Double.parseDouble(sc.nextLine())转 - 或者每次用完
nextInt()后补一句sc.nextLine()清掉换行符 - 避免混合使用
nextXXX()和nextLine()，尤其在循环里
账户类要不要实现Serializable接口
只有当你明确要用ObjectOutputStream保存对象时才需要。但实际开发中几乎没人这么干，因为序列化文件无法被其他语言读取，也不能用SQL工具查，更没法做部分更新。
如果你只是想“让程序重启后账户还在”，那Serializable只是最省事的临时方案。真正要注意的是：一旦加了这个接口，Account里所有非transient字段都会被存，包括你忘了删的调试用logger或connection对象——运行时直接抛NotSerializableException。
更轻量的做法是手写saveToFile()方法，只写id、pinHash、balance三个字段到CSV或JSON，用Files.write()一行搞定，可控且易调试。
