★ FEATURED ARTICLE 1. 项目整体设计与思路拆解1.1 家庭财务管理系统到底在解决什么问题家庭财务管理系统这个题目在毕业设计里属于经久不衰的经典款。原因很简单一是业务场景足够清晰谁家都有记账需求需求分析好写二是技术栈覆盖面广SSM Vue能把你大学四年学的东西串起来展示三是扩展空间大从最简单的收支记录到预算管理、账单统计、家庭成员角色分配层层递进论文篇幅和代码工作量都好把控。先明确一下这套系统的核心定位它不是给企业用的专业财务软件而是服务于一个家庭或一个小团队的日常收支管理工具。围绕这个定位系统至少要具备三大核心能力账目记录收入、支出、分类、账目查询多条件筛选、时间段统计、数据可视化图表展示收支趋势和结构。在此基础上加上用户管理、家庭成员管理、预算管理等模块就构成了一个完整的毕设项目。我见过不少同学在这个项目上踩坑最大的问题不是写不出代码而是把需求想得太大。有的同学一上来就要做多租户SaaS、要做人工智能账单分类、要做数字货币钱包对接结果写到一半发现自己hold不住论文也圆不回来。记住毕设的核心是把你掌握的技术完整地、规范地展示出来而不是搞科研创新。把家庭财务管理系统做好做实SSM Vue这套组合足以体现你的后端接口设计能力、数据库设计能力和前端页面交互能力。1.2 为什么选SSM Vue这套技术组合这几乎是当前Java方向毕设项目的标准答案了。简单说一下为什么是它而不是Spring Boot 模板引擎也不是Spring Cloud微服务全家桶。SSM是指Spring SpringMVC MyBatis三件套它代表了Java Web开发从传统Servlet时代走向轻量化配置时代的典型技术栈。选它的意义在于第一教学体系中Spring、MyBatis都是核心课程用它们做项目能直接检验课堂所学。第二SSM的配置过程相对繁琐恰恰是这个“繁琐”能让你论文里有一章写环境搭建和框架整合答辩的时候也有东西可讲。第三相比Spring Boot的“自动配置一切”SSM需要你手动管理Bean、配置事务、处理Mapper映射这逼着你去理解底层机制而不是当一个只会调用注解的工具人。Vue那边选Vue 2还是Vue 3是个需要权衡的问题。学校课程大多教的还是Vue 2而且Element UI这个组件库在Vue 2环境下特别成熟网上参考资料最多。如果你对Vue 3的Composition API足够熟悉选Vue 3 Element Plus也没问题。我个人建议是以稳妥为主你自己上课学的是哪个版本就用哪个版本不要为了追新给自己挖坑。后端接口用RESTful风格设计前端Axios发请求JSON格式传数据这套配合打得很顺。1.3 论文与程序如何两条腿走路毕设答辩最怕的一种情况是代码跑起来了但是论文写得像流水账导师问几个“为什么”就卡壳。程序和论文必须同步考虑而不是先写完代码再憋论文。正确的做法是先整理需求文档画出用例图和ER图明确系统有哪些角色、每个角色能做什么、数据库表怎么设计。这一步既是论文的第二章需求分析和第三章系统设计的底稿也是后面写代码的施工蓝图。千万别跳过设计直接上手写代码不然写到后面逻辑混乱前端调接口调得想砸电脑。论文的结构通常遵循绪论背景、意义、国内外研究现状→ 相关技术介绍 → 需求分析 → 系统设计 → 系统实现 → 系统测试 → 总结与展望。其中相关技术介绍是好写的部分把SSM、Vue、MySQL、Element UI各写一节配上架构图需求分析和系统设计是核心直接体现你对项目的理解深度系统实现是重头戏每个模块要配合页面截图和核心代码片段说明。2. 核心细节解析与实操要点2.1 数据库设计是系统的地基家庭财务管理系统的数据库设计我建议从“用户-账目-分类-预算”这四个核心实体入手把关系理顺了后面的开发会流畅很多。用户表user是系统的入口字段包括用户ID、用户名、密码、真实姓名、角色其中密码一定要加密存储。这里插一句很多同学图省事用明文存密码这是答辩时导师最常挑的毛病之一。用MD5加盐或者BCrypt都行后者更安全。角色字段区分管理员和普通家庭成员管理员能管理分类、查看所有成员的账目普通成员主要维护自己的账目。账目表bill是核心业务表字段建议这样设计账单ID、用户ID外键、分类ID外键、类型收入/支出、金额、发生日期、备注、创建时间。这里有几个细节需要注意。金额字段用DECIMAL(10,2)而不是FLOAT或DOUBLE因为浮点数在计算时会有精度丢失问题做月度汇总的时候容易出现0.01的差额查起来很头疼。发生日期和创建时间要区分开发生日期是用户记录的这笔钱实际发生的时间创建时间是这条记录写入数据库的时间后者用数据库的默认值 CURRENT_TIMESTAMP 就行。分类表category用于管理收支分类分为收入类工资、奖金、投资收益等和支出类餐饮、交通、购物、住房等。分类表要设计类型字段前端添加账目时根据收入或支出动态加载对应的分类下拉列表。预算表budget用来做月度预算控制。字段包括预算ID、用户ID、月份、总预算金额。这个表可以做得简单些按月和用户维度各一条记录系统在该月新增支出时汇总比对如果超出预算就给出提示。表关系上一个用户有多条账目一个分类下有多条账目一个用户在某个月份有一条预算记录。外键约束必须加上不然删了父表数据子表变成孤儿数据前端列表里会出现查不到分类名称的情况。还要给常用的查询字段建索引比如账单的查询经常按用户ID加时间范围进行那么(user_id, occur_date)的联合索引能明显提升查询速度。数据量小的时候感知不强但你论文里写“系统性能优化措施”的时候可以用上。2.2 后端分层架构与关键接口设计SSM项目的后端分层是教科书式的Controller → Service → Mapper三层架构。很多同学写代码喜欢把所有逻辑堆在Controller里Service层形同虚设这在大作业里能跑在毕设里就会被质疑。分层的目的在于职责单一Controller只负责接收参数和返回结果Service负责业务逻辑处理Mapper负责数据库操作。家庭财务系统里比较核心的Service业务逻辑有两处。第一处是账目分页查询前端传入页码、每页条数、用户ID、类型、分类ID、开始日期、结束日期这一堆条件拼出来要保证动态SQL正确。MyBatis的 标签和 标签就是专门干这个的注意每个条件都要判空日期范围用 和 再配合 DATE_FORMAT 处理。第二处是月度统计Service层查出一个月内的收入和支出后分别SUM返回给前端做图表展示顺便和预算表比对返回是否超预算的标记。接口设计采用RESTful风格常用的路径大致是这样POST /api/user/login 做登录返回TokenGET /api/bill/list 分页查询账单POST /api/bill 新增账单PUT /api/bill 修改账单DELETE /api/bill/{id} 删除账单GET /api/bill/statistics 获取统计结果。统一返回格式为 { code, message, data }前端根据code判断业务成功还是失败比裸返回JSON对象更规范。这里提一个我实际开发中养成的习惯所有的金额计算都在后端完成前端只负责展示。不要信前端JS算出来的钱JS浮点运算的精度问题会让你在月度汇总时欲哭无泪。即使前端页面只是想显示个实时合计也让它调用后端统计接口这点在答辩时也能讲成“系统安全性考虑”。2.3 前端页面结构与组件拆分Vue前端部分我建议采用Vue Router Vuex Element UI ECharts的组合。页面结构上分成这么几个视图登录页、系统主布局侧边栏菜单 顶部栏 内容区、仪表盘统计概览页、账目列表页、账目新增/编辑表单页可以用Dialog弹窗复用、分类管理页、预算设置页。先说登录页。表单校验是Element UI的强项用户名和密码为空时的提示、密码长度限制这些都是展示你前端基本功的地方。登录成功之后把Token存在localStorage里在Axios的请求拦截器里带上Token如果后端返回401状态码就跳回登录页。这些属于前后端交互的规范做法能体现出你对安全性的理解。账目列表页是整个系统里最复杂的页面。建议搜索条件区域放一行筛选表单——类型选择器、分类选择器、日期范围选择器、搜索按钮和重置按钮表格展示序号、日期、类型、分类、金额、备注、操作列编辑、删除表格下方放分页组件。新增和编辑共用一个Dialog弹窗里面是表单类型单选默认收入、分类级联下拉选类型后动态加载、金额InputNumber精度两位、日期DatePicker默认今天、备注Input textarea。切换类型时清空已选分类这个交互细节很多同学容易漏掉。仪表盘页面用ECharts做可视化比较推荐放这几个图最近6个月收支趋势折线图双系列、本月支出分类占比饼图、收入支出总额卡片。ECharts在Vue里的用法是引入echarts实例在mounted钩子里初始化图表在数据更新后调用setOption更新。这里有个小坑是图表容器宽度变化后需要调用 resize() 方法重绘如果页面里有折叠的侧边栏展开折叠后图表会变形处理方式是在侧边栏切换时延时触发 resize。组件拆分方面把统计卡片、分类选择器这类复用度高的部分抽出来做成子组件代码结构会清爽不少论文里也能写“本系统采用组件化开发模式实现了功能模块的高内聚低耦合”。3. 实操过程与核心环节实现3.1 从零搭建SSM后端骨架后端工程建议用Maven管理依赖。项目结构按这种分包方式com.xxx.familyfinance 下面分 controller、service、mapper、entity、common 五个包。common包里放工具类、统一返回结果类、异常处理类。Java版本选JDK 1.8稳定且教程最多。pom.xml里的核心依赖大概有这些spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databindJSON序列化、servlet-apiprovided范围。数据库连接用Druid连接池配置一下初始化连接数和最大连接数加上常用的监控配置。spring-mvc.xml配置文件里做这几件事开启注解驱动配置静态资源放行不然前端的静态页面会被拦截、配置视图解析器如果前后端分离就不需要配了、启动Service层的组件扫描。spring-mybatis.xml里配置SqlSessionFactoryBean把数据源和Mapper接口扫描器都挂上事务管理器也要配置。Druid数据源需要重点理解它不只是连接池还提供了监控页面。访问项目的 /druid/index.html 可以看到SQL执行次数、耗时、并发情况。这个页面在答辩的时候现场演示一下说“我用了Druid连接池并开启SQL监控方便定位慢查询”属于加分项。3.2 核心Mapper与Service代码实现思路以账目分页查询为例Mapper接口定义一个方法List selectBillList(Param(param) BillQueryParam param)XML里写动态SQL。注意MyBatis的 标签会自动拼上WHERE关键字并清除第一个多余的AND这样就不用担心条件全为空时生成语法错误的SQL。金额合计的查询用 SELECT IFNULL(SUM(amount), 0) FROM bill WHERE user_id #{userId} AND type #{type} AND occur_date BETWEEN #{startDate} AND #{endDate}。为什么要加IFNULL因为一个用户某个月只花了钱没有收入时SUM查询结果是NULL不处理的话JSON序列化出来就是 null前端拿到 null 去渲染图表会报错得在前端兜底。任何数据库查询的GTE都要养成这种兜底习惯。Service层的语音账目标准写法是public PageResultBillVO pageQuery(BillQueryParam param) { int total billMapper.countByCondition(param); ListBillVO list billMapper.selectByCondition(param); return new PageResult(total, list); }新增账目时要做的业务校验包括金额必须大于0、分类ID存在的且类型匹配、用户ID有效。修改和删除之前要校验操作者是否是该账单的所属用户不然用户A把用户B的账目删了数据就乱了。这套校验逻辑写下来论文里业务规则一章就有素材了。3.3 前端Vue项目的核心交互实现Vue工程用vue-cli创建后安装axios、vue-router、vuex、element-ui、echarts这几个核心依赖。router配置里加一个全局前置守卫没有Token且访问不是登录页的话跳转到登录页这样用户不登录就无法进入系统页面反向验证了后端接口的安全性设计。账目表单提交的核心代码可以这样组织submitForm() { this.$refs.billForm.validate(async valid { if (!valid) { this.$message.error(请完善表单信息); return; } const formData { ...this.form }; const resp await addBill(formData); if (resp.code 200) { this.$message.success(保存成功); this.dialogVisible false; this.loadBillList(); } }); }ECharts填充数据的典型逻辑是先调统计接口拿原始数据再转换成图表需要的格式然后 setOption 刷新图表。比如饼图数据格式是 [{ name: 餐饮, value: 1200 }, { name: 交通, value: 300 }]而后端返回的可能是 [{ categoryName: 餐饮, total: 1200 }]字段名对不上就需要前端做一次map映射const pieData res.data.map(item ({ name: item.categoryName, value: item.total })); chart.setOption({ series: [{ data: pieData }] });这个细节很值得在论文里提一句说明你考虑到了“后端面向业务建模前端面向可视化建模两者之间通过适配层转换”这件事。3.4 项目完整运行与联调步骤为了让这套系统在你自己电脑上能跑起来最好把环境固定为JDK 1.8、Maven 3.6、MySQL 5.7/8.0、Node 14。数据库先执行建库脚本创建表和初始化几个分类数据。后端用IDEA打开工程等Maven把依赖下载完修改数据库连接信息配置Tomcat启动或者用内置Tomcat的spring-boot方式如果用的是Spring Boot版SSM。前端开发环境跑 npm install等依赖装完npm run serve。这里有个高发问题后端接口地址是 http://localhost:8080/xxx前端开发服务器默认是 http://localhost:8081跨域了。解决方案是在vue.config.js里配devServer的proxy代理把/api前缀的请求转发到后端地址。配置好后本地调试就完全感觉不到跨域的存在这也模拟了生产环境的分离部署模式。还有个容易忽略的环节是数据库初始化数据。运行完项目要演示功能空数据库什么图都没有不好看。提前写一个SQL脚本插入一个演示用户、若干个收支分类、两三个月的真实模拟账目数据带日期的、分类分布合理的这样页面一打开就有图表和列表效果答辩演示效率高很多。4. 常见问题与排查技巧实录4.1 后端启动或接口调不通的几类高频问题第一个常见现象Tomcat能启动但请求接口报404。排查思路是先看控制台有没有报错日志没有的话用postman直接打后端接口试试。如果postman也404大概率是DispatcherServlet拦截路径配置问题SpringMVC配置里不要把 / 拦成拦截jsp以外所有请求如果拦了静态资源要放行如果postman通而前端打不通那就是跨域配置问题。第二个高频问题MyBatis的Mapper绑定错误报 org.apache.ibatis.binding.BindingException: Invalid bound statement (not found)。原因绝大多数是Mapper接口和XML文件不在同一个包路径下或者Mapper扫描配置只扫了接口没扫XML。把maven-resources插件配置里加上 **/*.xml 。或者更简单的办法是把XML文件放进resources目录下和Mapper接口保持同名同路径。第三个我遇到过的奇葩问题金额字段用Java的Double接收后出现100.9999这种天文数字。这就是前面说的精度问题解决方法一个是数据库里 DECIMAL 配Java的 BigDecimal另一个是金额全用String输入、后端解析成BigDecimal计算。我通常选择后者简单粗暴不容易出错。4.2 前端页面常见的报错与卡顿排查Element UI的Table表格默认高度固定时数据多会撑开页面而不是内部滚动。给它设置一个高度或者 maxHeight 属性就能获得表头固定、表体内部滚动、分页固定在底部的布局效果。这个细节在页面截图时特别加分很多人答辩时页面一拉数据长得离谱观感就差很多了。日期范围筛选时后端查询用的是字符串比较。从后端接口拿到 String 类型日期后不要直接传先做一次格式化再传给DatePicker否则显示的是默认格式。反过来提交筛选时把 DatePicker 返回的 Date 对象格式化成 yyyy-MM-dd 字符串再发请求。这些格式处理写成一个 util 文件里的 formatDate 函数集中维护而不是每次在组件里写死。还有一个经常被问到的问题刷新页面后路由页面空白控制台报JS错误。排查发现是Vue Router的mode是history模式下部署到服务器上刷新会出现404但本地开发不会。本地开发出现空白大多数是因为npm run serve的进程挂掉了重新启动就好。生产部署如果不想配服务器转发规则就用hash模式代价是URL会有个#号毕设场景完全够用。4.3 排查问题的方法论从“报错点”反推“源头”虽然上面列了很多具体问题但排查方法比记具体错误更重要。我的习惯是先在浏览器控制台看Network面板确认请求到底发出去了没有状态码是多少响应体里报的什么错。这一步能排除80%的问题因为很多BUG是前端参数没传对、请求根本没打过去。如果状态码200但是页面没变化就看控制台有没有JS异常异常信息里就指到哪一行代码。接着在代码里用 console.log 打印关键数据一步步追到数据是什么。如果后端返回500就去IDEA里看堆栈日志通常错误信息第一行就是原因所在。这一路排查下来你会发现大多数问题不在技术难度而是“前端参数名和后端实体字段名不一致”“日期格式对不上”这类低级但高频的对接问题。所以开发时有一个小习惯能省大量时间前后端约定的JSON字段名写进一个字段对照表文档里或者直接用接口文档工具来规范自己对接自己也不例外。5. 论文撰写与答辩准备要点5.1 论文的系统实现章节怎么写系统实现这一章是论文里占比最大的部分建议按模块来写用户登录模块、账目管理模块、数据统计模块、预算管理模块。每个模块遵循相同的结构——功能描述这个模块干什么、页面展示截图、实现思路用了什么技术、核心代码贴关键代码并加注释说明。截图有讲究不是随便截一张糊的放上去就行。页面数据要完整、样式要正常、数据要真实感。我见过很多论文截图里表格数据是空的或者金额显示明显异常这都会给导师留下“测试不充分”的印象。运行项目时花几分钟把几个核心页面的截图规范截好存入专门的论文素材文件夹整理论文时能省很多时间。核心代码不是让你把Controller全贴上去而是选一到两段最能体现你技术水平的代码比如MyBatis的动态SQL配置、Spring的条件分页查询Service、前端ECharts组装数据的函数。每段代码后写3到5行说明解释这段代码解决了什么问题或用了什么设计思想。这部分的深度直接决定了导师对论文的初步印象。5.2 答辩现场的高频问题与应对思路答辩时导师问的问题看似五花八门其实集中在几个维度业务逻辑、技术选型、特殊场景处理。把这些问题的回答提前准备好心里就稳了。业务维度的高频问题家庭成员之间数据隔离是怎么做的回答思路是按用户ID区分数据查询时强制带上当前登录用户ID作为过滤条件不让用户查看其他人的账单这是基于RBAC权限模型的简化实现。技术维度的高频问题为什么选择SSM而不选Spring Boot如实说明SSM是课程教学核心通过SSM能更深入地理解框架底层整合流程例如Spring容器管理Bean、AOP事务控制、MyBatis映射机制。同时表示也了解Spring Boot的自动配置原理两者并不冲突。再被追问MyBatis相比JDBC的优势可以讲预编译防注入、结果集自动映射、动态SQL这几条。特殊场景的高频问题如果用户一天记录了上百条账目列表性能会下降吗回答思路是做了分页和联合索引优化数据量大后可以进一步引入缓存或读写分离但当前单体架构下这是权衡取舍的结果。5.3 项目演示时的小技巧答辩现场演示最怕设备不配合。提前准备两条路线一条是本地完整跑起来另一条是录好视频备用。本地演示时先把后端启动、前端启动浏览器打开登录页登录进入仪表盘页面。演示顺序从总览图表开始再到账目列表新增一条记录图表马上更新这就形成了很好的闭环效果。数据库里准备一组带日期的模拟数据比如过去六个月每个月的工资收入、房租支出、餐饮支出分布均匀且总金额合理。数据太假也不好比如一个月收入填100万答辩完表格还没关导师的眼神已经不对劲了。把金额控制在普通人生活范围内更有说服力。再分享一个演示时加分的操作演示完新增和删除账目后刻意刷新一下页面说明数据是持久化到MySQL里的。很多同学演示时新增了一条记录结束前也不刷新页面导师没法看出数据到底存没存。主动做这个动作配合一句“重启项目数据也不会丢已经验证过MySQL持久化”数据的真实性和完整性就不用导师再追问了。6. 写在最后的实操心得做家庭财务管理系统这套毕设前后大概花了我六周左右的业余时间。前两周用来梳理需求、设计数据库和画原型图中间两周完成了后端全部接口和前端主要页面最后两周用来联调、补测试、写论文和准备答辩。整个过程走下来最深的体会是这个题目之所以经典是因为它的复杂度刚好落在“需要独立思考设计但又不至于完全无从下手”的位置上。如果你正准备做这个项目我的建议有三条。第一条先把用例图和ER图画好再动代码画图的过程就是逼自己理清业务逻辑的过程这个环节省了后面无数返工。第二条前后端联调的时候别急着一次把所有功能都连起来先跑通一条最核心的链路——登录、新增账目、列表展示链路了再扩展其他功能。第三条论文不要拖到最后才写每完成一个模块就记录截图和笔记最后整理起来效率翻倍。遇到卡壳的时候排查问题的顺序永远是先看网络请求通没通再看后端日志报什么错最后检查是参数问题还是数据问题。绝大多数卡壳都不会超过半天真正花时间的是那些藏在细节里的低级错误而它们恰恰是你在答辩时能讲的“踩坑经历”。做毕设最重要的是别钻牛角尖。某个功能实现不了退一步换个思路用更简单的方案绕过去展示的效果反而更好。家庭财务管理系统能做到账目清晰、统计直观、交互顺畅已经配得上“优秀”二字了。
阅读完成 · 觉得有帮助？
