企业官网建设流程全解析

1. 项目概述：一个老生常谈却每年都有人踩坑的题目

说起 Spring Boot 个人财务管理系统，我估摸着十个做毕设的同学里至少有一个会选它。为什么？因为这类题目天然适合作为毕业设计：技术栈固定、需求明确、数据库关系不复杂，却又能把 Web 开发的核心环节全部覆盖到——增删改查、权限控制、数据可视化、报表导出，你要愿意还能塞进去定时任务、消息通知。但恰恰因为"看起来简单"，很多同学反而在细节上翻车，最后答辩时被导师一句话问懵。

这个项目的标题是"springboot个人财务管理系统源码和论文"，关键词是 springboot、管理系统、源码、论文。我理解你的真实需求大概率是：第一，需要一套能跑通的源码；第二，需要一篇结构完整、逻辑自洽的毕业论文。但如果你只是照着网上下载的代码改个页面交差，那我劝你趁早换思路。我见过太多人拿到的所谓"源码"要么缺依赖跑不起来，要么数据库脚本和代码逻辑对不上，更别提论文里技术表述漏洞百出。这篇文章我会把整个系统的设计思路、代码实现、论文写作要点一步步拆开讲透，同时指出那些只有实际开发过才会发现的坑。

先给个整体认知：这套系统本质上解决什么问题？说白了，就是让普通用户把每一笔收入支出记下来，按时间、类别、账户去统计分析，最终知道自己钱花哪了。和那些记账 App 比，它少了移动端和第三方支付自动同步，但在 Web 端把账目管理这件事做完整了。系统一般分两类角色：管理员和普通用户。管理员管用户、管数据统计，普通用户管自己的账单和预算。你要是想让论文显得有深度，可以把预算预警、数据可视化、报表导出这几个模块都做了，既有技术含量，又能凑够论文篇幅。

适合谁来参考？如果你是计算机相关专业的学生，正在做毕设或课程设计，这篇文章能帮你少走弯路；如果你是想快速捡起 Spring Boot 全栈开发的初学者，这篇文章也可以当作一条完整的学习路径——从一个实际项目出发理解技术点，比对着教程敲代码有效得多。

2. 技术选型与整体架构：为什么偏偏是 Spring Boot

2.1 Spring Boot 不是唯一选择，但它是性价比最高的选择

个人财务管理系统这类 CRUD 密集型的 Web 应用，技术选型其实有很多坑要避免。有人上来就整微服务，Spring Cloud + Nacos + Feign + 分布式事务，我看了直摇头——一个记账系统有必要吗？也有同学非要赶时髦用前后端分离，Vue + Spring Boot 做两个工程，结果答辩时被问到跨域、Token 失效、接口鉴权这些问题，支支吾吾答不上来，反而扣分。

我的建议是老老实实用服务端渲染 + Thymeleaf，或者你自己模板渲染。原因很简单：管理类系统核心是"表单 + 表格 + 统计图表"，这类页面用模板引擎开发效率最高，一个 Controller 加几个 HTML 页面就能搞定，用户刷新后台页面也不会遇到浏览器前进后退带来的困扰。

选 Spring Boot 的核心优势，首先就是自动装配让配置成本大幅降低。比如你要用 MySQL，加一个依赖、配一段 yml，数据源就好了；要用 MyBatis-Plus，再加一个 starter，CRUD 就自带分页和通用方法。相比传统 SSM 手工写一堆 XML 配置，Spring Boot 把那些繁琐的 Bean 定义全部干掉，非常适合单人开发的毕设项目。

其次是生态成熟。你想加安全认证有 Spring Security，想做定时任务有 @Scheduled，想做接口文档有 knife4j，想做导出有 POI 或 EasyExcel，几乎你能想到的功能都有现成方案可以接进来。这不是说不需要理解原理，而是让你把精力放在业务本身，而不是反复调试框架间的兼容性。

2.2 系统模块划分：从"记账"到"理财"的进阶设计

如果只是为了交作业，你做个简单的收支记录管理就完事了。但如果你希望论文有看点、答辩有的聊，我建议你至少做以下七个模块：

1. 用户管理模块：注册、登录、个人信息修改、密码修改、管理员对用户的禁用与启用
2. 收支类型管理：支出类型（餐饮、交通、购物、娱乐等）、收入类型（工资、兼职、投资收益等），支持用户自定义
3. 记账管理模块：新增账单、编辑账单、删除账单、条件查询（按时间、类型、关键字）
4. 账户管理模块：现金账户、银行卡、虚拟账户（支付宝、微信），记录余额并随账单变动
5. 预算管理模块：设置月度预算，支出超过预算时前端弹出提示，后台生成预警记录
6. 统计报表模块：月度收支曲线、分类占比饼图、近期收支明细，用图表展示
7. 数据管理模块：数据导入导出（Excel），定期备份提醒

你看，这样一个划分，每个模块都能单独写一节，论文的详细设计章节就不用愁没内容。更关键的是，这些模块之间的数据流是清晰的：用户在页面上记录一笔支出 → 写入账单表 → 同时更新账户表里的余额 → 月度统计时按类型聚合账单 → 与预算对比触发预警。整个流程串起来，你在答辩时可以完整讲清楚，这就是加分项。

2.3 数据库设计：五张表及其关系

数据库是整个系统的地基，我之前审核过不少同学的数据库脚本，最常见的问题是字段类型定义随意、外键约束缺失、日期字段存成字符串。个人财务系统我用过的表结构大概是这样的：

用户表 users：主键 id、用户名 username、密码 password（加密存储）、昵称 nickname、邮箱 email、角色 role、状态 status、创建时间 create_time

账户表 accounts：主键 id、用户 id user_id、账户名称 account_name、账户类型 account_type（现金/银行卡/电子账户）、初始余额 init_balance、当前余额 balance、备注 remark

收支类型表 category：主键 id、用户 id user_id（0 代表系统默认类型）、类型名称 category_name、类型 category_type（0 支出 1 收入）

账单表 bills：主键 id、用户 id user_id、账户 id account_id、类别 id category_id、收支类型 type（0 支出 1 收入）、金额 amount、交易日期 trade_time、备注 remark、创建时间 create_time

预算表 budget：主键 id、用户 id user_id、月份 month（格式 yyyy-MM）、预算金额 amount、创建时间 create_time

五张表的关系在 SQL 里不显式写外键约束也没关系，但在 Java 实体类中要建立逻辑关联。特别提醒，金额字段用 BigDecimal，千万别用 double——二进制浮点数在做金额加减时会有精度误差，这是基础中的基础。日期字段统一用 datetime，不要拆成年月日三个字段，查询时用 Date 工具处理区间即可。

3. 核心功能实现细节：从登录到统计的完整拆解

3.1 认证与权限：Spring Security + JWT 还是 Session

个人财务系统涉及用户私有数据，权限控制不能只靠前端隐藏按钮，必须在后端接口层做校验。这里我推荐两种方案，各有取舍。

方案一：Spring Security + Session。这种方案的思路是用户登录成功后将用户信息存放在 Session 中，后续请求通过拦截器或 Spring Security 的过滤器链判断是否已登录。优点是简单直接，模板渲染下的页面跳转天然支持；缺点是前后端不分离时体验尚可，一旦你将来想扩展成小程序或 App，Session 方案就要改动。

方案二：Spring Security + JWT。登录成功后生成 Token 返回前端，前端每次请求带上 Authorization 头，后端通过 OncePerRequestFilter 校验 Token 并解析用户信息。这个方案的优点是无状态扩展，接口完全可以供多端复用；缺点是实现稍复杂，Token 过期和续期逻辑要处理。

我的建议是：如果做传统服务端渲染页面，Session 方案足够；如果你想在论文里展示"现代认证方案"，选 JWT。因为财务系统一旦考虑后续接入移动端的需求，JWT 的身份认证方式对未来扩展更友好——这一点恰恰能作为你论文里的"系统的可扩展性设计"来写。

我这里分享一个 JWT + Spring Security 的实现思路，密码加密务必用 BCryptPasswordEncoder，别用 MD5——MD5 加盐方案虽然也能用，但论文答辩时如果被问到"为什么不用更安全的算法"，你很难自圆其说。

@Component public class JwtAuthenticationFilter extends OncePerRequestFilter { @Autowired private JwtTokenProvider jwtTokenProvider; @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token = resolveToken(request); if (token != null && jwtTokenProvider.validateToken(token)) { String username = jwtTokenProvider.getUsername(token); UserDetails userDetails = userDetailsService.loadUserByUsername(username); UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } filterChain.doFilter(request, response); } }

这里有一个关键点：JWT 过滤器要在 Spring Security 的过滤链中注册在 UsernamePasswordAuthenticationFilter 之前，这样每次请求先验证 Token，再走授权规则。如果 Token 无效，直接返回 401，不用进入业务逻辑。

3.2 记账模块：事务处理和级联更新账户余额

记账是整个系统最核心的功能，它涉及到两张表的联动，这也是最容易写错的地方。比如你记录一笔 100 元餐饮支出：首先要往 bills 表插入一条支出记录，然后要把对应的 accounts 表里的 balance 减 100。注意，这两个操作必须放在同一个事务里，否则账单记了、账户余额没减，数据就不一致了。

代码实现上，在 Service 方法上加上 @Transactional 注解就能保证事务性。但我要说的是更隐蔽的坑：多人同时在高并发场景下对同一个账户记账时，直接读取余额再扣除会产生脏数据。个人财务系统虽然并发量不大，但你在设计时最好养成用乐观锁或悲观锁的习惯。MyBatis-Plus 自带 @Version 注解实现乐观锁，在余额更新时加上版本号校验，代码简单且能在论文里写一笔。

@Transactional(rollbackFor = Exception.class) public Bill addBill(BillAddRequest request) { // 1. 插入账单记录 Bill bill = new Bill(); bill.setUserId(request.getUserId()); bill.setAccountId(request.getAccountId()); bill.setCategoryId(request.getCategoryId()); bill.setType(request.getType()); bill.setAmount(request.getAmount()); bill.setTradeTime(request.getTradeTime()); bill.setRemark(request.getRemark()); billMapper.insert(bill); // 2. 更新账户余额 Account account = accountMapper.selectById(request.getAccountId()); BigDecimal newBalance = account.getBalance(); if (request.getType() == 0) { newBalance = account.getBalance().subtract(request.getAmount()); } else { newBalance = account.getBalance().add(request.getAmount()); } account.setBalance(newBalance); accountMapper.updateById(account); return bill; }

记账表设计时还有一个建议：给账单表加一个逻辑删除字段 deleted，而不是物理删除。因为对用户来说，"删除一笔账单"其实常常是记错了想反悔，逻辑删除保留原始数据对统计报表的准确性很重要——这个细节用到论文里，体现的是你对数据资产的思考深度。

3.3 查询与统计：时间范围查询和聚合 SQL 的写法

统计报表是这个系统最有"含金量"的部分，也是很多模板代码敷衍的地方。常见的需求是：查看某个月份的收入总额、支出总额、分类占比。如果只在 Java 层做循环遍历累加，数据量大时效率非常低。正确姿势是用 SQL 聚合函数：

SELECT DATE_FORMAT(trade_time, '%Y-%m') AS month, type, SUM(amount) AS total_amount FROM bills WHERE user_id = #{userId} AND trade_time BETWEEN #{startDate} AND #{endDate} GROUP BY DATE_FORMAT(trade_time, '%Y-%m'), type ORDER BY month

如果是按分类统计占比：

SELECT c.category_name, c.category_type, SUM(b.amount) AS total_amount FROM bills b LEFT JOIN category c ON b.category_id = c.id WHERE b.user_id = #{userId} AND b.trade_time >= #{startDate} AND b.trade_time < #{endDate} GROUP BY b.category_id, c.category_name, c.category_type

这里在 MyBatis 的 XML 映射文件里写，不要用注解拼接动态 SQL，因为动态 SQL 在 XML 里可读性更强、也容易调试。ECharts 的图表显示是前端的事，后端返回按月统计的 JSON 数组，前端遍历组装成 series，逻辑清晰。

关于日期范围查询还有一个细节：如果只按天粒度查，用 trade_time >= #{start} AND trade_time <= #{end} 没问题；但如果你要按月查，建议把结束日期跟成"当月最后一天 23:59:59"，或者直接判断 trade_time < #{nextMonthStart}。前者你还要在 Java 里计算月末，后者思路更简洁且不会漏掉当天数据。

3.4 预算预警：定时任务和业务规则的结合

预算预警功能设计得好，系统就有了一点"智能化"的味道，论文写这块也容易扩展。我的方案是这样的：用户在某个月设置了预算金额，系统中的定时任务在每天 20:00 检查当月支出是否达到预算的 80%，达到就发一条站内通知或推送信息。关键点在两点：

一是支出累计口径要准。这个月已经发生的支出，按时间区间过滤账单表累加，注意不能统计"已删除"的账单。二是预警要幂等。同一用户同一月份，如果触发了一次预警，不要重复触发，需要在预警记录表里加唯一约束（user_id + month + type），或者查询时先判断是否已存在同类记录。

用 Spring Boot 的 @Scheduled 很容易实现：

@Scheduled(cron = "0 0 20 * * ?") public void checkBudgetWarnings() { List<User> users = userMapper.selectAll(); for (User user : users) { String currentMonth = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy-MM")); BigDecimal monthExpense = billMapper.sumMonthExpense(user.getId(), currentMonth); BigDecimal budget = budgetMapper.selectByUserAndMonth(user.getId(), currentMonth); // 判断是否超过80% if (budget != null && monthExpense.compareTo(budget.multiply(new BigDecimal("0.8"))) > 0) { // 检查是否已经预警过 int count = warningMapper.count(user.getId(), currentMonth); if (count == 0) { warningMapper.insert(new Warning(user.getId(), currentMonth, "当月支出已达预算的80%")); } } } }

这个定时任务在答辩时非常好讲，因为它体现了你综合运用了 Spring 定时任务、业务判断、数据持久化三个层面的能力，比单纯放一个 CRUD 有说服力得多。

4. 论文写作要点：学会用"设计思路+技术实现+验证结果"三段式

4.1 论文结构如何搭，才能让导师挑不出毛病

很多同学拿到的论文模板千篇一律，第一章绪论你抄我我抄你，第四章功能实现全是截图。我讲点实在的：毕业论文的核心是"你做了什么，为什么这么做，最后效果怎么样"，这三个问题贯穿每一章才能得高分。

我建议论文按这个框架来写：

第 1 章绪论。选题背景和意义写两节就够了，重点突出"传统记账方式的不足"和"数字化个人财务管理趋势"，稍有扩展意识。国内外研究现状可以写，但不要写成一堆文献的罗列，要有简单对比分析——比如本地记账软件、Web 端财务系统、移动记账 App 的优缺点差异。

第 2 章需求分析。这一章最容易写水。要画用例图、角色分析、功能需求列表、非功能需求（性能、安全、易用性）。其中非功能需求要写得具体：比如密码不能明文存储、数据要能恢复、操作响应时间在 1 秒内这一类可度量的指标。

第 3 章系统设计。关键技术介绍部分，把 Spring Boot、MyBatis、MySQL、ECharts 讲清楚，但不要大段粘贴官方文档，要结合你项目中实际解决的问题来写。然后画系统架构图、功能模块图、数据库 E-R 图，每个表设计要有字段说明和设计理由。

第 4 章系统实现。按模块分小节，每小节先写设计思路，再写关键代码，最后放截图。注意代码不要全贴，只贴核心逻辑，关键处加注释。

第 5 章系统测试。功能测试可以用表格列出测试用例，包括测试步骤、输入数据、预期结果、实际结果；性能测试可以写用并发工具压测接口的结果数据。

说到论文这里有个技巧：不要等系统开发完了再写论文，那样你往往记不清设计的细节。边开发边写文档，代码里写了什么注释，论文里就用同样的术语，前后一致性会让导师觉得你逻辑严密。

4.2 论文里常见的技术性错误，导师一眼就能看出来

我审过不少同学论文，技术描述上的错误简直是最低级的扣分点，而且完全是可以避免的。

第一个高频错误是"Spring Boot 是框架、MyBatis 也是框架"这类层次不清的表述。严格说 Spring Boot 的前提是 Spring 框架，它是 Spring 全家桶的快速开发脚手架，而 MyBatis 是持久层框架，MyBatis-Plus 是在 MyBatis 基础之上的增强工具库，不是"框架"这种大而化之的说法。写论文时前后名词要保持一致，别前面写 MyBatis，后面写 MyBatis-Plus，让人怀疑你到底用的哪个。

第二个错误是混淆"前后端是否分离"。如果你的系统用 Thymeleaf 渲染页面，那就不叫前后端分离，而是"服务端渲染的 Web 应用"。如果论文里写"前端使用 Vue，后端使用 Spring Boot"，但项目里根本没有 Vue 工程，那答辩时直接被打穿。

第三个错误是时间前后矛盾。比如系统运行环境写 JDK 11，但代码里用了 Java 17 才有的语法特性，或者 pom.xml 里的依赖版本对不上你描述的环境。开题后先确认你用哪个 JDK、哪个 MySQL 版本，然后在论文中一致化。

第四个错误是图表编号混乱。论文里的每个图、每个表要有编号，并在正文中引用，比如"如图 4-1 所示"。很多同学光贴图不编号，或者编号了不引用，格式分扣得不冤。

4.3 如何把源码和论文对应上，避免"两张皮"

源码和论文脱节是毕设评审里最严重的负面印象之一，具体表现是：论文里写的模块在代码里找不到，代码实现的功能论文里没有描述。避免这个问题，我的经验是给每个模块建立映射表——先列好功能清单，每项功能对应 Controller 层的接口、Service 层的方法、Mapper 层的 SQL、前端页面，然后按照这个映射写论文的详细设计章节。

举个例子，预算管理模块，在论文里你写"系统支持用户按月设置预算金额，并定时对比当月支出，超过阈值后生成预警信息"。对应的代码点是 BudgetController 的 save 接口、BudgetService 的 getMonthExpense 方法、WarningTask 中的定时检查逻辑、预算页面 budget.html 的展示。你在写论文时，每描述一个功能就打开代码找到对应的类和页面截图，保证说到的代码确实存在。

我还建议，论文完成前做一次"代码走查"：把论文里贴的每个代码段都复制到 IDE 中确认能编译，把论文里每张截图重新截一遍。我见过有同学论文里贴的 SQL 语句，和项目里实际跑的 SQL 明显不一样，这种错误一旦被发现，整个论文的可信度都会崩塌。

4.4 论文查重怎么破：降低重复率的几个原则

写这类管理系统论文有一个痛点：选题相似的人太多，框架相似、语句相似，查重率居高不下。我的建议不是让你抄完再改语序，而是真正理解系统之后用自己的话去叙述。

具体来说三个原则：第一，用业务流程串联技术名词。比如不写"本系统使用 Spring Boot 框架"，而是写"系统的整体技术架构基于 Spring Boot 的自动装配机制构建，该机制通过条件注解在应用启动时自动完成依赖组件的装配"。第二，多写实测数据和分析。比如"在功能测试中，针对记账模块设计了 12 个测试用例，覆盖正常记账、金额为 0、金额超长、负数金额、不存在的账户等输入场景，测试结果显示全部通过"。这种内容是你自己写的，查重软件也不会识别为抄袭。第三，架构图和 E-R 图用自己重新绘制的版本，不要直接引用模板。

5. 常见问题与排查技巧：跑不起来和"看起来跑起来了"是两回事

5.1 环境问题：JDK 版本、Maven 依赖、MySQL 版本三座大山

我敢说，从网上下载的八成 Spring Boot 源码第一次跑不起来，原因基本集中在环境差异上。这里给出一个标准的排查顺序：

第一，JDK 版本对不对。看看 pom.xml 里 spring-boot-starter-parent 的版本，2.7.x 全系列最高支持 JDK 17，但很多模板工程是 JDK 8 编译的。你如果本地装的 JDK 17 还用了新语法，得先确认编译 target 是 17 还是统一 11，直接在 pom.xml 设置：

<properties> <java.version>11</java.version> <maven.compiler.source>11</maven.compiler.source> <maven.compiler.target>11</maven.compiler.target> </properties>

第二，Maven 依赖能否解析。私服镜像问题导致的下载失败是最常见的。检查 settiings.xml 里配置的镜像地址，常见方案是使用 Maven 官方中央仓库的镜像。如果某个依赖始终拉不下来，试试清理本地仓库后重新导入，不要只是"刷新 Maven"。

第三，数据库初始化是否完整。很多源码包里附带的是 SQL 脚本，你要先建库、再导入数据表，然后核对 application.yml 里的数据源配置是否指向正确的库名、用户名、密码。连接的是本机 3306 端口还是云数据库，这个很不显眼但经常坑人。

5.2 代码运行问题：常见异常及解决思路

我给你归纳几个高频出现的运行时异常，你按表索骥排查：

5.3 逻辑层面的隐患：项目"看着能跑"和"经得起问"的区别

有些代码跑通并不代表逻辑正确。我举三个常见例子，你在自测时重点关注。

账单删除后账户余额要不要加回来？这个逻辑如果处理不对，删一笔支出后账户余额不会恢复，用户第一反应是"我的钱去哪了"。如果你做物理删除，必须同时更新账户余额；做逻辑删除的话，余额也不必恢复，但统计报表里就要排除已删除数据。

编辑一笔账单时怎么处理余额？如果只改金额，账户余额应该先还原旧金额，再扣减新金额。如果不做这一步，用户改一笔 10 元的支出为 100 元，余额差额就错了。这个更新逻辑最好在同一个事务里完成。

多账户支持下，从 A 账户转到 B 账户怎么记？如果你有转账这个"高级功能"，本质是一笔支出、一笔收入，要同时更新两个账户余额，并且两笔账单关联成一个流水号。没有这个功能就忽略，但如果有，事务边界要设计好。

这些逻辑上的完整性和一致性，誊写在论文的测试章节里，会非常加分。比如你可以专门设计一组"极端测试场景"，验证修改账单前后账户余额的一致性。

6. 功能扩展思路：怎么让系统在答辩时眼前一亮

毕设答辩拼的其实不是代码量，而是你对自己做的系统的理解深度和扩展潜力。如果你想让导师觉得你有想法，可以从以下几个方向点出你未来的改进思路。

第一个方向是引入图表联动的可视化分析。现在的统计报表就是按月查询、分类饼图，扩展空间在于可以做趋势对比：本月 vs 上月、今年各月收支走势、某分类的消费趋势，配合日期区间选择器实现动态刷新。技术上并不难，无外乎 SQL 分组聚合和 ECharts 数据联动，但表达出来的"产品思维"会让人觉得你想问题比较完整。

第二个方向是数据备份与恢复。个人财务数据最怕丢，你可以在系统里增加导出 JSON 或 CSV 的备份功能，再搭配一个恢复入口。更进一步，用 Spring Boot 的定时任务，每周自动生成数据库备份文件，并保留最近 N 份。这个功能既有实际价值，又能在论文里单独写一节。

第三个方向是接口的幂等性和安全性。比如记账接口防止重复提交，前端按钮置灰 + 后端 Redis 分布式锁双管齐下；再比如金额字段加上范围校验（不能超过 1 亿，不能小于 0.01），用 JSR 303 的 @DecimalMin 和 @DecimalMax 注解实现。这类细节往往是拉开论文档次的关键，因为大多数人的系统都缺少基本安全防护。

第四个方向是容器化部署。把 Spring Boot 应用打成 Docker 镜像，配合 docker-compose 编排 MySQL 和 Redis 服务。如果你的论文能在最后加一章"部署与运维"，写到 Docker Compose 启动命令和镜像配置，答辩时就多了一个"贴近工程实践"的亮点。虽然对毕设来说不是必须，但绝对是加分项。

7. 最后的实操提醒：源码获取后一定要做的三件事

文章最后我再分享一些个人经历。每次有人拿网上下载的项目来问我会不会改，我先问三个问题，答不上来的基本后面都会踩坑。

第一件事，核对依赖和版本。拿到源码第一时间打开 pom.xml，确认 Spring Boot 版本、Java 版本、数据库版本三者兼容。不要因为本地装了新版 JDK 就强行跑旧项目，优先调整本地环境到项目的要求上，而不是改一堆代码去迁就新版本。

第二件事，跑通客户提出的第一个核心场景。比如记账：注册一个测试用户，新建账户，录入一笔收入一笔支出，然后看账户余额、月度统计、预算预警是否都按预期工作。如果只验证了登录页面能出截图，后面做演示时控制台报异常，会非常尴尬。

第三件事，把数据库脚本重新执行一遍，对照实体类逐字段检查。我见过不止一次，源码里的实体类比 SQL 脚本多两个字段，导致运行到查询时直接报"Unknown column"。这种低级错误，早查一分钟，后面少折腾一小时。

其实这类管理系统的开发，本质上是把所有常见 Web 技术用一遍：框架、数据库、安全、模板引擎、图表库、定时任务、文档生成。做完一个项目，你基本上就把后端开发的主线技能点通了。关键是做的时候别想着"能交差就行"，每个模块想清楚为什么这样做、有没有更好的做法，这个过程收获的才是你自己的。答辩时导师问什么都能对答如流的人，不是在现场临场发挥，而是真正把系统的每一行代码都吃透了。