Spring Boot与Android个人财务系统开发实战全解析

简介：一份基于Android平台、采用Java与SpringBoot框架的个人财务系统毕业设计论文资料，适合计算机、软件工程等相关专业学生撰写移动应用类课题时参考。内容覆盖论文完整流程，从绪论、相关技术、需求分析到系统设计、功能实现、测试优化与总结，包含用户注册登录、收支记账、分类管理、预算设定、数据统计与安全登录等模块的设计思路。文档为docx格式，共1个文件，压缩包大小约2.57MB，便于直接阅读、编辑和按需调整章节结构。该资源已有156人学习下载，可作为毕业设计开题、撰写与答辩准备阶段的实用参考，帮助快速理解个人财务类App从需求梳理到技术落地的整体过程。 看到这个标题，我估计不少正在准备Java方向毕业设计的同学会觉得眼熟——Spring Boot + Android 的搭配，加上个人财务系统这个选题，几乎是每年都在出现的经典组合。这不是坏事，经典意味着参考资料多、踩坑记录多、老师也容易理解你的系统在做什么。但正因为做的人多，你要想拿高分，就得在技术深度、功能完整度和论文表述上比别人多做几步。

我去年刚完整带过一个类似课题从开题到答辩，这里把整个项目的技术选型、后端实现、Android端落地、论文撰写和答辩准备一条线讲清楚，内容包括可直接复用的代码思路、表结构设计和一些踩过才明白的坑。准备选这个题的同学，建议先把这篇看完再动手。

1. 项目整体设计与技术选型思路

1.1 系统定位与核心功能边界

个人财务系统的用户需求其实很直白：解决普通用户“钱花到哪里去”的问题。功能无非是记一笔账、看一个统计、设一个预算。但作为毕业论文课题，你得在清晰的需求边界内把技术含量做出来。

我的建议是把系统拆成六个核心模块。用户模块负责注册、登录、密码找回和基础信息维护；账单模块负责收入和支出记录的增删改查，支持按时间、分类、账户做组合筛选；账户模块管理现金、银行卡、微信、支付宝等多类账户，支持余额调整和账户状态管理；分类模块提供系统预设的收入支出分类，同时允许用户自定义；预算模块按月设置总预算和分类预算，有超支提醒；统计模块输出月度趋势、分类占比、账户收支对比和年度汇总。

功能千万不要贪多。能把六个模块做扎实，论文素材就已经很充足了。我见过不少同学想一口气把理财、股票、信用卡、分期付款全塞进去，结果前后端都没做透，答辩时被问到数据库设计直接卡壳。毕设的核心是“完整交付一个系统”，不是“做一个大而全的商业App”。

1.2 为什么选 Spring Boot + Android，而不是其他方案

这个问题基本是答辩必问。你要提前想清楚技术选型逻辑，不能只回答“大家都用这个”。

Spring Boot 的优势很明确。自动配置机制省掉了大量 XML 配置，内置 Tomcat 让项目能打包成 JAR 直接运行，生态里 MyBatis-Plus、JWT、Redis、EasyExcel 都有现成的 starter，接入成本非常低。再加上分层架构清晰，天然适合写进论文的“系统设计”章节。

Android 原生开发这边，本地 SQLite 可以做离线缓存，网络不佳时用户也能记账；Material Design 组件库让 UI 实现门槛低了不少；图表方面直接用 MPAndroidChart，统计展示效果很能打。如果换 Web 端，你就少了一块“移动端适配”的内容；如果换 Flutter 跨端，又可能因为环境问题多出一堆不可控的变量。

当时我在论文里画了一张前后端交互架构图，把 Spring Boot 后端、Android 客户端、MySQL 数据库之间的完整请求响应链路标清楚，老师看完直接点头。这张图后来也成了我答辩PPT里最核心的一页。

2. 后端 Spring Boot 核心实现与实操细节

2.1 工程结构、依赖版本与避坑组合

这里要特别注意版本兼容性问题。我的建议是选 Spring Boot 2.7.x 而不是 3.x。原因很现实：大部分教学资源、博客文章和网上代码还是基于 2.x，遇到问题容易搜到答案；3.x 迁移到 Jakarta EE 规范后，部分旧教程代码不能直接用，调试成本直线上升。Java 8 + Spring Boot 2.7.x + MyBatis-Plus 3.5.x + MySQL 8.0 这套组合非常稳，我实测下来基本没有版本层面的坑。

工程分层建议这样组织：

com.example.finance ├── controller // 接口层，接收请求、返回结果 ├── service // 业务层，核心逻辑 ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── dto // 前端传入参数对象 ├── vo // 返回给前端的视图对象 ├── config // 配置类，如拦截器、跨域 ├── utils // 工具类 └── common // 统一返回体、异常处理、常量

当时我把每一层职责用一段话写进论文，再配一张项目包结构图，“系统设计”章节的框架感就出来了。代码层面，controller 里只做参数接收和结果转发，业务逻辑全在 service 层，mapper 只做数据操作。这样分层方便写单元测试，答辩时也能说清楚各层的边界。

2.2 统一返回、全局异常与JWT鉴权

个人财务系统的接口不多，但统一返回体一定要做。我写了一个 Result 类，包含 code、message、data 三个字段。约定 200 成功、400 参数错误、401 未登录或 Token 失效、500 服务器异常。所有接口都返回这个结构，Android 端解析时只需判断 code 就能决定是弹提示还是跳登录。

配合 @RestControllerAdvice 做全局异常处理，把业务异常和系统异常分开处理。比如用户输入金额为负数，抛出业务异常返回 400；数据库连接失败，返回 500 并记录详细日志。这一块在论文里对应“系统健壮性设计”小节，答辩时有得聊。

登录注册环节，用户登录成功后后端签发 JWT，Android 端把 Token 保存到本地。后续每次请求通过拦截器放在 Authorization 头里。后端用拦截器校验 Token，解析出 userId 放入 ThreadLocal，业务层直接引用。

实际踩过的坑有两个。第一，JWT 密钥要写在 application.yml 配置里，别硬编码到代码中。第二，拦截器放行白名单必须包含登录和注册接口，否则客户端永远登不进去——我当时就是忘了配白名单，排查了整整一晚上。另外，如果你用 MyBatis-Plus，可以顺手用 MetaObjectHandler 做 createTime、updateTime 的自动填充，省掉每次手动 set 的操作。论文里这叫公共字段自动填充，是个加分细节。

2.3 账单模块设计：表结构、金额存储与统计SQL

账单模块是整个系统的核心，表结构设计直接决定后面所有统计功能的实现难度。我最终采用的账单表设计是这样：id 主键自增；user_id 关联用户表；account_id 关联账户表；category_id 关联分类表；amount 字段存储金额，单位是分，使用 BIGINT 类型；type 标记收支方向，0 代表支出、1 代表收入；remark 存备注；bill_time 记录消费时间；create_time 和 update_time 记录创建和修改时间。

金额用“分”存储是我特别想强调的一点。整数运算没有浮点误差，精度绝对可控。论文里可以清楚解释 Why Not Double，这也是答辩时老师最爱追问的问题之一。

月度趋势统计可以这样写：按月份做分组，分别汇总收入和支出金额。SQL 里用 DATE_FORMAT 函数格式化时间字段，再用 CASE WHEN 做条件聚合。

SELECT DATE_FORMAT(bill_time, '%Y-%m') AS month, SUM(CASE WHEN type = 1 THEN amount ELSE 0 END) AS income, SUM(CASE WHEN type = 0 THEN amount ELSE 0 END) AS expense FROM bill WHERE user_id = #{userId} GROUP BY DATE_FORMAT(bill_time, '%Y-%m') ORDER BY month;

分类占比统计类似，按分类分组汇总支出金额，Android 端拿到数据后渲染成饼图。这里有个隐藏问题要提前处理：如果某个分类下没有账单，这个分类就不会出现在统计结果里。不用觉得这是 bug，产品逻辑上完全合理，但你要在论文里把这一点说清楚，不然老师会问“为什么分类列表和统计结果不一致”。

3. Android 端核心实现与联调经验

3.1 工程分层与网络层封装

Android 端我采用的架构是 MVVM。View 层用 Activity 和 Fragment 承载页面，ViewModel 持有界面状态，Repository 层统一管理数据来源。这么做的好处是逻辑清晰，而且能在论文“客户端设计”章节里画出完整的架构图。

网络层选择 Retrofit + OkHttp + Gson，这是最稳的组合。这里有两个重点值得展开。

第一，统一拦截器注入 Token。在 OkHttpClient 构建时添加一个 Interceptor，从本地取出 Token 并设置到请求头的 Authorization 字段。这样所有接口的鉴权逻辑收敛到一处，后续代码不用重复处理。

第二，统一响应处理。响应体先走一个全局解析流程，code 不等于 200 时统一弹 Toast，401 时自动跳转登录页并清空本地数据。这个机制做好之后，前后端联调会顺畅很多，不会再为了“为什么这边没反应”来回折腾。

val client = OkHttpClient.Builder() .addInterceptor { chain -> val token = AppPrefs.getToken() val request = chain.request().newBuilder() .header("Authorization", token) .build() chain.proceed(request) } .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .build() val retrofit = Retrofit.Builder() .baseUrl(BuildConfig.API_BASE_URL) .client(client) .addConverterFactory(GsonConverterFactory.create()) .build()

3.2 记账页面、统计图表与本地缓存实现

记账页面建议做成一个单独的 Activity。顶部是收支切换 Tab，中间是金额大的输入框，下方选择账户和分类，底部是备注输入和保存按钮。分类选择使用 GridView 或 RecyclerView 展示图标加文字，数据由后端分类接口提供。页面整体结构不复杂，但交互细节要多留心——比如切换收入支出时分类列表要联动变化，金额输入框默认弹出数字键盘。

统计页面我直接集成了 MPAndroidChart。月度趋势用折线图展示，分类占比用饼图展示。图表库的集成成本不高，Gradle 加一行依赖就能用，但注意图表数据要跟接口返回的结构对应好，不要在前端做太多二次加工。

本地缓存方面，我用 Room 做了账单表结构同步存一份。每次进入 App 先加载本地数据，同时后台拉取最新数据并更新界面。离线时用户可以记账，但记录会标记为“未同步”，等网络恢复后自动提交。这个设计在论文里可以对应“离线缓存与弱网优化”，是一个明显的加分点。不过实现时注意：提交失败的记录要有重试机制，不然用户会以为记了账，结果数据丢了。

3.3 联调过程中最容易被卡的三个点

Android 端与后端联调时，我做毕设期间遇到过三个高频问题，提前知道能省不少时间。

第一个是 Android 9 及以上系统默认禁止明文 HTTP 请求。如果你的后端是本地 HTTP 接口，Android 端需要配置网络安全策略，允许明文流量，否则请求会直接失败。这个报错信息很典型，出现类似 Caused by: java.io.IOException: Cleartext HTTP traffic to xxx not permitted 就是你忘了配置。

第二个是真机调试时访问后端地址的问题。模拟器访问宿主机用 10.0.2.2，真机要填电脑局域网 IP 地址。我当时用真机调试经常忘记改 IP，每次都要重新打包。后来学乖了，用 BuildConfig 区分 debug 和 release 环境地址，不同构建类型自动加载不同 baseUrl，一次配置好就不用手动改了。

第三个是时间字段时区问题。后端返回的时间如果带时区信息，Android 端解析时格式不对会直接崩溃。统一约定后端返回时间戳或者 yyyy-MM-dd HH:mm:ss 格式的字符串，前端按约定解析，两边都不要自己做格式化再传。

4. 论文写作与答辩准备经验

4.1 论文结构安排与关键章节写作

毕业设计的论文结构一般按照“绪论—需求分析—系统设计—系统实现—系统测试—总结”的思路展开。个人财务系统这个题目本身不复杂，写作重点应该放在需求分析和系统设计上。

绪论部分重点写研究背景和意义，不要大段复制网上的范文，最好结合个人使用场景写两三句真实感受。国内外研究现状建议引用可视化账单类App的共性功能来印证你做的需求。需求分析部分要严格画用例图，每个角色对应哪些操作、每个操作涉及哪些数据流，图要清晰，文字要对应图展开描述。

系统设计部分把整体架构图、功能模块图、数据库ER图、表结构说明都放进来。数据库设计是答辩时老师最常翻的章节，每张表的字段含义、类型选择、外键关联都要解释得清清楚楚。当时我在论文里专门用了一个大表格把所有核心表的字段列出来，备注列写上业务含义，老师看了之后说“这数据库设计得挺规范”。

系统实现部分不要贴大段完整代码，只放核心方法片段，比如 JWT 拦截器的校验流程、月度统计的 SQL、Android 端网络层的封装。代码前后加解释性文字，说明这段代码解决了什么问题。系统测试部分要区分功能测试和性能测试，我当时没有花钱做压力测试，但写了较完整的测试用例表，覆盖每个模块的正常流程和异常流程。

4.2 数据库设计文档的呈现与ER图、流程图

ER 图是论文必备素材，个人财务系统至少涉及用户、账单、分类、账户、预算这五张表。用户和账单是一对多，分类和账单是一对多，账户和账单是一对多，预算和用户是一对多。用设计工具导出实体关系图，再在论文里对应解释每张表的主外键关系。

流程图上重点画记账流程和登录鉴权流程。记账流程是：用户填写表单、校验数据、保存账单、更新账户余额、刷新统计界面。登录鉴权流程是：用户输入账号密码、后端验证、签发Token、客户端保存Token、后续请求携带Token、后端拦截器校验。这两张流程图画好，系统的核心链路就清晰了。

4.3 测试用例设计与答辩准备要点

测试用例是论文里容易写得很空的部分。我当时写了一个表格，包含用例编号、测试模块、操作步骤、预期结果、实际结果、结论六列。每个模块挑三到五个典型场景，覆盖正常输入、边界值输入和异常输入。比如记账功能就测了正常记一笔支出、金额为0、金额为负数、备注超长、断网提交这几种情况。表格一放，论文篇幅和完整度都有了。

答辩准备上，PPT 控制在十分钟以内。技术亮点挑三个讲：一是 JWT 无状态鉴权机制，二是基于“分”的金额存储与防浮点误差方案，三是 Android 离线缓存与同步机制。老师提问大概率会围绕这几个点展开，提前准备好例子，压力会小很多。

5. 常见问题速查表

这个清单是我当时整理给自己用的，几项都是从报错到找到原因折腾了几个小时的经历。你遇到类似问题时不用慌，先定位是前端、后端还是网络层，再按表格里的思路排查，基本都能快速解决。

最后说点心里话。Spring Boot 基于 Android 的个人财务系统，技术上没有特别难的关卡，真正拉开差距的是细节。表结构设计是否合理，统计 SQL 是否高效，接口规范是否统一，离线缓存是否可用，异常处理是否到位，论文里每一个模块的实现过程是否讲得清逻辑，这些才是答辩老师眼中“工作量”和“掌握程度”的真实体现。按照功能优先、演示可跑、论文讲透的顺序推进，这个课题拿一个理想的成绩是很有把握的事。

本文还有配套的精品资源，点击获取