银行账户应封装为责任明确的实体，余额字段须private，仅通过deposit()和withdraw()校验后修改，构造方法拒绝负初始余额。

如何用 Java 类封装银行账户的核心行为

账户不是数据容器，而是有明确责任的实体。直接暴露 balance 字段或提供无校验的 setBalance() 方法，等于把取款机钥匙交给任意调用方。

• 必须用 private 修饰余额字段，强制所有变更走业务方法
• deposit(double amount) 和 withdraw(double amount) 是唯二修改余额的入口，内部需校验金额正负、透支等逻辑
• 构造方法应拒绝负初始余额，例如：

  public Account(String accountNumber, double initialBalance) {
      if (initialBalance < 0) {
          throw new IllegalArgumentException("Initial balance cannot be negative");
      }
      this.accountNumber = accountNumber;
      this.balance = initialBalance;
  }

为什么不能用 double 表示货币金额

浮点数精度问题在金融场景下是致命的。比如 0.1 + 0.2 在 Java 中结果是 0.30000000000000004，不是数学意义上的 0.3。

• 必须使用 BigDecimal 存储和计算金额，且构造时用字符串（new BigDecimal("100.50")），避免 double 构造器引入误差
• 所有加减乘除操作都调用 add()、subtract()、multiply()、divide() 方法，并指定 RoundingMode
• 显示输出前用 setScale(2, RoundingMode.HALF_UP) 统一保留两位小数

转账操作必须跨账户原子性处理

转账不是两个独立操作：A 减钱、B 加钱。中间若发生异常（如 A 扣款成功但 B 入账失败），会导致资金丢失或重复入账。

• 转账方法应定义在外部服务类（如 BankService）中，而非单个 Account 类内
• 必须用同步块或显式锁控制并发，防止多线程同时对同一账户操作引发竞态条件
• 推荐先校验双方账户有效性及余额充足性，再执行扣减与增加，任一环节失败则全部回滚（实际项目中需结合事务管理器，简易版可用布尔返回值+状态重置）

账户编号生成与唯一性保障的实操陷阱

用 Math.random() 或简单递增整数生成账号，在多实例或高并发下极易冲突。

• 开发阶段可用 UUID.randomUUID().toString().replace("-", "").substring(0, 10) 快速生成伪唯一 ID
• 生产环境必须依赖数据库主键自增、Snowflake 算法或分布式 ID 生成服务
• 若用内存集合（如 Map）做账户仓库，添加新账户前必须检查 map.containsKey(accountNumber)，否则覆盖已有账户