BankAccount类应使用BigDecimal存余额、String存账号，构造时校验初始金额≥0并设状态为ACTIVE，禁用setBalance()；withdraw()需检查状态、余额、锁机制并返回boolean。
BankAccount 类怎么设计才符合真实业务逻辑
银行账户不是只有余额字段，必须区分账户类型、状态和操作约束。比如储蓄账户不能透支，而信用卡账户有信用额度；账户被冻结后所有交易应拒绝。
关键点：
-
balance应为BigDecimal，避免double的浮点精度问题（如 0.1 + 0.2 ≠ 0.3） -
accountNumber宜用String而非long，因实际账号含前导零或校验位（如"BANK12345678"） - 构造方法中应校验初始金额 ≥ 0，且设置
status = "ACTIVE"，而非默认null - 不暴露
setBalance()这类危险 setter，余额变更必须通过deposit()或withdraw()控制流程
withdraw() 方法如何正确处理失败场景
直接用 if (balance >= amount) 判断不够——它没考虑账户状态、最小余额限制、单日限额等现实规则。更严重的是，若多个线程同时调用，还会出现竞态条件。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先检查
status.equals("ACTIVE")，否则抛IllegalStateException - 对储蓄账户，判断
balance.subtract(amount).compareTo(MIN_BALANCE) >= 0（MIN_BALANCE可设为new BigDecimal("10.00")） - 加
synchronized块或使用ReentrantLock，但注意：锁粒度别过大（比如不要锁整个对象，只锁该账户实例） - 返回
boolean表示是否成功，而非 void；失败时明确抛出不同异常（如InsufficientFundsException、AccountFrozenException）
为什么 AccountManager 不该是静态工具类
把 addAccount()、findAccount() 全写成 static 方法，会导致测试困难、无法 mock、违反单一职责——它其实是一个有状态的聚合根。
更好做法：
- 定义
AccountManager实例类，内部用Map存储，键为accountNumber - 构造时可接受
AccountRepository接口（便于后续替换为数据库实现） - 提供
transfer(String from, String to, BigDecimal amount)方法，且必须在单个事务内完成：先扣减再存入，任一失败则回滚（可用try-catch+ 人工补偿） - 避免在 manager 中直接 new BankAccount()，应由工厂或 builder 创建，确保对象始终合法
public class AccountManager {
private final Map accounts = new ConcurrentHashMap<>();
public boolean transfer(String fromNum, String toNum, BigDecimal amount) {
BankAccount from = accounts.get(fromNum);
BankAccount to = accounts.get(toNum);
if (from == null || to == null) return false;
synchronized (from) {
synchronized (to) {
if (!from.withdraw(amount)) return false;
to.deposit(amount);
return true;
}
}
}
}
测试时最容易忽略的边界条件
很多初学者只测 “正常存 100 → 余额变 100”，却漏掉这些真实会炸的点：
- 传入
null账号号：manager.findAccount(null)应明确抛NullPointerException或提前校验 - 金额为负：如
account.deposit(new BigDecimal("-50"))，应在方法入口 throwIllegalArgumentException - 超大金额：
new BigDecimal("999999999999999999999999999999.99")是否触发ArithmeticException？需在deposit()中加scale() == 2校验 - 并发转账：用
ExecutorService启 100 线程反复调用同一对账户的transfer()，验证最终余额不变
