企业官网建设流程全解析

讲道理，控制台程序这个形态经常被初学者低估。很多人一上来就奔着Spring Boot、Web项目去，觉得黑窗口里跑出来的东西不上台面。但实际上，能把一个Java控制台程序写得结构清楚、数据可靠、交互顺手，扎实的基本功就藏在这些不起眼的细节里。今天聊的这个家庭财务管理系统，就是用纯Java在控制台里实现的一套账本工具，我把整个设计和开发过程完整拆出来，包括数据模型怎么建、文件怎么存、菜单怎么交互、哪些坑一定要避开。不管你是刚学完Java基础想找项目练手，还是正在准备面试需要梳理常见知识点的落地写法，或者单纯想给家里做一套能用的记账工具，这篇内容都能给你一份可以直接照做的参考。

1. 项目概述与整体设计思路

1.1 为什么选控制台做财务系统

在动手写代码之前，我先花点篇幅聊聊技术形态的选择。家庭财务管理系统这类工具，功能本质是数据的增删改查加统计，做成Web应用、桌面GUI或者App都行，为什么偏偏选控制台？

最直接的原因有两个。第一，控制台项目没有前端界面和框架依赖的干扰，注意力可以完全集中在Java本身的语法、集合、文件IO、异常处理、面向对象设计这些核心能力上。对一个学习阶段的人来说，这反而是最值钱的部分。第二，控制台程序的开发成本和运行成本几乎为零，不需要配置Tomcat，不需要折腾数据库，一个JDK、一个文本编辑器就能跑起来，拿来当家庭记账工具反而特别轻量。

从我个人的经验看，控制台项目做完之后，再回头看那些面试里常问的Java基础知识点，比如字符串比较、集合遍历、日期处理、文件读写、异常捕获，脑子里会清楚很多。因为你真正用它们解决过问题，而不是只在八股文里背过概念。

1.2 家庭财务系统的核心需求拆解

项目的定位是“家庭财务管理系统”，那核心需求就要围绕一个家庭的日常收支场景来设计。我当时做的第一件事不是写代码，而是把需求一条一条列出来，最后沉淀成五个功能模块。

记账是基础，任何财务系统都离不开收入和支出两条流水线。用户需要能快速记一笔收入或者一笔支出，记录时至少要包含金额、分类、日期、备注，这四个字段构成了流水的核心骨架。分类管理非常重要，没有分类的收入支出数据就是一堆数字，没办法回答“这个月吃饭花了多少钱”这种问题。所以系统要内置一套家庭常用的分类，比如饮食、交通、居住、医疗、教育、娱乐、人情往来、工资奖金、理财收益，同时允许用户自己增删改分类。

统计报表是账面数据的升华。光记不看没有意义，系统至少要能做月度汇总，算出某个月的总收入、总支出、结余，再按分类统计支出占比，让用户一眼看出钱都花在了哪里。预算提醒属于进阶但很实用的功能，用户可以给每个月设置支出上限，当累计支出超过阈值时，系统在控制台里给出提示。最后是数据持久化，程序关掉再打开数据不能丢，至少要能把流水和分类信息保存到本地文件里，启动时自动加载。

这套需求设计下来，覆盖面比较均衡。数据结构上有实体类和集合操作，业务流程上有交互循环和校验逻辑，数据层面涉及文件IO，既不会简单到没有练习价值，也不会复杂到一个人短时间做不完。

1.3 技术选型的几点考虑

技术选型遵循“够用且顺手”的原则。JDK版本我用的是JDK 8以上，主要是因为LocalDate和Lambda这两个特性在日期处理和集合操作里实在太好用。存储方案上，有人会用数据库，但对这个项目来说明显是杀鸡用牛刀，我最后选的是CSV格式的文本文件，每行一条记录，优点是人眼直接能看懂，出了问题也能用记事本打开检查。

金额处理必须用BigDecimal而不是double，这是做财务系统的基本底线。double在加减乘除时存在精度丢失问题，算钱的时候出现一分钱的误差，在真实记账场景里是很让人恼火的。日期类型用LocalDate，它比java.util.Date用起来舒服太多，格式化和解析都更直观。集合方面，存储流水用ArrayList，统计分类汇总时用HashMap，这两个是Java使用频率最高的集合类，在这个项目里能自然地把它们的用法练熟。

1.4 项目结构设计

项目结构我采用了分层思路，虽然是一个控制台程序，但代码组织上不能所有东西都堆在main方法里。我的包结构大致是这样的：

familyfinance ├── Main.java // 程序入口，负责启动 ├── model/ // 实体类 │ ├── Record.java // 流水记录 │ ├── Category.java // 分类 │ └── Budget.java // 预算 ├── service/ // 业务逻辑 │ ├── FinanceService.java // 核心业务接口 │ ├── FinanceServiceImpl.java │ └── StatisticsService.java // 统计逻辑 ├── dao/ // 数据访问 │ ├── RecordDao.java │ ├── CategoryDao.java │ └── BudgetDao.java ├── util/ // 工具类 │ ├── InputUtils.java // 输入处理 │ ├── FileUtils.java // 文件读写 │ └── DateUtils.java // 日期格式化 └── view/ // 界面交互 ├── Menu.java // 菜单渲染 └── RecordView.java // 各功能界面

这种结构借鉴了经典的分层思想：view层只负责跟用户交互，接收输入、展示输出；service层处理业务规则，比如校验金额、计算结余；dao层只管数据的读写。三个层次各司其职，后续扩展功能或者替换存储方式，改动范围能控制在一个局部，不会牵一发动全身。这也是面试中经常考察的设计原则在真实项目里的落地。

2. 数据模型与存储方案设计

2.1 三个实体类的字段设计

数据模型是整个系统的基础，字段设计得合理，后面写业务逻辑会顺畅很多。先从最核心的Record类说起，它对应一笔收入或者支出流水。

public class Record { private String id; // 唯一标识 private String type; // 类型：income / expense private BigDecimal amount; // 金额 private String category; // 分类名称 private LocalDate date; // 日期 private String note; // 备注 private String paymentMethod; // 付款方式：现金/银行卡/微信/支付宝 }

id字段默认用时间戳加随机数生成，避免流水重复。type字段只有收入、支出两种状态，我用字符串而不是布尔值，是为了让CSV文件里存的内容更直观，一眼能看出这笔记录是进账还是出账。amount用BigDecimal，这一点前面已经强调过。category存的是分类名称，虽然存分类ID更规范，但对一个家庭记账工具来说，名称更直观，而且在CSV文件里打开就能看懂。date是记账日期，默认取当天，也可以手动输入过去某一天的日期。paymentMethod虽然不算核心字段，但加上之后统计“哪个支付渠道花得多”非常方便。

Category类字段比较简单，就是名称、类型和图标标识。名称比如“餐饮”“交通”“工资”，类型用来区分这个分类是属于收入侧还是支出侧。Budget类主要字段是月份、总预算金额，还可以扩展出分类预算，但第一版我先做总额预算，逻辑简单实用。

2.2 文件持久化：CSV格式与读写实现

家庭财务系统的数据量不会太大，一个家庭一年下来也就能产生几百到上千条记录，CSV文本文件完全扛得住。CSV有一个天然优势：格式足够简单，每行对应一条记录，字段之间用逗号分隔，既方便程序解析，也方便人类手动修改。

我设计的CSV格式长这样：

id,type,amount,category,date,note,paymentMethod 20240101-0001,expense,38.50,餐饮,2024-01-03,午饭,微信 20240102-0002,income,15000.00,工资,2024-01-10,1月工资,银行卡

读写的时候有一个关键细节：金额和备注里如果出现逗号，会破坏CSV的列结构。所以我在拼接一行数据时，会把所有文本字段里的逗号替换成全角逗号“，”，读取时再替换回来。这个方法虽然简单粗暴，但对家庭记账这种场景足够有效，而且避免了引入第三方解析库的复杂度。

读取文件时，我用Files.readAllLines()一次性把整个文件读入内存，然后逐行解析。写入时最简单的做法是每次保存都全量重写文件，而不是追加一行。数据量小的时候全量写入完全没性能压力，而且天然避免了写入过程中断导致的数据错乱。每次操作结束后自动保存，这样即使程序异常退出，损失的数据也不会超过最近一次操作。

2.3 控制台交互协议的设计

控制台程序没有鼠标点击，所有操作都靠键盘输入，所以菜单设计的好坏直接决定这个工具好不好用。我采用的是经典的主菜单加子菜单结构，主菜单负责功能导航，子菜单负责具体操作。

======== 家庭财务管理系统 ======== 1. 记一笔收入 2. 记一笔支出 3. 查看流水 4. 分类管理 5. 月度统计 6. 预算设置 7. 数据备份与恢复 0. 退出系统 请输入你的选择：

交互层有一个原则必须坚持：任何时候用户输入了非法内容，程序不能崩溃，也不能让用户卡在某个死循环里，必须给出明确提示并回到正确流程。比如输入菜单序号时，用户可能输入一个“abc”，程序要捕获异常然后提示“请输入数字”。金额输入如果是负数或者为零，直接拒绝并要求重新输入。这些边界情况看上去琐碎，但正是这些细节区分了一个能用的程序和一份只能交作业的代码。

3. 核心功能实现与代码解析

3.1 记账模块：收入与支出的实现逻辑

记账模块是系统的入口，所有统计和报表都依赖流水数据的准确性。实现一笔支出记账时，流程是这样的：调用输入工具读取金额，校验金额大于零且最多保留两位小数；展示支出分类列表让用户选择，同时支持手动输入新的分类名称；日期默认是今天，如果用户需要补记之前的账，可以输入特定格式的日期；备注支持直接回车跳过。

这段代码展示了金额输入校验的核心部分：

public BigDecimal readAmount() { while (true) { String input = scanner.nextLine().trim(); try { BigDecimal money = new BigDecimal(input); if (money.compareTo(BigDecimal.ZERO) <= 0) { System.out.println("金额必须大于0，请重新输入："); continue; } if (money.scale() > 2) { System.out.println("金额最多保留两位小数，请重新输入："); continue; } return money; } catch (NumberFormatException e) { System.out.println("金额格式不正确，请重新输入："); } } }

有一个细节容易被忽略：如果用nextBigDecimal()接收输入，用户在同一个输入流里混合输入数字和文本时容易出现换行残留问题。所以我的建议是所有的输入都统一用nextLine()读入，然后在代码里做类型转换和校验。这样整个程序的输入处理规则就是一致的，从源头上规避了一类隐蔽问题。

3.2 分类管理模块：内置分类与自定义分类结合

分类管理模块做得是否顺手，直接影响用户坚持记账的动力。如果每次记账都要在一大堆无关分类里翻找，体验会非常糟糕。我设计了两套分类体系：系统内置的默认分类，以及用户自定义分类。

默认支出分类包括：餐饮、交通、居住、购物、医疗、教育、娱乐、人情、旅行、其他。默认收入分类包括：工资、奖金、理财、兼职、礼金、其他。内置分类的用意是让用户拿到程序就能直接开始记账，不需要先做一大堆设置工作。自定义分类则提供了弹性，比如用户家里有宠物，需要单独统计宠物开销，就可以新增一个“宠物”分类。

分类的数据结构比较简单，Category类包含名称、所属类型、是否内置三个字段。删除自定义分类前，系统会检查是否有流水关联到这个分类，如果有，就不允许删除，而是提示用户先把相关流水迁移到其他分类。这个小设计避免了一个很常见的异常场景：流水里的分类引用了一个不存在的分类，导致统计时出现空指针。

3.3 统计报表模块：让数据说话的核心模块

统计报表是家庭财务系统里最出彩的部分。光有一堆流水记录，用户记了一个月之后如果看不到任何分析结果，很快就会失去记账的动力。我的统计报表做成按月份快照的形式，用户可以输入2024-01这样的月份，然后系统展示完整的月度报告。

月度报告包括这样几个部分：总收入、总支出、结余、收支笔数、支出分类占比。支出分类占比这部分工作量最大，需要做三件事：筛选出指定月份的支出记录，遍历并按照分类字段将金额累加到Map里，再计算每个分类占总支出的比例。这一步天然用到了Map的合并技巧，比如：

Map<String, BigDecimal> categorySum = new HashMap<>(); for (Record r : monthRecords) { if ("expense".equals(r.getType())) { categorySum.merge(r.getCategory(), r.getAmount(), BigDecimal::add); } }

HashMap在统计场景里非常典型：key是分类名称，value是累加金额，merge方法在键不存在时直接放入初始值，存在时执行BigDecimal::add进行累加。这种写法比传统的“先判断再put”简洁很多，也避免了频繁的临时变量。报表展示时还可以顺便输出一个简易的柱状图，用等号的数量直观表示占比大小，控制台里看起来很有意思。

3.4 预算提醒模块：超支之前给个预警

预算提醒是系统里偏人性化的功能。用户可以在每个月设置预算上限，比如“2024年1月预算5000元”，然后每次记账之后自动检查：本月累计支出是否超过预算的80%，超过就在控制台输出一条醒目的提示，比如“注意：本月支出已达预算的85%”。

当累计支出真正超过预算时，提示升级为“本月支出已超过预算，请理性消费”。预算状态我设计成三个级别：正常、警戒、超支，分别用不同文本前缀标识。这个模块的业务逻辑并不复杂，核心就是每次写完流水后调用一次checkBudget方法，但它是从“记账工具”到“财务管理工具”的关键一步，因为系统开始主动给用户反馈，而不再是一个被动记录数据的存储容器。

3.5 数据持久化模块：启动加载与自动保存

数据持久化是控制台项目里最容易翻车的地方。我第一版写的时候用的是“操作完手动按5保存”的方案，结果经常忘记保存，数据丢了才追悔莫及。后来改成自动保存策略：每次增删改操作直接写文件，保证内存数据和磁盘数据始终是一致的。

启动时，程序的加载逻辑按照“分类文件先加载，流水文件后加载”的顺序执行。因为流水里的category字段要跟内存中的分类集合对应，分类先加载，才能在流水加载时对未知分类给出告警。加载完成后，控制台会打印出当前系统的数据概况：共加载多少条流水、多少个分类、最近一条流水的日期。这行提示看起来不起眼，但能立刻验证数据文件是否被正确读取。

文件路径管理上，我没有用绝对的磁盘路径，而是把数据文件放在项目根目录下的data文件夹中。程序启动时先检查data目录是否存在，不存在就自动创建，避免首次运行就报文件找不到的异常。

4. 实操过程与关键代码实现

4.1 环境准备与项目初始化

动手写代码前需要准备的东西非常少。JDK版本推荐8以上，我用的是11，编译器任选，IDEA、Eclipse、VS Code都可以，甚至直接记事本加命令行编译也能跑，因为项目没有第三方依赖。唯一要注意的是JDK安装后环境变量要配置正确，命令行里输入java -version能正常输出版本号，这是很多新手卡住的第一道坎。

新建项目时，我习惯先从实体类写起。把Record、Category、Budget三个类的字段和getter、setter先定义好，然后立刻写一个测试类，用new创建几个对象验证字段读写正常。实体类是整个系统的骨架，骨架稳定了，后面的业务逻辑写起来心里才有底。

然后写dao层。我给每个实体类都配了一个对应的Dao类，Dao内部持有内存中的集合引用，同时对外提供增删改查方法。比如RecordDao里有list、add、delete、findByMonth、findByCategory等方法。这里有一个设计取舍：集合数据是全局共享的，Main类创建Dao实例后通过参数传给各个服务类，而不是用static静态变量共享。参数传递虽然写起来啰嗦一点，但依赖关系更清晰，测试的时候也更容易构造独立环境。

4.2 service层：把业务规则从界面中隔离出来

service层是整个项目最值得花心思的地方。界面和业务逻辑如果不分开，所有代码都堆在Main方法里，前期写着爽，后期维护会崩溃。FinanceService接口我定义了这样几个方法：

public interface FinanceService { boolean addRecord(Record record); boolean deleteRecord(String id); List<Record> queryRecords(String startDate, String endDate); List<Record> queryByCategory(String category); Map<String, BigDecimal> monthlyStatistics(int year, int month); BigDecimal getMonthExpenseTotal(int year, int month); void setBudget(int year, int month, BigDecimal amount); String checkBudget(int year, int month); }

我在service层里放了一个典型的校验逻辑：删除流水时，先根据id查找记录，如果找不到就返回false并附带提示信息，找到才真正从集合中移除。这个流程避免了一个很常见的bug：用户输入一个不存在的流水编号，程序却反馈删除成功，造成界面提示和实际结果不一致。

另一个值得分享的设计是月度统计方法。我先把所有流水按月份过滤出来，然后用一次遍历同时完成收入总额、支出总额、分类汇总三个统计指标。一次遍历完成多项统计比写三个独立的循环方法效率更高，代码可读性也更好。写这个方法的时候正好练习了Java 8的Stream和Collectors.groupingBy，项目做完，这套API的基本用法也就内化了。

4.3 控制台交互层：把易用性做到控制台能做到的极限

控制台程序没有图形界面，但交互依然可以做出温度。我在view层做了几个小的交互设计，实际用起来体验提升明显。

金额、日期等输入全部采用“带提示信息的输入行”，用户输入前系统会先打印格式示例，比如“请输入日期（格式：2024-01-15，直接回车为今天）：”。这个示例文本起到锚定作用，用户不需要去翻说明文档就能完成输入。输入校验失败时，提示信息必须说明“为什么失败”，而不是简单说一句“输入错误”。比如金额校验失败，就告诉用户“金额必须大于0且最多两位小数”，这样用户知道了规则，下一步操作就不会再犯同样的错。

还有一个细节：所有列表在展示当前数据后，末尾都要带一条操作指引，比如“输入序号查看流水详情，输入back返回上级菜单”。控制台程序没有手势操作，也没有超链接，用户每一步都依赖文字提示来导航。提示信息的完整程度，直接决定这个工具是“能用”还是“好用”。

4.4 测试流程：用真实数据走一遍全流程

代码写完并不意味着项目结束，至少要跑一遍完整的测试流程，我称为“模拟一个月生活”。我在测试环境里模拟了这样一个月的流水：1月3日支出38.5元吃午饭，1月5日支出2000元交房租，1月10日收入15000元工资，1月12日支出256元买电子产品，1月18日支出88元买水果，1月25日支出45元交通费，1月28日收到500元礼金。

跑完这组数据，月度统计应该显示总收入15500元，总支出2427.5元，结余13072.5元。如果统计结果和手算对不上，说明业务逻辑里有bug，需要排查。测试时还要特意输入几组非法数据：负数金额、小数超过两位的金额、乱格式的日期、不存在的分类名称，确保程序在所有输入场景下都能优雅地回到主菜单，而不是抛出异常堆栈后退出。异常堆栈直接打在控制台里，是控制台项目最影响观感的表现，没有之一。

5. 常见问题与排查技巧实录

5.1 Scanner输入陷阱：nextInt和nextLine的恩怨

这个坑几乎每个Java初学者都会踩，我也踩过。如果用scanner.nextInt()读取菜单选项，接着再用scanner.nextLine()读取备注内容，你会发现备注读取直接被跳过了。原因是nextInt()只读取了数字，没有消费掉数字后面的换行符，紧跟着的nextLine()就把那个残留的换行符读走了，返回一个空字符串。

解决方案很简单，整个项目统一使用nextLine()读取所有输入，然后手动做类型转换。菜单序号读进来是字符串，用Integer.parseInt()转成数字，转之前先try-catch住异常。这个方案一劳永逸，整个项目中完全不存在输入类型匹配错乱的问题。我在InputUtils里封装了readLine、readInt、readBigDecimal、readDate这几个方法，所有界面层都用工具方法读取输入，而不是直接拿着Scanner到处用。

5.2 中文乱码问题的两个入口

控制台中文输出乱码，是很多新手在Windows系统下遇到的第一大魔鬼。乱码产生的原因通常是编码不一致，Java源文件的编译编码、运行时控制台的输出编码、文件读写的数据编码三个环节只要有一个不统一，显示就会出问题。

我的做法是：源文件统一保存为UTF-8，并且在启动Main方法时执行System.out.println输出时，通过JVM参数确保使用UTF-8编码。在IDEA里可以通过设置VM options为-Dfile.encoding=UTF-8解决，在命令行运行则要确认控制台代码页是UTF-8或者GBK中与文件一致的那一个。文件读写方面，使用Files.newBufferedReader和newBufferedWriter时显式指定StandardCharsets.UTF_8，避免依赖平台默认编码。数据文件一定用UTF-8保存，这样换一台电脑、换一个操作系统，打开数据文件也不会乱码。

5.3 数据文件锁死与重复读写问题

在Windows系统上，如果用户用Excel等工具打开了data文件夹下的流水CSV文件，程序再尝试全量写入这个文件时，会抛出FileNotFoundException或AccessDeniedException。原因是Excel默认锁定了打开的文件。这个问题在实际使用中很容易遇到，尤其是用户想“看看数据文件内容”的时候。

排查思路是，写入前先检查文件是否可写，捕获IOException后提示用户关闭占用文件的程序。另外，写入时不要用FileWriter直接覆盖原文件，而是先写到一个临时文件，写入成功后再用Files.move替换原文件。这种“先写临时文件再原子替换”的做法，既避免了写入中断导致文件损坏，也能减少文件被占用的窗口期。

5.4 金额比较的经典误区

判断金额是否为零，如果直接写amount == BigDecimal.ZERO，编译不会报错，但运行结果很可能不对。BigDecimal是对象，==比较的是引用地址，不是数值。正确写法是amount.compareTo(BigDecimal.ZERO) == 0。同理，判断两个包着金额的BigDecimal是否相等，也不能用equals，因为equals还会比较精度，0.5和0.50会被判定为不相等，而日常生活中它们当然是相等的。这个问题在财务系统中属于高危问题，我特意在代码注释里标注过，后来有一次重构时还是差点犯错。

5.5 数据一致性：引用一个不存在的分类

流水表中的category字段如果引用了不存在的分类，统计报表会出问题，更严重的会在获取分类名称时抛出空指针异常。我通过两条防线解决：第一，记账时分类名称优先从内存分类集合中选取，程序只提供“选择已有分类”和“新增分类”两个入口，不开放自由输入路径。第二，加载数据文件时如果发现某条流水的分类在分类表中不存在，程序会自动归属到“其他”分类，同时输出一条警告信息，而不是直接崩溃或者静默忽略。

数据备份也是一个容易被遗忘的环节。我给系统加了一个简单的备份功能：用户在主菜单中选择备份，程序会把data目录下的所有CSV文件复制到backup目录，文件名带上当前时间戳。备份文件之间互不覆盖，用户想恢复某个时间点的数据也能找到对应文件。这个功能代码量很少，但实际使用中价值极高，尤其是调整代码逻辑导致数据格式变化的时候，退路是必须有的。

6. 扩展方向与进阶建议

6.1 数据结构层面的优化方向

第一个版本的数据结构以ArrayList和HashMap为主，功能没问题，但有几个扩展点值得继续打磨。一是引入枚举类型定义收入支出类型和支付方式，替代现在的字符串，让代码更类型安全，并且配合switch表达式能减少大量if-else判断。二是给Record增加排序规则，默认按日期降序排列，日期相同的按录入先后顺序排列，这就需要在类中实现Comparable接口或者使用Comparator比较器。三是把分类ID作为流水的关联字段，而不是直接存分类名称，这样分类改名的时候流水记录不用跟着变，数据模型更规范。

6.2 分析功能与报表可视化

月度报表目前是纯文本表格，可以增加环比和同比比较，比如“本月支出较上月增加12%”“本月餐饮支出高于近三个月平均值”，这些分析能让用户对家庭财务变化趋势更敏感。还可以增加按年汇总的功能，输出全年各月收支柱状图，让一整年的财务情况尽收眼底。图表部分完全可以继续用控制台字符画实现，等号、竖线、中文字符组合起来也能做出像模像样的可视效果，不依赖任何图表库。

6.3 引入序列化与日志机制

如果不想继续用CSV，可以把存储方案换成Java对象序列化，ObjectOutputStream直接保存对象集合。缺点是文件是二进制的，无法用文本编辑器直接查看，但优点是读写代码大幅简化，对象结构直接保留。引入日志机制也是一个不错的进阶方向，用java.util.logging或者简单的自制日志工具记录每次记账操作的时间、操作类型和结果，这样出了问题可以追踪操作历史，对家庭记账场景来说也有一种“对账”的感觉。

6.4 学习路线的衔接

这个项目做完之后，如果要继续往更工程化的方向走，可以把它改造成Spring Boot后端项目，CSV文件替换成MySQL数据库，控制台界面换成RESTful API，再用一个简单的前端页面调用接口，一个完整的全栈项目就出来了。中间涉及的Java知识点，比如集合、IO、异常、日期、Lambda、Stream，都是共通的。也就是说，现在写的这些基础代码，在未来技术栈升级时不会白费，它们会沉淀成你对Java语言本身的理解。这就是为什么我一直建议初学者认真做一个控制台项目，它像是在打地基，房子还没盖起来，但地基的每块砖都决定了未来能盖多高。

最后再分享一个我自己的习惯。项目做完之后，我并没有把它丢到角落里，而是真的用了几个月记录每天的日常开销。用真钱记账和用测试数据跑程序完全是两种体验，真实使用中会发现很多当初设计时没考虑到的场景，比如退款怎么记、跨月预算怎么处理、共同账户怎么区分。这些来自真实场景的问题，会引领你把项目不断改得更好，也会让你的Java能力和业务理解能力同步成长。这大概就是做一个小而完整的项目，比刷一百道面试题更有收获的地方所在。