Spring Boot游泳馆管理系统：从课程预约到在线充值的毕设实战

Spring Boot 毕设选题这件事，每年都能劝退不少人。题目太大做不完，题目太小没深度，答辩的时候容易冷场。今天要聊的这个游泳馆管理系统，算是我这几年见过少有的把业务链做完整、模块划分又清晰的 Java Web 项目。它不堆砌技术，而是老老实实把课程预约、泳池信息查询、在线充值、教学管理几个核心场景全部落地，附带完整前后端代码、说明文档和论文，正好卡在毕设要求的舒适区里。

这个系统适合谁来参考？首先是毕设选题还没定、想找一个业务完整度高、技术栈又主流的人；其次是自己正在写这个题，但卡在某个模块上不知道往下怎么走的同学；还有一种是想通过一个真实项目，把 Spring Boot 从建表到部署整条链路跑一遍的初学者。它的核心价值在于：模块之间的数据关系不复杂，但每个模块都有值得展开讲的业务细节，不管是写论文还是答辩，都有实打实的内容可聊。

1. 项目价值与需求拆解

1.1 选题逻辑：为什么是游泳馆，而不是更常见的图书馆或健身房

很多人第一反应是：游泳馆管理系统和图书馆管理系统有什么区别？区别大了。图书馆系统的核心是图书的借还和库存，属于典型的单主体业务；而游泳馆天然带着“场地 + 人员 + 时间 + 资金”四个维度，是一个多角色协同场景。用户要预约课程、要查泳池状态、要充值余额，管理员要管教练排课、管教学进度，教练要查看自己的学员。这种多角色、多业务线的结构，恰好是毕设评审老师最爱问的“你的系统解决了什么实际问题”的天然答案。

选这个题还有一个很现实的原因：数据建模有得写。泳池信息、课程安排、预约记录、充值流水、教学关系，每一块都能单独拉出来画 ER 图。对需要写论文的人来说，这种题材不怕没内容，只怕你不会提炼。我当时跟一个做毕设的学弟聊过，他最初想做一个简单的新增删改查，结果被导师一句话点醒：“你连支付流程都没有，怎么体现系统完整性？”后来他换成了这个带充值和预约的系统，论文里光业务流程描述就写了三章。

从技术角度看，这个题目也踩得很稳。用户管理、预约冲突检测、订单流水、状态机流转，这些功能在真实企业项目里几乎是每天都要打交道的，用它来练 Spring Boot 再合适不过。相比做图书管理这类已经被写烂的题目，游泳馆自带“实时状态”和“时段冲突”这两个亮点，稍微一包装就是特色。

1.2 功能需求全景图：标题里四个关键词到底包含了什么

把标题拆开看，核心功能其实可以归纳成三条业务链。

第一条是“预约链”：用户查看课程或泳池时段，选择空闲时间，提交预约，必要时支付定金或课时费，然后按期上课。这条链上最关键的技术点就是冲突检测，同一时段同一课程不能被两个人同时预约，同一用户也不能预约两节重叠的课。

第二条是“资金链”：在线充值。用户先充值到账户余额，再用余额购买课程或支付预约费用。这里涉及充值订单生成、支付成功回调、余额变动流水、订单状态变更，听起来不复杂，但里面藏着幂等性处理和事务一致性问题。

第三条是“管理链”：泳池信息查询和教学管理。泳池信息包括开放时间、当前水温、水深、实时人数；教学管理包括教练档案、课程分类、学员绑定、上课进度记录。这些模块业务逻辑相对直白，但承担了系统里大量的数据展示和统计功能，也是管理员端的核心操作界面。

除此之外，系统还应该包含常规的用户登录注册、权限控制、公告发布、数据统计等基础能力。这些不一定是题目标题里写出来的，但作为一个完整的毕设系统，它们是支撑上面三条业务链的地基，缺了任何一个，答辩都容易被追问到答不上来。

2. 技术架构与核心设计

2.1 技术选型：Spring Boot 项目到底怎么搭配才算合理

既然是 Spring Boot 项目，核心框架不外乎 Spring Boot 2.x 或 3.x。我的建议是不要盲目追新，选一个稳定、网上资料多的版本就好。从实际毕设经验来看，Spring Boot 2.7.x 配合 JDK 8 或 JDK 11 是最稳的组合，插件兼容性好，Maven 依赖也容易拉。如果非要用 JDK 17 加 Spring Boot 3.x，也完全可以，只是碰到网上旧教程时需要对配置做调整，遇到问题排查起来会多花时间。

持久层框架，这里我更推荐 MyBatis-Plus 而不是 JPA。原因很简单：MyBatis-Plus 在国内教程最多，CRUD 基本不用写 SQL，分页插件一行搞定，出了问题搜解决方案也快。而且它保留了 SQL 的控制力，复杂查询可以自己写 XML，对要讲清楚“表结构怎么设计”的毕设项目来说，这个灵活度是实打实的优势。JPA 虽然自动化程度更高，但很多人写到最后会被懒加载、级联更新这些概念绕晕。

前端部分，常见的做法有两种。一种是传统的服务端渲染，用 Thymeleaf 模板引擎，Spring Boot 自带支持，部署简单，适合对前端不太熟的同学。另一种是前后端分离，前端用 Vue 加 Element Plus，后端只提供 RESTful API。如果你对 Vue 多少有点基础，或者论文里需要展示一定的工程化能力，我建议选前后端分离，因为答辩的时候可以说“采用前后端分离架构，前端 Vue 负责交互渲染，后端 Spring Boot 负责业务逻辑与数据接口”，这句话本身就是一个加分项。

登录认证这块，最好是引入 JWT，配合拦截器或 Spring Security 做接口权限控制。有的同学会用 Session，也能跑，但写论文的时候缺少可讲的技术点。JWT 是无状态认证，讲清楚 token 生成、校验、续期，技术上立刻上了一个层次。至于是否要上 Spring Security，看个人精力，时间紧的话用拦截器加 JWT 也足够撑场面。

2.2 数据库设计：一招搞定预约冲突和数据一致性

数据库是整个系统的定海神针。我见过太多人把精力花在调页面上，结果表结构设计得一塌糊涂，后面越写越痛苦。这个项目建议从下面几类表入手：

用户表（user）：用户 ID、用户名、密码、手机号、角色（学员/教练/管理员）、余额、注册时间。这里最容易疏忽的是余额字段，它会被并发修改，要放在用户表里还是单独一张账户表？我的经验是单独拆出来做成钱包表（wallet）更好，后面做流水记录时逻辑更清晰。当然放用户表里也没问题，但操作时要注意加锁。

泳池信息表（pool）：泳池 ID、泳池名称、当前温度、水深、开放时间、当前人数、最大容量、状态。这个表的核心是“状态”，是开放还是维护中，直接决定前端能否预约。

课程表（course）：课程 ID、课程名称、课程类型（蛙泳/自由泳/私教）、教练 ID、上课时间（开始/结束）、上课地点（关联泳池）、人数上限、已选人数、价格、状态。

预约记录表（reservation）：预约 ID、用户 ID、课程 ID、预约时间、状态（待支付/已支付/已取消/已完成）。这张表是整条预约链的数据核心，字段必须设计到位，尤其是状态字段。

充值订单表（recharge_order）：订单 ID、用户 ID、充值金额、订单状态、第三方流水号（模拟）、创建时间、支付时间。设计成独立表，是为了让后续“模拟支付成功回调”时不干扰主账户逻辑。

余额流水表（wallet_log）：流水 ID、用户 ID、变动类型（充值/消费/退款）、变动金额、变动后余额、关联业务单号、创建时间。这张表是答辩时可以展开讲的亮点，因为它体现了系统对资金安全的把控。

教练与教学关联表（teaching）：学员 ID、教练 ID、绑定时间、当前学习阶段、开课记录。教学管理模块的后端数据基本都落在这张表上。

预约冲突检测，数据库层面能做的有限。最核心的手段是程序里加“时间区间重叠”判断，同时在数据库里给预约表加上唯一约束，比如同一用户同一课程只能有一条未取消的记录。要往深了说，可以在课程表上做“已选人数+1，先判断是否小于人数上限”的乐观锁更新。这两个方案配合起来，基本能覆盖大部分并发场景。

3. 核心功能模块的实现思路

3.1 课程预约模块：冲突检测与状态流转

课程预约是整个项目里业务逻辑最重的模块，也是答辩时最值得讲的点。简单罗列一下这个模块的后端接口：获取课程列表、获取课程详情、提交预约、取消预约、查询我的预约、课程签到。每个接口都不复杂，但组合起来就是一整套预约流程。

提交预约的核心代码逻辑是这样：先根据课程 ID 查出课程信息，判断当前用户是否已经预约过同一时段的其他课程；然后判断该课程的人数是否已满；再判断当前时间是否在可预约时间窗口内。全部通过后插入预约记录，同时把课程的已选人数加一。这三步操作涉及查询和更新，最好放在一个事务里。为了应对两个人同时抢最后一个名额的场景，更新已选人数时要用乐观锁，SQL 里带上版本号条件，然后检查更新影响行数。

这里有个很典型的问题，容易被忽略：取消预约时人数要减回去。如果只改了状态没改人数，一段时间后课程会明明没人约却显示已满员。这个问题我在调试时遇到过，排查了很久才找到原因，后来在处理取消接口时加了同步更新人数的逻辑。

状态流转也要提前规划清楚。预约状态可以设计为：待支付、已支付、已取消、已完成。用户提交预约后默认待支付，模拟支付成功后变成已支付，到了上课时间由用户或管理员操作变成已完成。具体流转路径建议画一张状态机图，放到论文里，这不仅是实现逻辑，也是论文素材。

3.2 泳池信息查询模块：做一个不让人“迷路”的场景页

泳池信息查询虽然业务简单，但它是用户进入系统后最先接触的页面，体验好坏直接影响整体观感。我在做这个模块时最大的感受是：不要把它做成一个简单的数据表格，而是要做成一张信息丰富的“场景卡片”。

每个泳池卡片上应该展示泳池名称、当前开放状态、实时温度、水深、今日开放时间段、当前人数与最大容量比例。页面可以设计成卡片流或者左右布局，用户一眼就能看到哪个泳池能用、哪个泳池人多、哪个泳池在维护。后端接口也简单，GET /api/pool/list 返回所有泳池信息，GET /api/pool/{id} 返回单个泳池详情即可。

关于“实时人数”，很多同学会想复杂了，觉得要做 WebSocket 推送。实际上在毕设阶段完全可以用轮询方案：前端每隔三十秒或一分钟请求一次接口，刷新人数和状态。这样做的好处是代码简单稳定，不需要额外引入消息队列或长连接，也能正常完成数据展示。答辩时如果老师追问实时性，你可以回答“当前采用定时刷新方案保证数据同步，后续若需要秒级实时更新，可引入 WebSocket 做服务端主动推送”，这一句话既显示了你的认知边界，也展示了扩展思路。

泳池状态还要和预约联动。比如某个泳池处于维护状态，前端提交预约时后端必须校验泳池状态，不能等到写入预约记录才发现问题。这个校验在 Course 表关联 Pool 时做一次，在 Reservation 写入时再做一次，双重保险才能避免脏数据。

3.3 在线充值模块：订单、流水与接口幂等性

在线充值模块是典型的高并发风险点。虽然毕设没有真实高并发，但把安全和幂等机制做出来，可以让你的系统在答辩时明显比别人高一个档次。

基本的充值流程是这样：用户点击充值按钮，输入金额，前端调用后端生成充值订单接口，后端创建一个状态为“待支付”的订单，返回订单号和充值金额；前端拿到订单号后显示“模拟支付”按钮，点击后调用支付成功回调接口；后端收到回调后，先校验订单号和金额是否匹配、订单状态是否真的是“待支付”，然后更新订单状态为“已支付”，再给用户余额加上对应金额，最后写入一条余额流水。

很多人在这里会犯一个经典错误：用户连续点两次充值按钮，生成两个订单，支付回调也重复推两次，导致用户余额被加了两次。要解决这个问题，第一是前端按钮防重复点击，第二是后端生成订单时做幂等控制，同一用户短时间内重复请求只返回同一个有效订单。更稳妥的做法是为每次充值请求生成一个请求唯一编号，在订单表里加唯一索引，重复请求直接报错或返回原订单。

余额变动一定要用流水表留痕。余额可以更新两次，但流水只在回调成功后写一条。这里我建议余额的更新和流水的写入放在同一事务里，任何一个失败都要整体回滚。此外，为了防止并发扣减余额导致负数，更新余额的 SQL 可以写成UPDATE wallet SET balance = balance + #{amount} WHERE user_id = #{userId}，让数据库来保证原子性。对充值而言加余额不存在负数问题，但如果是消费扣款，这种 SQL 写法同样适用。

3.4 教学管理模块：教练、课程和学员的三角关系

教学管理模块是系统里最容易被低估的部分。表面上看只是教练信息的增删改查，但真要做出彩，需要把“教学绑定”这个概念讲清楚。

教练拥有自己的课程列表，学员可以选择某位教练进行绑定，绑定后教练能看到自己名下的学员，以及学员的上课进度。举个例子，一个学员报了张三教练的自由泳私教课，绑定成功后，学员端能看自己的课程安排，教练端能看学员名单，管理员端能统计每个教练的带教人数。这层关系可以用一张 teaching 表来维护，字段包括学员 ID、教练 ID、绑定时间、当前课程进度等。

这里比较值得说的是录入课时进度。每上完一节课，教练可以给学员记录一节进度，学员端能看到“已完成 3/10 节课”。这个记录操作本身只是一个简单的增加字段，但它在论文里可以写成“教学进度闭环管理”，很加分。另外，课程评价功能如果时间允许也可以加上，让学员在课程完成后对教练和课程打分，数据反馈到管理与统计模块。

4. 部署实操与常见问题排查

4.1 本地环境搭建与启动全流程

拿到一份完整的项目代码，第一步不是急着看代码，而是先把环境对齐。这个项目我建议你统一使用以下环境版本：JDK 8 或 11、Maven 3.6 以上、MySQL 5.7 或 8.0、Node 14 以上（如果前端是 Vue）。版本不一致是启动失败的第一大原因，尤其是 JDK 版本和新旧 Maven 插件的兼容性。

环境就绪后按以下顺序操作：

1. 创建数据库，字符集选择 utf8mb4，排序规则建议 utf8mb4_general_ci。然后在里面执行项目提供的 SQL 脚本。SQL 里一般会带初始数据，包括管理员账号和测试用户，不要手贱把初始数据清了，后面调试全靠它。

2. 打开后端项目的 application.yml，修改数据库连接地址、用户名、密码。如果 Redis 是可选组件，暂时不用就先把 Redis 配置注释掉，避免本地没起 Redis 导致启动失败。

3. 启动后端。可以在 IDE 里直接运行主类，也可以mvn spring-boot:run。看到诸如“Started Application in xx seconds”的日志就说明启动成功。如果启动失败，重点看最底部的异常信息，通常是数据库连不上或端口被占用。

4. 如果包含前端工程，在 frontend 目录下执行npm install，然后npm run serve。开发环境下 Vite 或 webpack-dev-server 会默认监听 5173 或 8080 端口，注意和后端端口区分开。

5. 最后验证接口连通性。直接在浏览器访问后端接口地址，比如http://localhost:8080/api/pool/list，能返回 JSON 就说明后端正常；再访问前端开发服务器，能正常跳转并拉到后端数据，说明前后端联调成功。

4.2 常见问题速查表与独家排查技巧

这个项目看起来小，实际调试起来该遇到的坑一个都不会少。我整理了一张排查表，都是我实际踩过的，照着查能帮你省下大把时间。

排查还有一个通用大技巧：别盯着前端报错，要看后端控制台。前后端分离项目里，前端报 500 的时候实际错误信息全在后端日志里，养成先翻后端日志的习惯，排查效率至少提升一倍。

提示：修改了 application.yml 配置后，一定要重启后端服务，Spring Boot 默认不会热加载配置文件。我就见过有人改了数据库密码没重启，卡在那里半天找不到原因。

4.3 调试定制：拿到代码后如何做二次开发

标题里写了“调试定制”，说白了就是拿到这套代码后，除了跑通，还要能按自己的需求改出新功能。很多同学只会跑不会改，答辩时老师一问“你做的项目有什么独特之处”就卡壳了。

二次开发建议从两个方向入手。一个是改造现有模块，比如给课程预约加一个“拼团优惠”逻辑，或者在充值模块增加“阶梯充值赠送”规则，这些改动只涉及个别字段和几段计算逻辑，难度不高但足以成为你的特色功能。另一个是增加新模块，比如给系统增加数据可视化统计，用图表展示每日预约量、课程热门程度、教练带教人数排行，这类功能用一个新接口加一个前端页面就能完成，但展示效果很亮眼。

我建议你在答辩前至少做一处“拿得出手”的改动。不需要大，把充值赠送做到位，或者把泳池查询做成带筛选排序的高级搜索，讲的时候说清楚“我基于原系统增加了什么功能，解决了什么问题，最后效果如何”，这比背十遍业务简介更管用。

5. 说明文档与论文的落地技巧

5.1 说明文档：别把它当成代码注释的堆砌

这年头很多同学习惯把说明文档写成操作手册的流水账，这是本末倒置。一份好的说明文档，应该能让一个从没接触过这个项目的人，看完后就知道系统解决什么问题、有哪些角色、每个角色能做什么、数据是怎么流转的。

建议说明文档至少包含这样几块：项目背景与目标、技术选型说明、部署环境要求、启动步骤、核心功能操作指南、接口列表、项目目录结构说明。目录结构说明尤其重要，很多同学拿到完整代码后看着几十个包不清楚哪个是干什么的，梳理清楚了对后续改代码和写论文都有帮助。

写文档时还有一个比较实用的习惯：每完成一个功能模块，就立刻把相关的表结构、接口、业务流程记录下来，不要等全部开发完再补。项目一复杂，过期记忆很容易出错，到时候再对着代码反推文档，效率低到让人崩溃。

5.2 论文写作重心：把业务流程和数据建模写透

论文方面，这个题目的写作重心得放在系统需求分析、总体设计、数据库设计、系统实现这几个章节，其中数据库设计是最能体现工作量的一部分。每一个表的字段、类型、约束、说明都要写得清清楚楚，最好再配上一张完整的 E-R 图。没有 E-R 图的数据库设计章节，评审老师一眼就能看出来是赶工的。

系统实现部分不要逐行贴代码，而是挑核心功能写关键代码片段，加文字说明。比如预约冲突检测这段，可以先贴出核心逻辑方法，然后用一段话说明思路：先查出用户已有预约，再判断时段重叠，最后更新人数，配合乐观锁防止并发。这种写法既显得专业，又不容易被代码泄漏带偏。

流程图也是论文里比较值得用的工具。游泳馆的核心业务流程，比如预约流程、充值流程、教学管理流程，各画一张标准流程图，放在对应章节里，视觉效果和逻辑表达都会好很多。画流程图用常用的绘图软件就行，不用刻意追求高级工具。

5.3 答辩准备：围绕四个关键词预演提问

答辩对项目的熟悉度要求很高，建议你把项目当作自己从零写的一样的心态来准备。围绕标题里的四个关键词，老师最可能问的问题无非是这些：

课程预约这块，最常见的问题是“同一个时间段有两个人同时抢一门课，系统怎么防止超卖”。回答思路就是先查人数、再更新人数，配合乐观锁控制并发，如果更新失败提示“课程人数已满”。泳池信息查询部分，老师可能会问“泳池实时状态怎么保证准确”，回答可以是前端定时轮询刷新，数据库状态由管理员维护。在线充值最容易被问的是“充值过程中支付平台重复回调怎么办”，直接回答幂等处理逻辑，先判断订单状态，再更新余额写流水。教学管理则会问“教学进度是怎么记录的”，把课时记录的流程讲清楚就足够了。

这些问题的回答思路，其实在上面的模块实现里都已经展开过。只要你把每一个模块的代码和数据流转真正理解了，答辩基本不会出现答不上来的情况。

注意：答辩千万不要背代码，要背业务逻辑和数据流程。老师问的是“你怎么设计的”，不是“这行代码是什么含义”。

6. 后端常见的隐藏坑与实战心得

6.1 MyBatis-Plus 与自动填充的“小陷阱”

用了 MyBatis-Plus 之后，很多同学都在时间字段上踩过坑。比如插入预约记录时，希望 create_time 自动填入当前时间。有些人会在实体类中写@TableField(fill = FieldFill.INSERT)，然后在处理器中实现 MetaObjectHandler 接口统一设置创建时间和更新时间。这个思路没错，但问题往往出在实体类字段名与数据表字段名不一致上。

当你设置了驼峰命名映射后，代码里的 createTime 会映射到数据库的 create_time，这个映射关系默认是开启的。但有些版本或配置下，如果关闭了下划线转驼峰，或者表字段用了不同的命名风格，自动填充就会失效。遇到插入时时间字段为 null 的情况，第一反应是检查驼峰映射配置，第二是看 MetaObjectHandler 有没有被 Spring 管理。这两个地方都没问题的话，基本就正常了。

另外，MyBatis-Plus 分页查询需要单独配置分页插件。有的同学以为引入依赖就能用 PageHelper，结果写了个自定义分页，代码绕了一大圈。直接在配置类里加一个 MybatisPlusInterceptor，设置 PaginationInnerInterceptor，就能直接用 Page 对象实现分页。分页插件配置好后，返回的分页结果里包含 total、pages 等字段，前端分页组件直接用这几个字段就可以了。

6.2 事务管理：不只在支付时要隔离，预约同样需要

很多同学对 @Transactional 的理解停留在“支付必须用事务”，其实预约流程同样需要严格控制。用户预约一门课时，至少要做这几件事：查询课程当前人数、判断是否已满、插入预约记录、更新课程已选人数。这四个动作跨越多张表，任何一步失败都会导致数据不一致。

比如插入预约记录成功，但更新课程人数时抛了异常，最终结果就是用户约上了课，人数却没增加，下次再约就可能出现超卖。解决办法就是在 Service 方法上加 @Transactional，任何异常都会触发回滚，两侧数据保持一致。

在写事务代码的时候还有几个细节：第一，事务只对 RuntimeException 回滚，业务异常时抛出自定义运行时异常或明确指定 rollbackFor；第二，事务方法不要写成 private，否则代理无法生效；第三，同类内的自调用this.xxx()会绕过代理，导致事务失效。这几个点虽然基础，但出问题的概率很高，而且一旦出了问题，排查成本也不小。

7. 效率工具与调试技巧

7.1 接口调试：别再只依赖前端页面了

前后端联调的时候，最痛苦的事情就是前端还没写好，后端接口已经完成后无法验证。这时候 Postman 或 Apifox 这类工具就非常值得用了。把每个接口按模块分组保存，登录接口获取 token，然后在每个需要认证的接口上配置 Authorization 请求头，就能独立验证接口逻辑，不用等页面出来以后再慢慢点。

用这类工具还有一个好处：可以直接复制接口的调用示例，生成接口文档，方便后续写论文或说明文档。后端的 controller 层写好参数校验和统一返回格式，前端对接时会轻松很多。我这里比较推荐统一返回 Result 对象，包含 code、message、data 三个字段，前端统一拦截处理，代码会干净很多。

7.2 IDEA 调试的几个快速定位技巧

Debug 是排查问题时最直接的手段。在 Spring Boot 项目里，我最常用的几个技巧是：在 Controller 第一行打端点，查看入参是否符合预期；在 Service 层关键判断处打条件断点，比如当用户 ID 为指定值时才停下；在 MyBatis-Plus 执行 SQL 前后查看控制台打印的预处理语句，确认最终执行的 SQL 是否真正符合意图。

还有一个比较容易忽略的事：MyBatis-Plus 控制台默认会输出 SQL 语句，如果看不到，可能是日志级别配置问题。在 application.yml 中把 mapper 包日志级别设置为 debug，就能看到完整的 SQL 和参数绑定。这个配置对排查查询类问题帮助非常大，建议写进项目的默认配置里，不要关掉。

8. 写在最后的心里话

这个游泳馆管理系统，最大的特点就是“该有的都有，但每一样又不复杂到失控”。它教会学生的最重要一件事，不是怎么写一个极其抽象的算法，而是怎么把一个真实的业务流程通过代码落下来。课程预约、在线充值、教学管理，每个模块拆开都不难，但串在一起就形成了一个完整的线上线下闭环。

我自己的感受是，做这类管理系统，最怕的不是技术不会，而是心智上轻视。很多人觉得增删改查有什么好做的，结果一写起来才发现，光是一个“预约冲突”就能把你绕进去。但只要你沉下心把这个系统完整搭一遍，你会发现 Spring Boot 的绝大多数日常玩法其实都覆盖了，而这种项目经验，正是以后进公司能直接上手干活的基础。

最后再分享一个小技巧：跑通系统后，不要立刻开始写论文。花三天时间，把自己当成用户反复操作几遍，发现问题就改，改完再跑。这种真实业务流的打磨过程，才是你做这个项目获得的最大收获。等系统用起来顺手了，论文和答辩准备就都水到渠成。