Java家庭财务管理系统APP毕设全解析：架构、数据库与答辩要点

1. 项目定位：这是个什么样的毕设选题

家庭财务管理系统放在计算机毕业设计里，属于“看起来很常见，但要做好并不容易”的经典选题。它既是移动应用开发题，又是信息管理系统题，还带了一点数据分析的味道。换句话说，这个题目把一个本科生应该掌握的大部分后端与客户端技术都串了起来，而且业务场景人人都懂，答辩时不需要花大量时间给评委解释项目背景，重点能放在技术实现上。

标题里反复提到的“Java家庭财务管理系统APP”，把它拆开其实就是三部分：移动端负责采集和展示数据，Java后端负责处理业务逻辑，数据库负责持久化数据。业务闭环可以概括为“记账、管账、分析账”。记账是把每一笔家庭收支记录入库，管账是围绕账户、分类、预算做日常管理，分析账则是对一定周期内的数据进行统计并形成图表，辅助家庭做消费决策。

我在带毕设和评审项目的过程中，一直觉得这类题目最适合基础中等、想做出一个完整可演示项目的学生。它的难度不像人工智能或大型分布式系统那样高不可攀，但也不是单纯的CRUD增删改查。如果认真做，能从数据库建模、接口设计、客户端交互、数据可视化一条链路得到完整训练；如果敷衍了事，也很容易做出一个只有网页端或者功能残缺的半成品。希望这篇总结能给正在做类似项目的同学一些可落地的参考。

需要注意一个现实问题：家庭财务管理系统属于信息管理类项目，很多同学容易把它做成一个“通用记账软件”的换皮版本。为了避免这个问题，建议一开始就把“家庭”这个场景做透。家庭和个人的区别在于多成员、多账户、预算共享、账单归属明确，这些特征都要在功能设计里体现出来。比如一张支出账单需要记录“谁花的钱”和“花在哪个家庭成员身上”，预算可以按家庭成员分别设置，首页数据看板要展示家庭当月总支出和剩余预算。把这些细节做出来，项目才真正有辨识度。

2. 功能设计与模块拆分：从需求到可落地的功能清单

2.1 核心需求梳理

做毕设的第一步不是写代码，而是把答辩时要展示的功能点想清楚。我习惯用“角色 + 场景 + 动作”的方式去拆需求，也就是问自己三个问题：谁在用这个系统？在什么场景下用？用了之后要完成什么动作？

家庭财务管理系统的主要使用者是家庭成员，典型场景有：买菜后记录一笔支出、月底查看结余、月初设置消费预算、年末看年度支出分布。把这些场景翻译成功能点，可以归纳成五个模块：

• 用户模块：注册、登录、个人信息维护，这是系统访问的入口。
• 账户管理模块：维护家庭名下的多个账户，比如日常储蓄卡、信用卡、现金账户，记录账户余额并支持交易流水联动。
• 收支记账模块：记录收入和支出流水，包含金额、分类、账户、成员、备注、时间等核心字段，支持按条件查询与编辑删除。
• 预算管理模块：按月为不同分类设置预算额度，统计已用额度并计算剩余比例，超支时给出提醒。
• 统计分析模块：按日、周、月、年维度的收支趋势图，按分类维度的占比图，同时提供账单明细列表。

这五个模块里，用户模块和账户管理模块是基础，收支记账模块是核心，预算管理和统计分析是亮点。很多同学做项目时会卡在预算和统计这两个模块，因为涉及的判断逻辑和聚合查询比单纯增删改查复杂。但从答辩角度看，恰恰是这两个模块最能体现设计能力和编码水平。

2.2 功能优先级与版本规划

做毕设最忌讳一上来就想把所有功能做全。我建议把开发分成两个阶段，先完成基础版本，再做进阶优化。

基础版本需要优先保证：注册登录流程完整，登录后能看到首页的账户总览，能正常记一笔支出和一笔收入，能在流水中看到历史记录并且可以修改删除。这个版本对应的是项目能够跑通、演示不翻车。

进阶版本再去补：预算设置与超支提醒、图表统计、家庭成员管理、账单筛选和搜索、个人中心的数据汇总。这一步对应的是答辩时的加分项。实际操作中，我通常建议学生先花三到五天把基础版本跑通，剩下时间再慢慢往里面加亮点功能。因为很多同学高估了自己的编码速度，低估了联调和排查问题的时间，基础版本拖得越久，后期越容易被烂摊子缠住。

2.3 模块之间的调用关系

模块设计不能只是脑内想象，要有清晰的调用关系。我的习惯是先画出数据流向，再据此设计接口。记账这个核心流程的数据流向是：用户在Android客户端填写账单表单，客户端调用后端的记账接口，后端校验参数后写入数据库的流水表，同时更新对应账户的余额，刷新预算使用额度，最后把处理结果返回给客户端。

这里有一个关键点：更新账户余额不应该由客户端来做。有些同学图省事，在客户端收到成功结果后本地把余额显示改一下，后端不更新，这样数据一致性很容易出问题。正确做法是后端在事务内完成流水插入和余额变动两步操作，客户端只负责展示后端返回的新余额。

数据流向清晰之后，接口也好设计了。按REST风格来划分：

• POST /api/user/register 与 POST /api/user/login，完成用户注册和登录，返回用户信息和令牌。
• GET /api/account/list 获取当前用户的账户列表，GET /api/account/detail/{id} 获取账户详情，POST /api/account/create 新增账户。
• POST /api/transaction/create 新增收支记录，GET /api/transaction/list 分页查询流水，PUT /api/transaction/update 修改流水，DELETE /api/transaction/delete 删除流水。
• GET /api/statistics/overview 获取首页统计概览，GET /api/statistics/monthly?month=2024-05 获取月度收支趋势。
• GET /api/budget/current 获取当前预算，POST /api/budget/set 设置预算额度。

接口写清楚，前后端联调时会省很多力气。

3. 技术选型与架构设计：为什么我选这套技术栈

3.1 客户端：为什么是原生Android而不是跨端方案

家庭财务管理系统APP这一块，很多同学会在“原生Android”和“跨平台方案”之间纠结。我的建议是：除非你有明确的多端发布需求，否则毕设老老实实选原生Android，使用Java或Kotlin开发。

原因很简单，第一是原生开发入门资料多，遇到问题容易搜索到现成答案；第二是毕设答辩更看重你是否理解底层机制，原生开发中涉及的Activity生命周期、权限申请、数据存储都是评委比较关心的技术点；第三是跨端框架虽然开发效率高，但调试和构建环境本身就可能消耗大量时间，对毕设来说风险大于收益。

UI层可以适当使用一些轻量组件。列表展示用RecyclerView配合Adapter实现，图表部分用开源库MPAndroidChart，网络请求用OkHttp和Gson解析JSON，图片加载如果有需要可以用Glide。这些选型都是业界经过大量项目验证的稳定方案，踩坑概率小，适合毕设这种“求稳”的项目。我见过不少学生在图表库上反复折腾，最后答辩前一天才能跑出图，实在没有必要。MPAndroidChart足够成熟，支持折线图、饼图、柱状图，完全够用。

3.2 后端：Spring Boot是当下最稳妥的选择

如果倒回五六年，后端方案可能还在JSP和SSM之间争论。但放到现在，Spring Boot基本是唯一需要认真考虑的选项。它的自动配置机制省掉了大量XML配置，内嵌Tomcat让项目可以一键启动，Spring全家桶的生态让它集成MyBatis、MySQL、Redis等组件都非常方便。

很多学生担心Spring Boot“太高级”，学起来有难度。其实从毕设角度，不需要把Spring Boot的所有原理都吃透，只需要理解几个核心机制：控制层用@RestController接收请求并返回JSON，业务层用@Service管理业务逻辑，数据访问层用@Mapper交给MyBatis处理SQL。依赖注入、自动配置、统一异常处理这三个概念搞明白，就足以完成一个功能完整的后端项目。

另外提一句，千万不要为了展示技术实力引入一堆用不上的组件。比如引入Redis做缓存，或者引入RabbitMQ做消息队列，如果业务场景撑不起来，答辩时被追问细节很容易翻车。技术选型的核心原则是“匹配业务复杂度”，家庭财务管理系统用单数据库加Spring Boot足够，引入微服务和消息中间件反而画蛇添足。

3.3 数据库与其他组件：基础但关键

数据库选择上，MySQL 5.7或8.0都是常见选择，证明材料里建议写“MySQL 5.7以上版本”，既不过时又兼容性稳定。ORM框架用MyBatis或MyBatis-Plus都可以，我个人在实际项目中更常用MyBatis-Plus，因为内置的BaseMapper提供单表CRUD，可以直接少写大量重复的XML映射文件。

服务端部署方面，Spring Boot内置的Tomcat已经满足需求，不需要额外外置容器。开发调试时数据库与后端都跑在本地，部署演示时也可以在同一台机器上全部搞定，这对答辩场地的网络不确定性是个天然优势。

客户端与服务端的通信协议必须统一，这里我推荐JSON格式配合HTTP协议。接口返回结构建议封装成统一的类：code、message、data三个字段，code为0表示成功，非0表示业务异常，客户端根据code统一弹出提示。这套设计能让前后端联调过程顺畅很多，不用每个接口单独处理异常场景。

架构层面，整个项目可以简化成三层：展示层（Android客户端）、业务层（Spring Boot接口）、数据层（MySQL数据库）。以家庭财务系统“多成员、多账户”的业务场景，合适架构的画像就是：轻客户端、富后端、单数据源，逻辑清晰、扩展容易，未来如果要做智能推荐或消费趋势预测，完全可以在后端服务内增加模块实现。

4. 数据库设计：七张核心表的建模与关系梳理

4.1 表结构总览

数据库设计是整个项目的“地基”。地基没打好的后果是：功能写着写着就发现查询越来越别扭，表达不清某张表到底该放哪些字段，甚至出现冗余数据靠代码硬撑。家庭财务管理系统的核心数据对象包括用户、家庭成员、账户、分类、收支流水、预算和系统附件，我最终拆成了七张核心表：

• user（用户表）：存储登录账号密码
• member（家庭成员表）：存储家庭成员的姓名、角色、可用状态
• account（账户表）：存储家庭名下的资金账户信息
• category（分类表）：存储收支持分类
• transaction（收支流水表）：存储每一笔收入和支出明细
• budget（预算表）：存储每个分类的月度预算额度
• attachment（附件表）：可选，存储账单图片或凭证的路径

七张表里，transaction表是核心，user表是入口，category与budget是亮点功能的支撑。表的关系可以用简单的话描述：一个用户拥有多个家庭成员，家庭成员可以拥有多个账户，一个分类可以对应多条流水，一张预算表记录某个分类在某个月份的计划额度。流水表通过字段关联到用户、成员、账户和分类，形成一个星型结构，查询统计时大量通过JOIN把表关联起来。

4.2 核心表字段设计

设计字段时最需要关注的是类型选择、默认值、约束条件和索引设计。以transaction表为例，每个字段我都展开说一下选型背后的考虑。

• id：流水表主键，用BIGINT自增即可，不建议用字符串UUID做主键，虽然业务上更安全，但作为频繁插入的表，UUID的随机性会导致B树索引频繁页分裂，在大数据量下性能明显变差。
• user_id：关联用户表的逻辑外键，BIGINT类型。这是“家庭”场景的核心字段，所有数据必须归属到某个用户下，查询时默认带上这个条件，避免跨用户数据串扰。
• member_id：关联家庭成员表，记录这笔流水是谁花的钱或谁收到的钱。一个家庭里多个成员共用一个账户，如果不知道是“谁”花的，后续做成员消费排行就无法实现。
• account_id：关联账户表，记录这笔交易发生在哪个账户。
• category_id：关联分类表，记录这笔收支属于哪个分类，比如餐饮、交通、日用、工资、理财收益等。
• amount：交易金额，DECIMAL(10,2)，单位是元，保留两位小数。这里有个常见误区：不少同学喜欢用DOUBLE或FLOAT存金额，这会在精度上埋雷，因为浮点数无法精确表示十进制小数，统计时会累计误差，如果未来接入支付相关流程会造成对不上账的严重问题。一定要用DECIMAL。
• type：交易类型，TINYINT类型，0表示支出，1表示收入。这里不用字符串“income”或“expense”，原因是枚举值用数字最节省查询开销，且Java代码里只要定义好常量，可读性完全不受影响。
• happen_time：交易发生时间，DATETIME类型，精确到秒。注意别用字符串存时间，也别只存日期忽略时分秒，因为后续按小时维度分析时会缺数据。
• remark：备注，VARCHAR(255)，允许为空，用户可以不填。
• create_time与update_time：记录创建时间和最后修改时间，DATETIME类型。

其余表的设计思路类似。user表除了id与账号密码，还会放nickname、avatar_url、status、create_time。member表放member_name、role_type、is_active。account表放account_name、account_type、initial_balance、current_balance。category表放category_name、category_type、is_deleted、sort_order。budget表比较特殊，需要唯一约束（user_id和category_id与month组合），用来保证一个用户在某个月内对同一个分类只能有一条预算记录。

4.3 建表SQL与索引规划

以MySQL为例，事务流水表的建表SQL可以写成下面这样：

CREATE TABLE `transaction` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `user_id` BIGINT NOT NULL COMMENT '所属用户ID', `member_id` BIGINT DEFAULT NULL COMMENT '家庭成员ID', `account_id` BIGINT NOT NULL COMMENT '账户ID', `category_id` BIGINT NOT NULL COMMENT '分类ID', `amount` DECIMAL(10,2) NOT NULL COMMENT '交易金额', `type` TINYINT NOT NULL COMMENT '交易类型：0支出 1收入', `happen_time` DATETIME NOT NULL COMMENT '交易发生时间', `remark` VARCHAR(255) DEFAULT NULL COMMENT '备注', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间', PRIMARY KEY (`id`), KEY `idx_user_time` (`user_id`, `happen_time`), KEY `idx_account_id` (`account_id`), KEY `idx_category_id` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='收支流水表';

索引设计在毕设里是很容易被忽视但答辩必问的点。上面这张表我建了四个索引：主键索引保证记录唯一并加速等值查询，idx_user_time是一个复合索引，专门服务“某个用户在某段时间内的账单列表”这一类高频查询，同时兼顾了排序，因为复合索引的第二个字段已经是有序的。账户和分类两个单列索引则服务于按账户或分类筛选的场景。这里要提醒一点：索引不是越多越好，每多一个索引都会拖慢写入速度，并占用额外存储空间，只给高频查询字段建索引就够了。

预算表同样要强调唯一约束：

CREATE TABLE `budget` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键ID', `user_id` BIGINT NOT NULL COMMENT '所属用户ID', `category_id` BIGINT NOT NULL COMMENT '分类ID', `month` VARCHAR(7) NOT NULL COMMENT '预算月份，格式yyyy-MM', `amount` DECIMAL(10,2) NOT NULL COMMENT '预算金额', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_cat_month` (`user_id`, `category_id`, `month`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预算表';

这里用VARCHAR(7)存月份，比如“2024-05”，比DATE更直观，也避免日期格式化带来的复杂度。唯一约束的价值在于：当用户再次设置同一月份同一分类的预算时，后端可以先做查询再决定新增还是更新，也可以直接用INSERT ... ON DUPLICATE KEY UPDATE 让数据库去重，代码更简洁。

5. 核心功能实现：从“能记账”到“会分析”

5.1 记账主流程与事务控制实现

记账功能是整个系统的心脏。用户填完表单点击保存，后端要完成五件事：校验参数、判断收支类型、插入流水记录、更新账户余额、触发预算使用量更新。

这里最容易被忽略的是事务控制。假设用户同时选择了“银行卡”账户和“餐饮”分类，如果插入流水成功但账户余额没有减少，数据就产生了不一致。Spring Boot中处理事务非常简单，在Service层方法上添加@Transactional注解即可。只要方法内抛出运行时异常，数据库就会自动回滚之前提交的所有操作。

账户余额的更新逻辑要注意并发问题。如果家庭成员在同一个账户上同时发起两笔消费，后更新的余额可能覆盖先更新的余额。这其实不应该由Java代码加锁来处理，因为你锁不住多实例和数据库事务的隔离级别，最好的方案是使用SQL原子更新：

UPDATE account SET current_balance = current_balance - #{amount} WHERE id = #{accountId} AND current_balance >= #{amount}

这个SQL自带“余额校验”和“原子更新”两个能力：如果余额不足，影响行数为0，业务层就能感知到“余额不够用”并给出提示。用这种数据库层面的原子操作，可以把并发问题消解在最底层，Java代码里则完全不需要自己管理锁。

分类与账户的校验也不可跳过。用户在客户端虽然已经做了输入限制，但接口是公开的，恶意请求可以直接拼接参数绕过前端。后端需要确保category_id确实属于当前用户，account_id也存在，避免越权操作。

5.2 统计报表的多维度查询实现

统计模块是答辩时最能出彩的部分。实现它不需要多复杂的算法，关键是写出正确的聚合SQL，再配合图表库把数据可视化。

月度收支趋势的数据来源是先按月分组，再计算总额。以按天统计某月的支出趋势为例，SQL核心逻辑是：

SELECT DATE_FORMAT(happen_time, '%Y-%m-%d') AS day, SUM(amount) AS total FROM transaction WHERE user_id = #{userId} AND type = 0 AND happen_time BETWEEN #{startTime} AND #{endTime} GROUP BY DATE_FORMAT(happen_time, '%Y-%m-%d') ORDER BY day

这条SQL要过滤掉type=0只统计支出，并且用DATE_FORMAT把DATETIME格式化到天维度。如果把统计周期改成月或年，只需要调整格式化字符串：%Y-%m表示月，%Y表示年。

分类占比图的核心是按分类分组：

SELECT c.category_name, SUM(t.amount) AS total FROM transaction t LEFT JOIN category c ON t.category_id = c.id WHERE t.user_id = #{userId} AND t.type = 0 AND t.happen_time BETWEEN #{startTime} AND #{endTime} GROUP BY t.category_id ORDER BY total DESC

这两条SQL拿到服务端之后，可以封装成统一的统计结果类返回前端。前端拿到数据之后用MPAndroidChart绘制图表，饼图展示分类占比，折线图展示月度趋势，柱状图展示每日支出。这样一个完整的统计看板就在客户端呈现出来了。

有一个实用技巧要分享：统计接口尽量在后端完成聚合计算，不要在客户端拿到明细后再循环累加。后端一条SQL解决的问题，客户端可能要发起上百次请求，而且网络传输数据量大、用户体验差。把计算压力放在数据库上，是合理且务实的做法。

5.3 预算超支提醒的实现方案

预算模块的实现分两部分：预算设置和超支预警。

预算设置功能对应budget表的插入或更新。客户端传递分类ID、月份、金额，后端判断该分类该月份是否有历史预算，有就更新，没有就插入。这里可以适当加一个限制，预算金额必须大于零且不超过某个上限，保证数据的合理性。

超支预警有两种常见的实现时机。第一种是记账时实时监控：每新增一笔支出，就把该分类在当前月份的已用金额和预算金额做对比，如果超出则返回一个提示字段，客户端据此弹出“该分类预算已用90%”这样的警告。第二种是进入首页时进行整体扫描：查询当前月份所有分类的预算使用情况，把所有超支项整理成列表展示在首页的提醒卡片里。

我建议两种方式同时用。记账时的实时预警能第一时间反馈给用户，首页的整体提醒则方便用户查看全局情况。这两种方式都依赖一条聚合SQL：按分类计算某月份已用支出。把它封装成方法之后，两个场景都能复用。

预算使用比例的统计逻辑如下：先按用户和月份查出一组预算记录，再对每个预算分类执行月度支出汇总，然后用已用金额除以预算金额得出使用率。使用率阈值的经验值可以设成：小于70%显示绿色，70%到100%之间显示橙色，超过100%显示红色并触发“已超支”文案。这样不仅有数据的准确性，还有一定的交互质感。

5.4 客户端登录与会话管理

登录是每个应用必备的模块，但很多毕设项目的登录都做得“表象化”，只是在前端跳转页面，服务端完全不校验是否登录。这样做很容易被评委问到“怎么保证用户只能看到自己的数据”这类问题。

推荐做法是使用令牌机制。用户登录成功后，后端生成一个随机字符串token，把token保存到服务端（可以用表存储，也可以用Redis），同时返回给客户端。客户端后续每次请求都在请求头中携带token，后端通过拦截器校验token是否有效，无效则返回401状态码，客户端收到后自动跳转回登录页。

令牌机制比在每个接口里反复判断“是否登录”要优雅得多，也符合真实开发场景的做法。如果你没有引入Redis，可以直接把token字段放到user表中的token_column里，实现成本很低，答辩时也能讲清楚原理。

5.5 UI设计细节与交互体验

客户端UI是整个项目给人第一印象的地方，值得认真打磨。没必要做得花哨，但要做到干净整齐。首页我习惯放成三块区域：顶部是本月收支和结余的概览卡片，中部是各账户余额和总资产的横向排列卡片，底部是分类预算的使用进度条。这样用户在打开APP的第一眼就能看到最重要的信息。

配色方面建议使用柔和的浅色系，比如淡蓝配白底或者浅绿配白底，避免高饱和颜色。字体大小保持层级清晰：标题18到20sp，正文14到16sp，辅助说明12sp。控件的圆角统一，按钮的点击状态要设计按下反馈，列表滑动要流畅。

列表页的交互细节也要考虑。账单列表可以按时间倒序展示，每条记录显示分类图标、备注、金额正负色（收入绿色、支出红色）。支持下拉刷新和水波动画，提供加载更多分页能力。筛选条件可以做成顶部标签栏，按月、按分类、按类型快捷过滤。这些交互虽然实现成本不大，但对完成度的提升非常明显。

6. 毕设过程里的常见问题与答辩准备

6.1 开发过程中最常见的四个问题

第一个问题是时间字段类型混乱。有的同学在数据库里用VARCHAR存放交易时间，导致后续统计年月日时都要用字符串函数转换，效率低还容易出错。解决办法是建表时统一用DATETIME，Java实体类里用LocalDateTime与之对应。

第二个问题是金额精度丢失。这个问题很隐蔽，表面上看不出Bug，但当支出累计到一定金额时，统计结果会出现“差几分钱”的诡异现象。原因就是把DECIMAL字段映射成了DOUBLE或FLOAT。解决办法是Java实体类中金额字段用BigDecimal，数据库用DECIMAL(10,2)，两者严格对应。

第三个问题是分类和账户的下拉框经常出现“空数据”。排查思路是先检查登录用户的ID是否传到后端，再检查分类表里是否真的录入了数据。很多同学在开发阶段测试数据录得少，容易误判为接口错误，其实大多数是初始化数据缺失。

第四个问题是Android端网络请求失败。常见原因包括：模拟器或真机访问10.0.2.2和宿主机地址的差异性、服务端没有配置跨域、请求头缺少token、JSON解析失败。排查时先用Postman确认服务端接口正常，再在客户端打开日志确认网络请求是否发出，一层一层缩小问题范围。

类似的排查经验我整理成了一个速查表：

6.2 答辩时的功能演示路线

答辩时间通常有限，演示路线要提前设计好，不能随意乱点。我建议按照这条主线走：注册登录 → 创建账户与家庭成员 → 新增几笔收入和支出 → 查看流水与修改删除 → 查看统计图表 → 设置预算并演示超支提醒 → 总结系统特点。

这条主线的设计逻辑是“完整业务闭环”。每一步都衔接上一个步骤的数据，评委不会觉得跳跃。最后收尾时把技术点的总结放在一张PPT上：后端采用Spring Boot与MyBatis-Plus、移动端采用原生Android、数据库设计上通过7张表建模家庭财务场景、记账事务保证数据一致性、统计报表通过聚合SQL优化性能。

6.3 答辩中被高频追问的十个技术点

• 为什么用Spring Boot而不用传统的JSP和Servlet？回答思路：自动配置降低开发成本、内嵌Tomcat利于部署、生态丰富易于扩展。
• BigDecimal和double有什么区别？回答思路：double采用浮点表示，无法精确表示十进制小数；BigDecimal使用字符串与整数组合表示，精度可控。
• 预算超支提醒是怎么实现的？回答思路：新增记账时在事务内完成预算使用量统计，超预算则返回提示字段。
• 查询统计性能怎么优化？回答思路：核心是SQL层面做聚合，对user_id和happen_time建立复合索引，避免全表扫描。
• 事务在哪个层加？加所有方法还是只加写操作？回答思路：写操作加@Transactional，读操作不加；事务粒度尽量控制在业务方法范围，避免过长事务占用连接。
• 密码是怎么存储的？回答思路：使用MD5加盐或BCrypt不可逆加密，数据库不存放明文密码。
• 图表数据是前端算还是后端算？回答思路：后端执行聚合SQL计算，前端只做展示，减少网络数据量。
• 如果用户删除了一个家庭成员，历史账单怎么办？回答思路：采用逻辑删除，is_active置为0，历史数据保留，账单查询过滤失效成员。
• 为什么数据库表要加user_id？回答思路：这是数据隔离的关键字段，确保多用户之间数据不串扰。
• 如果APP要支持多端登录怎么办？回答思路：token机制支持一个用户生成多个有效token，每个设备独立维护会话。

6.4 论文撰写时的建议

论文和技术实现是“一对孪生兄弟”，不能代码写完了再反过来补论文。我建议边开发边写，把每天的进展记录成文档，最后按章节整理成一篇完整论文。论文框架可以这样安排：绪论部分介绍背景和意义，相关技术部分介绍Spring Boot、Android、MySQL等技术，需求分析部分画用例图和流程图，系统设计部分写架构图和功能设计，数据库设计部分放表结构和ER图，系统实现部分配合截图写关键代码，测试部分写功能测试和接口测试。其中系统实现部分是论文的核心，每个功能模块建议都配一张界面截图加一段核心逻辑说明，避免纯贴代码的流水账。

论文里的每一个架构图和ER图建议自己画，不要直接截图IDE。Visio、draw.io都可以，画完之后统一风格，整体观感会好很多。

7. 写在最后的个人体会

带过不少学生和项目之后，我愈发觉得毕业设计最考验人的不是编程能力，而是“项目推进能力”。真正开始做Java家庭财务管理系统这个题目前，先把需求文档和数据库设计写清楚，后面代码的推进速度能快一倍；反之，边写代码边改需求，很容易陷入一个月改了四版数据库表的困境。

在具体操作上，我建议每天给自己定一个可验证的小目标，比如“今天完成注册登录接口”“今天完成首页统计看板的折线图”“今天完成预算模块的SQL聚合查询”。每个小目标都带着一次可运行的验证，积少成多，项目自然就立起来了。

最后再分享一个小技巧：答辩前一定准备一份带演示数据的环境，不要现场造数据。提前在数据库里录入两三周内几十笔覆盖多个分类、多个账户的流水，把预算设得略低于已用金额，这样演示时既能展示图表效果，又能触发超支提醒，整个流程下来一气呵成，评委看到的“完成度”和临时造数完全不一样。这个细节，值得每一个准备毕设答辩的人认真对待。