用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 默认不校验格式，得自己兜底。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 读取金额时，用 scanner.hasNextDouble() 判断再 nextDouble()，而不是直接 nextDouble() 后 catch
• 解析日期用 DateTimeFormatter.ofPattern("yyyy-MM-dd")，并 try-catch DateTimeParseException，提示“请输入 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 语句中。