用Java建模记账系统需先定义Account、Transaction、Category（枚举）三类，封装TransactionManager管理业务逻辑与余额同步，输入校验防异常，CSV持久化确保数据可靠。
如何用 Java 类建模记账核心实体
记账系统最关键的不是界面或存储，而是把「账目」「账户」「分类」这些现实概念准确映射为类。别一上来就写 main，先想清楚职责边界。
-
Account类只管账户名、余额、创建时间，不处理记账逻辑 -
Transaction类必须包含金额（double amount）、类型（String type，如 "income" / "expense"）、分类（Category category）、时间（LocalDateTime time）和可选备注 -
Category用枚举比字符串更安全：public enum Category { FOOD, TRANSPORT, SALARY, ENTERTAINMENT } - 避免在
Transaction里直接存账户名字符串——用Account引用，方便后期扩展（比如查某账户所有流水）
为什么不用 ArrayList 而要封装成 TransactionManager
直接在 Main 里用 ArrayList<Transaction> 看似简单，但很快会遇到：重复添加、按月筛选失效、余额算错、无法撤销操作。把这些逻辑全塞进一个列表变量，等于把业务规则藏在调用处，没人能一眼看出约束。
- 新建
TransactionManager类，内部持有一个private List<Transaction> transactions - 提供
add(Transaction t)方法，在里面校验：t.getAmount() != 0、t.getTime() != null、关联的Account是否已存在 - 余额不能靠遍历重算——每个
Account应维护自己的balance，并在TransactionManager.add()中同步更新（否则多线程或频繁查询时性能崩盘） - 不要暴露
getTransactions()返回原始List，改用unmodifiableList或返回副本，防止外部误修改
控制台交互中容易被忽略的输入校验点
用户输错一个字符，程序就抛 InputMismatchException 或 DateTimeParseException，体验极差。Java 的 Scanner 默认不校验格式，得自己兜底。
- 读取金额时，用
scanner.hasNextDouble()判断再nextDouble()，而不是直接nextDouble()后 catch - 解析日期用
DateTimeFormatter.ofPattern("yyyy-MM-dd")，并 try-catchDateTimeParseException，提示“请输入 2024-03-15 格式” - 选择菜单项时，用
scanner.hasNextInt()+ 范围检查（比如选项是 1–5，就判断input >= 1 && input <= 5），别依赖nextInt()的异常机制做流程控制 - 字符串输入后立刻调用
trim()，空格导致的"food "和"food"不匹配是高频 Bug
文件持久化选哪种方式更轻量可靠
小型记账不需要数据库。用 ObjectOutputStream 直接序列化整个 TransactionManager？危险——Java 序列化版本不兼容、文件不可读、升级类字段后旧数据直接报废。
立即学习“Java免费学习笔记（深入）”；
- 选 CSV 更务实：每行一条交易，字段用逗号分隔，用
Files.write()写入，用Files.readAllLines()读取 - CSV 字段顺序固定：id,accountName,amount,type,category,date,note；日期统一用
toString()（即 "2024-03-15T09:30"），读取时再 parse - 注意转义：用户备注含逗号或换行符？用双引号包裹字段，并将字段内双引号替换成两个双引号（标准 CSV 规则）
- 每次保存都覆盖全量文件，别尝试追加——否则删除某条记录后，文件里还留着脏数据
真正难的不是写完功能，是让每一笔账在重启后仍能对得上余额、分类不乱、日期不变成 1970 年——这些细节都在 TransactionManager 的增删改查契约里，不在 main 函数的 print 语句中。
