Java命令行记账工具应分三层:Transaction(纯数据)、AccountBook(CRUD逻辑)、CLI(输入解析与输出);输入用nextLine()+trim()+BigDecimal校验;文件保存采用追加写入JSON/CSV并原子替换;日期格式化须用线程安全的DateTimeFormatter。
Java 命令行记账工具不需要 GUI,关键在于把「数据模型 + 操作逻辑 + 用户交互」分层隔离。不推荐把所有代码塞进 Main 类里——否则加个导出功能就得重读 300 行。
建议按以下最小可行结构组织:
Transaction:只存字段(amount、category、timestamp),不带业务逻辑AccountBook:封装增删查改,用 ArrayList 存内存数据,暂不涉及文件持久化CLI 或 ConsoleApp:纯解析用户输入,调用 AccountBook 方法,再打印结果这样改需求时边界清晰:比如要支持多账户,只动 AccountBook;要加 JSON 导出,只新增一个 Exporter 类,不碰控制台逻辑。
Scanner 是最常用也最容易出错的输入方式。典型问题包括:nextLine() 跳过输入、数字解析异常崩溃、空输入未校验。
实操建议:
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 版本升级或类结构变动会导致反序列化失败,且文件不可读不可调试。
即使当前是单线程命令行工具,如果未来扩展成 Web 版或加异步导出,SimpleDateFormat 会立刻成为隐患——它不是线程安全的,共享实例可能导致日期解析错乱(比如把 “2025-05-20” 解成 “2025-01-01”)。
替代方案明确且简单:
DateTimeFormatter(Java 8+),它是不可变且线程安全的static final 实例,复用即可public static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
哪怕现在只是控制台工具,这个习惯能避开后续迁移时最隐蔽的并发 bug。