SSM+Vue装饰公司管理系统全解析：从需求拆解到毕设答辩

做毕业设计最怕的不是代码写不出来，而是题目拿到手里不知道怎么拆。前两天有个学弟问我“鲲龙装饰公司在线管理系统”这个题目怎么做，又是SSM又是Vue，还要做手机端适配，最后还要交一篇论文，光听题目就觉得头大。这种心情我太理解了，当年我自己做毕设的时候也这样，后来陆陆续续带过几届学生的毕设，发现这类管理系统的套路其实非常固定，关键是先把业务逻辑理清楚，技术选型走对方向，后面就是一马平川的事。

这篇文章就围绕“SSM + Vue + 手机端”这条主线，把鲲龙装饰公司在线管理系统从需求分析到开发实现、再到论文写作的完整路径捋一遍。我会把每个环节的取舍理由、踩过的坑、以及答辩时容易被问到的点都写出来。适合两种情况参考：一是正在做类似管理系统的毕业生，想找一份能直接落地的开发思路；二是想了解装饰装修行业信息化是怎么落地的人。文章内容偏实操，尽量少说虚的。

1. 装饰公司在线管理系统需求拆解：先理业务流程再写代码

1.1 业务流程梳理：系统到底在管什么

很多人做管理系统第一步就栽了，上来就画数据库表、写登录页面，结果做到一半发现功能之间对不上。做这种业务系统，第一步永远是搞清楚业务链条。装饰公司的核心业务链路是这样的：客户线上或者门店咨询，销售把客户信息录入系统；设计师接单后去现场量房，做方案设计和初步报价；方案定稿后转成正式合同；合同签订后创建装修项目，安排项目经理和施工队长；项目开工前做材料计划和采购清单，材料员统一采购进场；施工过程中项目经理按节点更新进度、上传工地照片；竣工后做验收和结算。

这条链路参与角色至少四类：管理员、设计师、项目经理（有些公司叫监理）、客户。另外材料员这类辅助角色在毕设里可以放进员工后台一起处理。角色不同，看到的菜单和操作按钮天然就不同。比如客户登录后应该直接看到“我的项目”“我的进度”“在线留言”，而设计师登录后看到的是“我的客户”“待设计方案”“项目进度上报”。如果不把角色权限和业务流绑在一起想，后面做权限控制的时候一定会改来改去。

我见过很多半途返工的毕设，原因都是业务没理清就开始建表。建表建到一半发现客户和用户两套体系对不上，项目状态不知道要拆多少种，材料是跟着订单走还是跟着项目走——这些问题的答案全在业务流程里。你先把业务链路画一遍，哪怕用笔在纸上画个圈都行，每一条连接线都对应后面的一张表、一个接口、一个前端页面。所以这一步真的别省。

1.2 功能模块划分与需求裁剪

基于上面这条业务流，合理的模块划分是：客户管理、项目管理、预算与合同管理、材料管理、施工进度管理、在线交流与留言、系统管理。客户管理负责客户信息的增删改查和跟进状态维护；项目管理从合同生效开始，维护项目基本信息、人员和状态流转；预算与合同管理解决报价单生成、合同登记和金额统计；材料管理覆盖材料信息维护、项目材料采购计划与进场确认；施工进度管理是手机端的核心，项目经理按节点更新进度并上传图片；在线留言则是客户和公司之间的异步沟通渠道。

放到毕业设计里，很多同学容易犯的错误就是功能贪多。有人说“老师指定要网上预约功能”，有人说“想加一个在线支付显得高级”。我特别强调一个观点：毕设功能在精不在多，业务闭环比花架子重要。做一个预约看房功能，涉及排班规则、时段冲突判断、短信提醒，全是新的复杂度；而做一个材料出库确认，其实只需要改一条状态字段。把有限的开发时间花在核心业务闭环上，系统完整度反而更高，论文的每个章节也都能落到实处，不会出现某个功能写了半页就写不下去的情况。

1.3 手机端范围定义：不要失控

题目里有“手机端”三个字，这个范围必须在一开始就定义清楚，否则后面容易失控。手机端不是另起一个App，也不是做一套独立的H5商城，最务实的做法是：核心业务支持移动浏览器访问，页面采用响应式布局，让客户在手机上能查进度、看预算、收留言；员工在手机浏览器上能操作进度更新、材料确认。这样技术方案完全基于Vue的响应式实现，不需要额外维护一套移动端代码，工作量可控，论文里也能写“移动端适配设计”这个章节，答辩时还能演示在手机上直接访问系统，现场效果很好。

在做范围定义的时候，我建议在论文的“需求分析”一章里明确写一行字：“手机端覆盖客户查询类功能和员工操作类功能，管理后台仍以桌面端为主”。这句话既是给老师看的，也是给自己定的边界。没有这个边界，你会不断在“要不要做App”“要不要做推送”“要不要做扫码签到”这些问题上纠结，纯粹消耗时间。毕设的时间就该往核心业务和稳定交付上投。

2. SSM+Vue技术选型分析：这套组合在毕设场景下的优势

2.1 都2026年了，为什么毕设还选SSM

这是答辩时第一个可能被老师问到的问题。别人都用Spring Boot了，你还在SSM，是不是技术太旧？你要能给出自己的理由：第一，SSM是Spring、SpringMVC、MyBatis三者的组合，它没有Spring Boot那么多“约定优于配置”的黑盒子，每一层都通过显式配置组装，这天然适合在论文里逐层分析，也方便你在答辩时讲清楚请求从浏览器到数据库到底走了一条什么路；第二，很多高校的Java课程和实验环节仍然以SSM为主要教学内容，用它做毕设意味着你的课程设计和毕业设计技术栈是一致的，学习成本低，遇到问题也好查资料；第三，项目规模属于典型的中小型管理系统，SSM在开发效率和运行性能上并不比Spring Boot差，MyBatis的SQL可控性在报表统计这类场景下反而更有优势。

回答这个问题时，千万不要表现出“我也知道Spring Boot更好”这种态度。技术选型没有绝对的对错，只有合适与不合适，你要强调SSM的配置透明性和学习价值。加上你用了JWT做认证、Vue 3做前后端分离、响应式布局做手机端适配，这套技术组合放在毕设里已经足够完整和现代了。

2.2 后端三层架构与事务边界

SSM最核心的写法是Controller-Service-Mapper三层。Controller只做参数接收、结果封装和路由转发，不做任何业务处理；Service承担所有业务逻辑，包括事务管理；Mapper就是数据访问层，只对应数据库的增删改查。实际开发中很多同学容易把三层混在一起写，在Controller里直接调Mapper，这是大忌。一旦业务逻辑多起来，事务控制不了，代码也没法测试。

Service接口和实现类分开写，事务注解加在实现类上。比如合同确认这个方法内部要同时更新合同状态、创建项目、生成初始预算，这三步必须在一个事务里完成，哪一步失败都要整体回滚，不然就会出现“合同签了但项目没建出来”的数据不一致问题。MyBatis的Mapper接口和XML文件要一一对应，XML命名空间写错的话启动就报错，这种错误自己排查特别浪费时间。还有一个小细节：Mapper接口的方法名不能重载，因为MyBatis是通过全限定名加方法名定位SQL的，重载方法会冲突。

2.3 Vue版本选择与脚手架搭建

Vue这块有个现实问题：官方生态全面转向Vue 3组合式API已经很久了，但很多老教程还是Vue 2选项式API的写法，图书馆里的毕设参考书也是新旧混杂。我的建议是直接选Vue 3 + Vite作为脚手架，原因有三个：Vite冷启动速度快，开发体验比webpack好太多；组合式API配合<script setup>写业务代码更简洁；2026年的答辩场景里，如果还在用Vue 2，老师大概率会追问“为什么不用新版本”。

唯一的坑是网上很多组件库示例还是Vue 2时代的写法，真遇到版本不兼容报错，要看一眼官方迁移文档。脚手架创建命令现在很稳定，选默认的Vue Router和状态管理选项即可，后面不需要的依赖再手动移除。前端项目结构我习惯这样组织：src/api放接口请求封装，src/router放路由配置，src/store或src/composables放全局状态，src/views按模块建目录，src/components放通用组件。目录清晰的好处是自己开发到后期好定位，论文里贴“项目目录结构图”也好看。

2.4 请求封装与状态管理的取舍

前后端交互用axios最成熟，统一封装一个request.js文件，配置baseURL和请求拦截器。拦截器里做两件事：从localStorage取JWT token放到请求头，响应状态码401时清掉本地登录信息并跳回登录页。这样每个页面里不需要重复写token逻辑，代码干净很多。

Vue这边我反而建议不要为了“技术亮点”硬上Pinia。这个系统的跨组件共享状态没有那么多，一个用户信息加一个项目列表视图状态，用provide/inject或者组件props回调就能解决。真要上Pinia，也请控制在用户状态和路由权限这两个store，不要每个页面都挂全局状态，否则调试起来反而混乱。答辩时被问到“状态管理”就直接说：项目规模不大，按需引入，大多数场景用组件通信已经足够，这反而是你对技术有判断力的体现。

2.5 版本搭配参考

直接给一套实践过且兼容良好的版本组合，省得自己踩版本坑。JDK用1.8就够了，Spring用5.3.x，SpringMVC同版本，MyBatis用3.5.x，连接池用Druid 1.2.x，MySQL 5.7或8.0都行。前端Vue 3.2.x + Vue Router 4.x + axios 1.x + Element Plus 2.x，移动端组件库用Vant 4，Vant 4完全基于Vue 3，手机端页面用它的Tabbar、Cell、Progress组件，开发效率会高非常多。

有一点提醒：前面说的是“我实际用过且稳定”的组合，网上很多教程给的版本比较老，比如Spring 4、MyBatis 3.2，这些老版本在高版本JDK下会有兼容问题。你如果完全照搬别人的pom.xml，启动时报错的概率很高。比较稳妥的方法是建一个空白Maven工程，从Spring官网或者权威示例里复制当前稳定版本坐标，然后逐个加上Druid和MySQL驱动。

3. 数据库设计：装饰公司业务的数据表结构

3.1 核心表结构与表关系

数据库是整个系统最不能返工的部分，因为前期表结构一旦定下来，后端的Mapper、前端的表单全要围着它转。装饰公司系统的核心表，按业务闭环来列大概是这几张：用户表、客户表、项目表、预算表、材料表、项目材料关联表、进度表、留言表。

用户表负责登录账号和角色，字段包括主键、用户名、密码（加密存储）、真实姓名、角色、联系电话、头像、创建时间。客户表负责客户业务信息，包括客户姓名、电话、需求描述、来源渠道、跟进状态、关联的用户id。项目表是业务的主线，包含项目编号、客户id、设计师id、项目经理id、状态、开工日期、预计完工日期。预算表关联项目id，存预算金额、费用明细JSON或子表、状态。材料表维护材料名称、规格、单位、供应商、单价。项目材料关联表记录每个项目用了哪些材料、数量、进场状态。进度表记录项目节点名称、完成状态、备注、更新时间。留言表记录客户与公司之间的沟通内容。

这里有极其关键的细节：客户和用户表要不要合一？很多毕设把客户单独建表，登录却用user表，最后客户登录不了。我的建议是分两个表但建立外键关联，user负责登录，customer负责业务字段和身份。客户注册时生成一条user记录，角色为ROLE_CUSTOMER，同时在customer表里加一条记录，用外键关联。业务查询统一通过customer的信息去拉user的登录态，这样既保证登录体系统一，又不让客户业务字段污染用户表。

3.2 状态字段设计与枚举

项目状态、材料状态、留言状态这类字段，我强烈建议存整数（0、1、2……），不要存中文状态字符串。好处有两点：前端展示时可以根据数字映射到不同标签颜色和文案，比如0待量房用灰色、1设计阶段用蓝色、2施工中用黄色、3已竣工用绿色；后端做统计筛选时where status = 2写起来简洁，索引命中率也比字符串高。还有一个容易忽略的好处：以后要加状态，只需要在枚举类或者前端字典里加一个数字映射，不用改历史数据。

前端可以把状态枚举统一放到一个constants.js文件里，写一个statusMap对象，页面里渲染时根据数字取文案和颜色。后端Java端也建议定义对应的枚举类或者常量类，Service层判断状态流转时不要散落魔法数字，统一引用常量。这样前后端的状态口径一致，不会出现“前端显示已竣工，后端状态还是3”这种对不上的问题。

3.3 MyBatis动态SQL与统计查询

装饰公司系统里一定会用到按时间段、按状态筛选的统计数据，比如某个月的项目数量、进行中的项目预算总和。这种查询条件不固定，最适合用MyBatis的<if>、<where>、<choose>动态SQL标签来拼接，而不是在Java代码里拼SQL字符串。下面这个例子是统计不同状态下项目数量的典型写法：

<select id="selectProjectCountByStatus" resultType="map"> SELECT status AS statusValue, COUNT(*) AS totalCount FROM project <where> <if test="beginTime != null"> AND create_time &gt;= #{beginTime} </if> <if test="endTime != null"> AND create_time &lt;= #{endTime} </if> </where> GROUP BY status </select>

实际操作中我习惯把这类统计SQL单独放到Mapper的XML里，每条SQL上加注释说明业务含义，论文的数据库设计章节截图也用得上。另外需要注意，<where>标签虽然会自动去掉多余的AND，但如果你在里面用了SQL片段<include>，片段里的子查询是要自行控制闭合的，写错时错误提示非常隐蔽。我建议写动态SQL时先在MySQL客户端里把完整SQL跑一遍，确定无误再粘回XML，这样能省下大量排查时间。

3.4 命名规范与索引基础

这个点看似无关紧要，答辩时老师其实很看重。表名用全小写加下划线，比如project_material，不要用驼峰表名；字段名统一小写加下划线，比如project_id，MyBatis里开启mapUnderscoreToCamelCase=true，查询结果就能自动映射到JavaBean的驼峰属性上。为什么不直接用驼峰？因为MySQL在Linux环境下的表名大小写敏感，Windows不敏感，开发环境一致还好，一旦部署到服务器就容易出现“表名明明存在却报找不到”的诡异问题。

索引方面，核心表的主键索引用自带的主键，业务查询常用的外键字段和状态字段建议建普通索引，比如project表的customer_id、status，progress表的project_id。毕设阶段不需要建太多索引，但要体现出你有这个意识。写论文时可以在数据库设计小节里放一张索引表，列出索引名、字段、用途，这个细节非常加分。

4. 手机端核心模块实现与响应式适配

4.1 JWT登录认证与安全注意点

登录是整个系统的门面，也是答辩演示时的第一个交互。认证方案用JWT是非常标准的做法：用户提交用户名密码，后端校验通过后，用用户id和角色生成token，设置过期时间，返回给前端；前端每次请求在Authorization头里带token，后端拦截器解析token并把用户身份放到ThreadLocal里供业务代码使用。JWT的好处是服务端不需要存session，天然适合前后端分离项目，手机端访问时也完全没问题。

生成token的代码大概是这样的：

String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("username", user.getUsername()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 30 * 60 * 1000L)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

有一点要特别提醒：JWT的payload默认是Base64编码，不是加密的，千万别往里面塞用户密码或者身份证号这类敏感信息，最多放用户id、用户名、角色和过期时间。密钥用固定配置，建议长度不少于32位，防止被暴力猜解。前端的token存储用localStorage还是cookie各有取舍，毕设场景下localStorage简单直接，但要跟老师说明清楚它的XSS风险。

4.2 权限拦截器配置

SSM里配置拦截器是在SpringMVC配置文件中注册的，拦截路径一般写成/api/**。把所有需要登录才能访问的接口统一放在/api前缀下，登录接口放行，静态资源比如上传的图片路径也放行，然后拦截器对/api下的请求做token校验。解析成功就把用户信息设置到请求上下文中，Controller层从上下文取当前用户，做业务判断的时候用得到。

这里有个经验：接口文档工具、数据源监控页面这类调试工具，如果你引入了相关依赖，要把它们的路径加到排除列表，否则本地调试时总会莫名其妙被拦。权限校验按角色做二次判断，比如客户端的接口只允许ROLE_CUSTOMER角色访问。毕设层面用Service层判断就足够，不用去引入复杂的安全框架做方法级权限管理。把权限逻辑写清楚，答辩时能讲明白即可。

4.3 施工进度模块的移动端展示

手机端最核心的模块就是施工进度查询。客户在手机浏览器上打开系统，看到的是项目进度时间线：水电改造、泥瓦工、木工、油漆等每一道工序对应一个节点，节点状态分为未开始、进行中、已完成，配合项目经理上传的工地照片，形成一条清晰的时间轴。

这里的实现思路是后端提供按项目id查询进度的接口，返回节点状态列表和照片地址数组，前端手机页面用Vant的时间线组件渲染，工序节点显示状态颜色、备注和更新时间。进度更新时项目经理在手机端上传图片和文字说明，后端将图片存储到服务器指定目录，数据库仅存访问路径。图片上传要特别处理：限制单个文件大小在5MB以内，格式只允许jpg和png，文件名用UUID重新生成，不要用前端传过来的原始文件名，这样可以防止路径穿越和文件名冲突问题。存储目录要做按月分文件夹的习惯，否则图片多起来一个文件夹几百个文件，找起来和备份起来都很痛苦。

4.4 响应式布局的关键细节

手机上要访问得好，光靠Element Plus默认的桌面布局是不够的。我在实际项目里总结三个非常关键的点，基本覆盖常见问题。

第一，viewport设置不能少。HTML模板里必须写<meta name="viewport" content="width=device-width, initial-scale=1.0">，否则手机浏览器会按980px的默认宽度渲染页面，字会变得特别小，这是很多人第一步就忽略的问题。

第二，栅格布局要处理断点。Element Plus的Row和Col组件提供了xs、sm、md、lg等断点属性，比如项目列表在电脑上是四列，到手机端就变一列，就靠这个属性控制。千万不要用固定像素宽度写死，否则手机上一出现横向滚动条，体验基本就崩了。

第三，字体和点击区域。移动端交互靠手指，按钮和列表项至少要有44像素的可点区域，字体建议用rem或vw适配不同屏幕。可以设置根元素的font-size随屏幕宽度变化，然后在样式中用rem作为单位，实测下来在不同尺寸手机上效果很稳定。写论文时，这部分可以放到“移动端交互设计”小节，配合两三个布局截图说明你的适配逻辑。

4.5 手机端与桌面端的功能裁剪

手机端页面不要试图把桌面端功能全部复制一遍。手机端应该优先做信息查询和状态操作类功能，比如客户查看进度、查看预算明细、留言咨询；员工更新节点状态、审批材料单。像系统管理里的用户维护、角色分配这类管理后台功能，手机上就不要做了，操作繁琐且容易误触。

这个“端的功能裁剪”思路，放到论文里就是“移动端交互设计”这一小节的加分内容。你可以在需求分析里就明确说明哪些功能是移动端优先、哪些功能是桌面端专属，再配一张功能分布表。答辩老师看到你能主动做这种产品层面的取舍，会觉得你不只是在写代码，而是真的在思考这个系统怎么被使用。

5. 毕业设计论文写作：从系统到文档的转化

5.1 论文结构安排

很多同学代码做完了论文写不出来，核心原因是把论文当成“软件开发文档”来写，而不是当“研究过程记录”来写。标准的毕设论文结构是：摘要、绪论、相关技术、需求分析、系统设计、系统实现、测试、总结、参考文献。先记住六个字：“背景-技术-设计-实现-测试”。

摘要不要最后才写，反而应该最早写完一版，因为摘要逼你把项目价值用三句话讲清楚，讲不清楚说明你业务还没想透，后面写什么都会别扭。绪论里写研究背景和意义，结合装饰行业信息化管理的实际需求，再写国内外发展现状，这部分就是文献综述的位置。相关技术章节把SSM、Vue、JWT、响应式布局这些技术逐个介绍，但不要写成长篇说明书，重点是“为什么选它、它解决什么问题”。

5.2 需求分析章节怎么写才能拿高分

需求分析是论文里字最多但最容易被写成流水账的部分。老师只看两个点：有没有用例图、有没有明确的功能需求表。用例图画的时候要按角色分开画，客户一个用例图、管理员一个用例图，不要把所有角色全画在一张图里。功能需求表用三列表达：模块名称、功能描述、优先级，比如“进度管理模块：提供项目经理更新施工节点状态的功能，优先级高”。这样写出来的需求分析一眼就很清晰。

非功能需求也别漏了：系统响应时间、并发用户数、安全性、可维护性。不用写多，每类一两句话带清楚就行。比如“系统核心查询接口响应时间在正常网络环境下不超过1秒”“采用JWT保证接口访问安全性”。这些内容看起来虚，但它是论文完整度的体现，也是后面测试章节的数据基准。

5.3 截图、数据量与测试记录准备

论文里的系统截图不要临时截两张大图充数，每张截图要有自己的编号和一句话说明，比如“图5-3 项目经理端进度更新界面”。测试章节一定要有测试用例表，列清楚用例编号、测试模块、操作步骤、预期结果、实际结果、是否通过。这个表格一定用真实的操作记录填，每个功能模块至少三条用例。

为了让测试数据好看，开发阶段就要往数据库里造足够多的模拟数据，比如三四个装修项目，每个项目有七八条进度记录，客户留言若干条，材料信息几十条。数据量太少的系统截图会露怯，也影响最终现场演示。造数据的时候要注意前后逻辑自洽，比如项目状态是“施工中”，那它的进度节点里就应该有已完成、进行中、未开始的工序，别出现“已竣工项目还没有验收记录”这种低级矛盾。

5.4 答辩高频问题准备

答辩老师最喜欢问的问题集中在这几个：“你的系统相比传统线下管理，效率提升体现在哪里？”“如果用户量变大，你的系统哪些地方会成为瓶颈？”“手机端数据是实时更新的还是定时刷新的？”这些问题一定要在答辩前想好答案。

第一个问题从信息流转速度上答，比如客户无需电话追问就能在手机上看到进度，项目经理一次录入全员可见，数据从“人找信息”变成了“信息找人”。第二个问题从数据库索引、接口缓存、静态资源优化三个层面答，哪怕你没做缓存也要能说出思路，比如“后续可以考虑在查询频率高的进度接口上做Redis缓存”。第三个问题老实回答通过接口实时拉取，但说明设计了页面缓存策略来减少重复请求。三个问题准备下来，基本能覆盖大多数追问场景。

6. 常见问题与避坑排查实录

6.1 前后端联调：跨域和响应格式

前后端分离项目联调时第一个遇到的就是跨域问题，表现形式是浏览器控制台报blocked by CORS policy。解决方式是在后端配置跨域过滤器，允许指定origin、方法和请求头。配置时要小心，不要把允许的origin写成*然后还启用allowCredentials(true)，这两个配置在浏览器规范里是冲突的，会直接导致跨域请求失败。

另外，联调时前后端要约定统一的响应格式，比如{ code, message, data }。后端所有Controller返回格式统一由Result对象包装，前端在拦截器里先判断code是200再取data，否则弹message提示。没有这个约定的话，前端每个接口都要单独处理错误，代码量翻倍，调试成本极高。接口文档在毕设阶段用简单的表格记录就行，写上路径、参数、返回格式，自己联调和写论文都需要。

6.2 手机真机调试连不上本机服务

手机端开发最常见的坑，就是手机访问电脑上的项目地址时提示无法访问。一般原因是三个：电脑防火墙没放行项目端口、手机和电脑不在同一个局域网、后端服务绑定在127.0.0.1而不是0.0.0.0。排查顺序是：先确认手机和电脑连的是同一个WiFi；再检查电脑的局域网IP地址，前端页面里接口地址要写局域网IP，不要写localhost；最后检查防火墙并放行端口。

还有一个容易忽略的细节：电脑同时开的有线网和无线网时，局域网IP可能有两个，手机访问的要是在无线网卡对应的那个IP才行。测试时用ipconfig看一下无线网卡的IPv4地址，而不是随便拿一个内网IP就用。后端启动参数里如果没有手动绑定，默认监听所有网卡的0.0.0.0，那个还好，但如果指定了127.0.0.1，手机就永远连不上。

6.3 启动过程常见报错速查

下面这张表是我实操中遇到的报错排查记录，覆盖从环境配置到运行期间的高频问题：

这些坑几乎每个人都会踩一遍，遇到先看自己是不是上面表格里的情况。不要一报错就去改大段代码，先看报错信息的前几行，定位到具体配置项，很多时候就是个路径、一个注解的问题。

6.4 毕设节奏管理的一点经验

做毕设最大的敌人不是技术难度，而是拖延和返工。我比较推荐的节奏是：第一周只做需求分析和数据库设计，表结构评审通过后再写代码；第二周到第五周按模块开发，先做后端再做前端；第六周联调、补数据、写论文。这种节奏每隔几天就有明确产出，心里踏实很多。千万别想着把所有代码写完再一次性写论文，到那时候你已经忘了当初为什么这么设计，论文写出来质量会很差。

写到这里，整个项目从拆题到落地的路径基本讲清了。我个人做完这个类型系统的体会是：SSM+Vue这套组合虽然不新奇，但只要把业务闭环理清楚、把数据库设计扎实做好、把手机端体验认真适配，它就是一个非常完整的毕业设计作品。答辩的时候你不用吹嘘用了多新的技术，能清楚讲明白每一步为什么这么设计，本身就是最好的展示。

最后再分享一个小技巧：把项目跑起来之后，用不同角色的账号在电脑和手机上分别操作一遍完整流程，比如客户从登录到查看进度，项目经理从登录到更新节点状态。这个动作能帮你发现很多“逻辑上没问题但实际用起来很别扭”的场景，也会让你在答辩时对整个系统如数家珍。祝各位顺利答辩。