Java命令行记账工具应分三层：Transaction（纯数据）、AccountBook（CRUD逻辑）、CLI（输入解析与输出）；输入用nextLine()+trim()+BigDecimal校验；文件保存采用追加写入JSON/CSV并原子替换；日期格式化须用线程安全的DateTimeFormatter。
命令行记账工具的核心结构怎么组织
Java 命令行记账工具不需要 GUI，关键在于把「数据模型 + 操作逻辑 + 用户交互」分层隔离。不推荐把所有代码塞进 Main 类里——否则加个导出功能就得重读 300 行。
建议按以下最小可行结构组织：
-
Transaction：只存字段（amount、category、timestamp），不带业务逻辑 -
AccountBook：封装增删查改，用ArrayList<Transaction>存内存数据，暂不涉及文件持久化 -
CLI或ConsoleApp：纯解析用户输入，调用AccountBook方法，再打印结果
这样改需求时边界清晰：比如要支持多账户，只动 AccountBook；要加 JSON 导出，只新增一个 Exporter 类，不碰控制台逻辑。
如何安全读取用户输入并避免 Scanner 的坑
Scanner 是最常用也最容易出错的输入方式。典型问题包括：nextLine() 跳过输入、数字解析异常崩溃、空输入未校验。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 统一用
scanner.nextLine()读所有输入，避免nextInt()+nextLine()混用导致换行符残留 - 金额输入必须用
BigDecimal解析字符串，不用Double.parseDouble()—— 否则0.1 + 0.2 != 0.3 - 所有输入都做非空和格式校验，例如分类名不能是空白或纯空格，用
input.trim().isEmpty()判断
String input = scanner.nextLine().trim();
if (input.isEmpty()) {
System.out.println("错误：输入不能为空");
continue;
}
BigDecimal amount = new BigDecimal(input); // 不用 Double
数据怎么保存到文件且不丢记录
记账工具一旦关掉就丢数据，用户会直接弃用。用 FileWriter 直接覆盖写入是常见错误——程序崩溃时整个账本可能被清空。
更稳妥的做法：
- 每次新增/修改后追加写入（
new FileWriter(file, true)），每条记录一行 JSON 或 CSV 格式 - 启动时从文件逐行读取并重建
AccountBook，遇到解析失败的行跳过并记录警告（不要抛异常中断加载） - 如需原子性，可先写临时文件（
data.json.tmp），成功后再Files.move()替换原文件
注意：不要用 ObjectOutputStream 序列化——Java 版本升级或类结构变动会导致反序列化失败，且文件不可读不可调试。
为什么 SimpleDateFormat 在多线程下会出错
即使当前是单线程命令行工具，如果未来扩展成 Web 版或加异步导出，SimpleDateFormat 会立刻成为隐患——它不是线程安全的，共享实例可能导致日期解析错乱（比如把 “2024-05-20” 解成 “2024-01-01”）。
替代方案明确且简单：
- 用
DateTimeFormatter（Java 8+），它是不可变且线程安全的 - 声明为
static final实例，复用即可 - 格式字符串别硬编码，提取成常量，比如
public static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
哪怕现在只是控制台工具，这个习惯能避开后续迁移时最隐蔽的并发 bug。
