ATM核心实体应建模为Account（管余额与存取款校验）、Transaction（不可变交易记录）、ATM（持账户Map与交易LinkedList）；账户用HashMap按卡号索引，交易用LinkedList追加，金额用double或BigDecimal避免精度问题。
如何用Java类建模ATM核心实体（Account、ATM、Transaction）
ATM模拟的关键不是界面或IO，而是把“账户”“取款动作”“余额变动”这些现实概念映射成可协作的Java对象。别一上来就写Scanner读输入，先定义清楚职责边界：
-
Account只管自己的balance、accountNumber，提供withdraw(double amount)和deposit(double amount)，且必须校验金额非负、取款不超余额 -
Transaction是不可变记录：含type（"WITHDRAW"/"DEPOSIT"）、amount、timestamp（用System.currentTimeMillis()即可） -
ATM类不存余额，只持有一个List<Account>和一个List<Transaction>，所有业务逻辑通过调用Account方法完成
这样设计后，测试单个账户逻辑时完全不需要启动ATM——直接new一个Account调withdraw()就行。
用ArrayList还是HashMap管理多个账户？
用户登录靠卡号（字符串），查账户是高频操作。用ArrayList<Account>遍历查找，时间复杂度O(n)；而HashMap<String, Account>按accountNumber做key，get操作平均O(1)。实际中后者更合理：
private Map<String, Account> accounts = new HashMap<>();
// 添加账户
accounts.put("6228480000000000000", new Account("6228480000000000000", 5000.0));
// 根据卡号快速获取
Account acc = accounts.get("6228480000000000000");
注意：HashMap的key必须是不可变对象，String符合；如果自己写Account类作为key，就得重写hashCode()和equals()——但这里没必要，卡号字符串已足够唯一。
立即学习“Java免费学习笔记（深入）”；
为什么Transaction列表要用LinkedList而不是ArrayList？
交易记录只追加、不修改、极少随机访问（比如查第5笔），但可能频繁在末尾添加。虽然ArrayList尾部add也是O(1)均摊，但扩容时有数组复制开销；LinkedList每次add都是纯粹指针操作，无扩容成本。更重要的是语义清晰：LinkedList明确表示“这是一个按时间顺序追加的线性日志”。不过若后续要支持“查最近10笔”，用ArrayDeque会更省内存，但对简易ATM，LinkedList足够直观。
- 别用
ArrayList存交易然后每次add(0, tx)倒序插入——那是O(n)操作，严重拖慢 - 交易列表不应暴露给外部修改，声明为
private final List<Transaction> transactions = new LinkedList<>();，只提供addTransaction(Transaction tx)方法
常见运行时错误及规避方式
真实跑起来最容易崩在三处：
-
NullPointerException：用户输错卡号，accounts.get("xxx")返回null，接着调acc.withdraw(100)就炸。必须检查acc == null并提示“卡号不存在” -
InputMismatchException：用Scanner.nextDouble()读取金额时，用户输了个"abc"。应在try-catch里捕获，并scanner.next()清掉非法输入，否则下次读取仍失败 - 余额透支：取款前没校验
if (amount > acc.getBalance())，导致余额变负数。这是业务逻辑漏洞，不是异常，必须在Account.withdraw()内部拦截并抛IllegalArgumentException
所有金额运算避免用float——精度丢失会导致0.1+0.2≠0.3。一律用double（教学场景可接受）或BigDecimal（生产级必需），但后者构造必须用字符串：new BigDecimal("100.50")，不能用new BigDecimal(100.50)。
