Account类应将balance设为private BigDecimal，余额变更全由带校验的withdraw()等方法控制，禁止setBalance()；输入解析、校验与执行须分离；提示语句不得写入Account，确保可测试性与扩展性。
Account 类怎么设计才不容易出余额负数问题
账户对象不是把 balance 做成 public double 就完事了——直接暴露字段会导致外部随意修改，校验逻辑分散，一改就漏。核心是把余额变更全收口到方法里，且每次变更都强制走校验。
-
balance必须是private，不提供setBalance()这类“后门”方法 - 提款操作只允许通过
withdraw(double amount)，且该方法内部必须先判断amount > 0和balance >= amount - 推荐用
BigDecimal而非double存余额，避免浮点误差（比如 10.0 - 9.99 = 0.010000000000000009） - 构造函数里对初始余额也要校验：
if (initialBalance.compareTo(BigDecimal.ZERO)
withdraw() 方法里校验失败该抛什么异常
别用 System.out.println() 打印错误，也别返回 false 让调用方自己猜失败原因。ATM 场景下，余额不足、金额非法、系统异常要区分清楚，否则上层没法做对应提示或重试。
- 余额不足 → 抛
InsufficientFundsException（自定义运行时异常），让 UI 显示“余额不足，请重新输入” - 金额 ≤ 0 或非数字 → 抛
IllegalArgumentException，前端可捕获并高亮输入框 - 数据库更新失败（如有持久化）→ 抛
RuntimeException或更具体的DataAccessException，触发事务回滚 - 不要吞掉异常：写
catch (Exception e) { }然后静默失败，这是最常踩的坑
主流程里怎么防止用户输错后直接跳到取款成功
很多初学者把输入解析、校验、业务执行混在一段 main() 里，一个 Scanner 读完就调 account.withdraw()，结果用户输个 "abc" 或 "-100"，程序要么报 InputMismatchException 崩掉，要么因没校验直接扣款为负。
- 输入解析必须独立封装，例如
parseAmount(String input)：用try-catch捕获NumberFormatException，失败时返回Optional.empty()或抛受检异常 - 校验和执行要分两步：先
if (account.canWithdraw(amount))（只读判断），再account.withdraw(amount)（实际扣款） - 控制台交互建议加循环重试：
while (!validInput) { ... }，而不是“输错一次就退出” - 注意
Scanner的换行残留：nextLine()前如果用了nextInt()，得额外加一行scanner.nextLine()清缓冲区，否则后续输入会跳过
为什么 ATM 模拟里不该在 Account 里写 print 语句
Account 是模型，只管数据和规则；输出提示是表现层职责。把 System.out.println("取款成功") 写进 withdraw()，会导致单元测试难写、无法对接 GUI、日志格式混乱。
立即学习“Java免费学习笔记（深入）”；
-
withdraw()只做三件事：校验参数、校验余额、更新balance字段——成功就返回void或boolean，失败就抛异常 - 所有提示文字（如“请输入取款金额”“取款成功，当前余额：xxx”）统一放在
ATMService或Main类里 - 这样改需求时才灵活：比如以后要加微信通知，只需改服务层，Account 类完全不动
- 顺便提醒：别在
toString()里拼接提示语，它只该返回对象状态快照，比如"Account{balance=123.45}"
事情说清了就结束。真正麻烦的不是写完能跑通，而是当你要加手续费、日限额、多币种、事务日志时，发现 Account 里到处散着 System.out 和裸 double 字段——那时候重构成本比重写还高。
