企业官网建设流程全解析

2026届本科毕设，我做了ssm+vue家政服务管理平台，论文和程序整套交付。这个题目当时选的时候没多想，后面做下来才发现它是个非常经典的组合：后端用SSM框架（Spring + SpringMVC + MyBatis），前端用Vue全家桶，业务上覆盖了用户下单、家政人员接单、管理员审核的完整管理闭环。对计算机专业的学生来说，这个题目难度适中、工作量可控，又能把大学四年学的核心东西串起来。如果你已经选了或者正在纠结这个题目，这篇内容就是一个过来人的完整记录：从技术选型到数据库设计，从后端接口到前端联调，从论文框架到答辩避坑，全部讲透，按这个节奏推进，整个项目能少走很多弯路。

1. 项目整体设计与技术选型解析

1.1 为什么选SSM+Vue，而不是SpringBoot+Vue

不少同学会问，现在企业里基本都用SpringBoot，学校毕设怎么还在用SSM？这个问题我在答辩时也认真想过。SSM是很多高校JavaWeb课程的主线，评委老师对这个技术栈非常熟悉，看到项目用SSM，至少不会在“你为什么要发明新轮子”这种问题上卡住。更重要的是，SSM需要手动维护Spring容器、SpringMVC配置和MyBatis映射，这种“手动挡”的配置过程会逼着你去理解IoC、AOP、DispatcherServlet这些底层概念。你要是真把Bean装配、事务传播、Mapper代理这些讲明白了，答辩反而更容易拿高分。

当然，SSM也有明显的槽点，比如配置繁琐、依赖版本容易冲突、启动调试效率低。所以我在论文里专门用了半页讲这个选型对比，不是回避SpringBoot，而是说明SSM是理解SpringBoot的“前置课”。如果你能把这个逻辑讲清楚，面试官会觉得你既懂原理又能落地上手，而不是只会背注解。至于项目本身，我在参考一些开源项目时也看过若依Vue的代码风格，它那种基于注解的权限拦截设计，其实可以简化后搬到SSM项目里，只要你能说清楚原理，这不是抄袭，是借鉴。

1.2 家政平台的功能模块怎么拆，才不会被老师喷

家政平台最常见的用法，就是用户在网上找保洁、月嫂、家电清洗这类服务，所以系统天然有三种角色：普通用户、家政人员、系统管理员。我当时规划的模块如下：

• 用户端：注册/登录、浏览服务项目、按分类筛选、选择服务时间与地址后下单、模拟支付、查看订单状态、取消未接订单、完成后评价。
• 家政端：接单、更新服务进度（待接单→已接单→服务中→待评价）、查看我的订单和预估收入、维护个人资料。
• 管理端：用户管理、家政人员审核管理、服务项目上下架、订单全量查询与异常处理、评价审核与删除、统计报表（月订单量、月收入、分类热度）。

模块不建议铺得太大，比如支付我用的就是模拟支付，因为真实接入支付宝沙箱也会耗掉不少时间，预算和排期都要考虑。但有一个原则不能丢：业务流程必须闭环。用户下单后，订单状态要有明确的流转路径；用户评价后，管理员能看见并能处理；家政人员接单时，不能出现两个人都抢到同一单的情况。把这些闭环做完整，比多加一个花哨却没有深度的“猜你喜欢”模块更有竞争力。

1.3 三种角色权限设计的正确姿势

权限设计是这类管理系统里老师最爱问的点。我的做法很直接：后端用一个登录接口签发token字符串（UUID或者简单的签名串），前端把它存到localStorage里，每个请求通过axios拦截器放到请求头Authorization上。后端写一个拦截器校验token是否存在、是否过期，再配合角色字段做权限控制。

具体到代码层面，我定义了一个BaseController，里面提供两个方法：getCurrentUser() 和 hasRole(String role)，所有需要权限判断的接口都先调用这两个方法。订单操作通常是用户下单、家政抢单，这两个操作都要校验角色和状态。比如用户想取消订单，接口里先判断订单是不是属于当前用户，再判断状态是不是“待接单”，两个条件都满足才允许取消。

我简单说下订单状态机，这算是一个加分项：

• 0 待接单
• 1 已接单
• 2 服务中
• 3 待评价
• 4 已完成
• 5 已取消

每次状态变更，代码里都做一个前置状态检查，比如只有状态为0的订单才能被家政人员接单，只有状态为1的订单才能被家政人员更新为“服务中”。这样能防止前端乱传状态篡改数据，论文里也能画一张状态流转图，非常直观。

2. 核心功能实现与数据库设计

2.1 数据库表结构设计，关键字段一次说清

数据库设计是整个系统的基础，我没少在这上面返工。家政平台实际需要的表没有想象中那么多，我当时一共设计了9张表，核心的是这几张：

几个容易踩坑的细节：

• 金额字段一定要用DECIMAL(10,2)，不要用double，浮点数计算金额会丢精度，答辩时如果被问到这是硬伤。
• 订单号不要用自增id，要单独生成一个唯一业务订单号，比如时间戳加随机数，或者用“服务类型编码+年月日+流水号”。
• 外键不一定要建在数据库层。我当时只在逻辑上维护关联关系，没有用物理外键，因为后续测试数据清理、删除操作会更方便，但ER图上要把关系画出来。
• 状态字段用TINYINT，注释里写明0/1/2分别代表什么意思，避免后面前后端联调时发生“0到底是未支付还是已取消”的分歧。
• 所有表都加create_time和update_time，update_time在更新时自动刷新，这是一个好习惯。

2.2 后端SSM框架搭建与核心业务接口

SSM的搭建过程，说穿了就是把Spring、SpringMVC、MyBatis三个框架配置到同一个容器里。Maven依赖上，我用的组合是：spring-webmvc、spring-jdbc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databind、lombok。这里要注意，lombok在IDEA里需要安装插件，不然编译会报找不到getter/setter。

配置上分三个文件：applicationContext.xml管理Service和Mapper，spring-mvc.xml管理Controller和注解驱动，jdbc.properties放数据库连接信息。我的数据库连接串用到了这几个参数：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/housekeeping?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=root

这里有个坑：MySQL 5.7和8.0的驱动类不一样，8.0要写成com.mysql.cj.jdbc.Driver，而且必须带serverTimezone参数，不然连接时会报时区错误。我当时在这里卡了快一个小时。

核心业务接口上，我重点实现了三个：

1. 下单接口：先校验用户、服务项目、预约时间是否合法，然后生成订单号，插入订单记录，返回创建成功的订单信息。整个流程加了@Transactional，如果插入失败就回滚。
2. 接单接口：这里我用了乐观锁思路，SQL语句不是简单的update orders set status=1 where id=订单id，而是update orders set status=1 where id=订单id and status=0。如果返回影响行数是0，说明订单已经被别人抢走了，后端直接抛出业务异常提示“手慢了，订单已被接”。这个细节在论文里写进去，老师会觉得你考虑了并发问题。
3. 完成订单接口：只有服务状态为“服务中”的订单才能变成“待评价”，同样做状态前置校验。

2.3 前端Vue页面、路由与状态管理

前端我用的是Vue CLI脚手架，用的是Vue 2 + Element UI，因为这是当时最稳的组合，网上资料也多。创建完项目后，第一件事就是装依赖：vue-router、vuex、axios、element-ui。你可能会遇到“vue安装及环境配置”的问题，尤其是Node版本，我当时用的Node 14，Vue CLI 4，整个安装过程比较顺。

路由结构我是按角色拆的：

• /login 登录页，独立布局
• /home 用户端主布局，下面嵌套首页、服务列表、服务详情、我的订单、个人中心
• /worker 家政端主布局，下面是接单大厅、我的服务单、收益统计
• /admin 管理端主布局，下面是用户管理、服务管理、订单管理、评价管理、数据概览

路由守卫我用的是router.beforeEach，逻辑很简单：如果访问的页面要求登录而当前没有token，跳转到/login；如果访问的是管理端但没有admin角色，跳回首页并提示“无权访问”。这里需要留意的是，Vue Router的meta里要加requiresAuth和role两个字段，不然守卫里判断起来很别扭。

状态管理我用Vuex存当前用户信息、角色、token。每个模块的页面里，涉及删除、状态变更的操作，我都在表格刷新后重新拉取列表数据，不做手动逗状态，这样能减少不少bug。

2.4 前后端联调，跨域和格式问题这样处理

前后端分离最烦人的就是跨域。我的做法是开发阶段用vue.config.js的devServer代理，把所有/api开头的请求转发到localhost:8080：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } }

这样前端里请求/api/login，实际后端收到的是/login，开发环境下根本不用处理CORS。但到了部署阶段，我把前端npm run build后的dist目录放进了后端的静态资源目录，让Tomcat同时托管前端页面和后端接口，这样连跨域问题都消失了。

联调时最容易踩的坑有三个：

• 后端返回的时间是“Wed Jun 01 2026 10:00:00 GMT+0800”这种格式，前端显示不友好。解决方式是在实体类的Date字段上加上@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")。
• 自增主键Long类型传到前端会有精度丢失问题。解决方式是把主键序列化为String，或者前端不用id做精确操作。
• 接口返回格式不统一，有的地方返回对象、有的地方返回List，导致前端axios封装困难。我建议后端所有接口统一返回Result对象，里面至少包含code、message、data三个字段，前端在响应拦截器里判断code是否等于200，再决定Message提示还是直接返回data。

3. 论文写作的框架与技巧

3.1 论文目录怎么定，内容比例怎么分配

很多同学做完了项目，结果论文不知道怎么下笔。我的论文目录是这样安排的：

• 第一章 绪论：选题背景、国内外研究现状、研究目的与意义、论文组织结构
• 第二章 相关技术介绍：SSM框架、Vue.js、MySQL、前后端分离技术
• 第三章 系统需求分析：可行性分析、功能需求、非功能需求、用例图
• 第四章 系统总体设计：系统架构设计、功能模块设计、数据库设计
• 第五章 系统详细设计与实现：后端核心模块设计、前端核心模块实现、关键代码讲解
• 第六章 系统测试：测试环境、测试用例、测试结果分析
• 第七章 总结与展望

字数建议上，当时导师给我的比例是全文1.5万字左右，第一章1500字，第二章1500字，第三章2000字，第四章2500字，第五章3000字，第六章1500字，第七章800字，再加上摘要和参考文献，刚好1.5万上下。你不能把主要篇幅全堆在“相关技术介绍”上，那个部分字数再多也体现不出你的工作量，评审老师更看重需求分析、设计、实现和测试。

3.2 需求分析章节，最容易拿分也最容易写成说明书

需求分析写得好的关键，是把“用户想要什么”翻译成“系统要做什么”。我建议你用表格形式写用例描述，不要只放一张用例图了事。拿“用户下单”这个用例来说，我会分栏写：用例名称、参与者、前置条件、主事件流、异常流、后置条件。主事件流写：用户选择服务项目→选择预约时间→填写服务地址→提交订单→系统校验→生成订单号→返回下单成功。异常流写：预约时间早于当前时间、地址为空、服务项目已下架等。

在收集需求的初期，我还做了一件事：找周边做过保洁服务的同学和家长聊了十几分钟，把大家最在意的“预约时间是否准点”“价格是否透明”“接单快不快”这些问题整理成功能点。这部分内容写进“可行性分析”里非常自然，比空谈“随着生活水平提高”套话要真实得多，也能体现你的调研能力。

3.3 设计与实现章节，贴代码与截图的火候把控

详细设计章节里，代码不要整段全部贴，评审老师不会逐行读。我的做法是挑核心片段，比如接单接口的乐观锁更新SQL、token拦截器的校验逻辑、Vue路由守卫的代码，一共贴了六七段，每段后面都用两三句说明这段代码解决了什么问题。其他常规的增删改查，用功能和截图带过就行。

截图也有讲究。不要只有页面整体外观，要有操作过程或数据的对应。举例来说，管理端“服务项目上下架”功能，我会截两张图：一张是管理员点击“下架”的界面，另一张是用户端该服务项目不再显示的界面。这种“前后呼应”的截图，实际上是在向老师证明你的功能是真的联调通了，而不只是页面画出来了。

除了代码和截图，每个模块最好配一个时序图。画图工具我用的是ProcessOn，画出来导出图片插入论文，清晰度足够。图下面一定要加图题，比如“图5-3 用户下单时序图”，正文里也必须有引用，否则图表没有意义。

3.4 论文查重的几个必看技巧

查重是毕设论文的最后一关，也是最容易焦虑的一关。我最想提醒你的是：相关技术章节是重灾区，因为框架概念就那些话，大家都在写“Spring是一个轻量级开源框架……”，重复率很容易拉高。我的处理方式是，把重点从概念名词挪到“这个项目里具体怎么用”上，例如把“Spring”的描述改成“本项目通过Spring的IoC容器管理Service层依赖，在applicationContext.xml中配置了数据源和事务管理器”，这样既说明原理，又有项目针对性，重复率明显降低。

另外，摘要和绪论不要最后一天再写，最好在项目做到一半的时候写初稿，因为那时候你对系统最有感觉，写完也踏实。查重系统一般以“连续13个字相同”为判定标准，所以长句分段、换词、调整语序这些技巧能用上，但不要为了降重把句子改得不成样子，导师一眼就能看出来。

4. 项目部署与常见问题排查

4.1 开发环境配置：从零到能跑起来

拿到一份新的SSM+Vue项目压缩包，很多人第一步就卡在环境上。先列一下我最终的开发环境：JDK 1.8、IDEA 2023、Maven 3.8、MySQL 8.0、Node 14、Vue CLI 4。如果你用的是更高版本，比如JDK 17或者Node 18，不是不能用，但要注意Maven依赖兼容性和sass编译可能出现的坑。

整个导入流程其实可以标准化：

1. 在后端目录找到pom.xml，用IDEA以Maven项目方式打开，等待依赖下载完成。如果下载慢，在Maven的settings.xml里配置阿里云镜像。
2. 在resources目录下改jdbc.properties，把数据库名、用户名、密码改成你自己的。
3. 用Navicat或命令行执行项目附带的housekeeping.sql脚本，把数据库表结构和初始数据都导入。
4. 配置Tomcat 8.5或9.0，把后端项目部署上去，启动后先访问接口测试路径，比如http://localhost:8080/api/login，看到JSON返回说明后端没问题。
5. 前端目录下执行npm install，这一步最容易出问题，如果报错就删除node_modules和package-lock.json再重新装一次。
6. 执行npm run serve，浏览器访问8081端口（Vue默认8080，但后端占用了，我改成了8081），能打开登录页就完成了。

4.2 高频报错与排查方法

我把自己当时遇到的和同学来问的报错整理成了一个速查表，按这个表排查问题会快很多：

排查问题时记住一个原则：先看后端日志，再看浏览器Network面板，最后才看代码。很多人一上来就翻代码，结果发现是数据库没启动，浪费时间。

4.3 打包部署：本地验证与远程发布

毕设答辩一般要求本地演示，所以打包部署的重点是“在老师电脑上也能跑”。我个人建议准备两套方案：

方案A（本地演示）：把MySQL、Tomcat都装好，前端用npm run serve，后端用IDEA启动。这个方案最方便，代码改完直接热刷新，演示时如果老师想让你改个数据也能快速操作。缺点是如果你的电脑性能一般，Tomcat加Node两个进程会比较吃内存。

方案B（纯部署）：前端npm run build生成dist目录，把dist里的文件复制到后端项目的webapp目录下，然后后端打war包放到Tomcat的webapps里，启动Tomcat后直接访问localhost:8080就能看到整个系统。这个方案启动更轻，但缺点是你想改前端代码就得重新build。我答辩前用的是方案A，但在虚拟机里额外验证了方案B，以防现场网络或环境出问题。

如果你想要远程展示，也可以部署到云服务器上。基本流程是：服务器装JDK、Tomcat、MySQL、Nginx，然后后端war包放Tomcat，前端dist放Nginx，配置Nginx代理/api到Tomcat。需要注意在服务器控制台开放8080和80端口的安全组规则，否则外部访问不到。这部分属于常规操作，一步步配就能通，但记住要在演示前几天自己远程访问测试，不要等到答辩当天才临时抱佛脚。

5. 避坑经验与优化建议

5.1 时间规划，别把论文全部拖到最后

我见过太多人，前两个月摸鱼，最后两周通宵赶代码和论文，质量可想而知。按你从3月初开始做、6月底答辩来算，我给一份可行的排期：

我这里最想强调两件事：第一，数据库设计最晚第5周要定稿，不然后面所有代码都会推倒重来；第二，论文绪论和相关技术两章可以在第3周就开始写，项目前期的灵感正好用得上，不要等到代码全写完了再回头憋字。

5.2 答辩常见提问，提前准备好这8个

答辩老师时间有限，问的问题离不开这几个方向。我建议你提前把答案写下来，反复练：

• 为什么选择SSM框架，不用SpringBoot？回答思路：SSM是经典技术栈，通过手工配置能理解框架底层，并说明你也会SpringBoot。
• 系统有哪些角色，权限是怎么控制的？回答思路：三种角色，token加拦截器，角色字段校验。
• 订单状态是怎么流转的？回答思路：画状态机图，说明每个状态的前置条件和可执行操作。
• 并发情况下怎么保证一个订单只能被一个家政人员接单？回答思路：乐观锁，update where status=0。
• 数据库表之间是怎么关联的？回答思路：找出订单表，讲user、service_item、evaluation与它的关系。
• 前端路由守卫是做什么的？回答思路：验证登录状态和角色权限，阻止越权访问。
• 如果用户下单后不想服务了，怎么退款？回答思路：说明取消订单逻辑，以及限制条件（待接单状态下可取消）。
• 这个系统还有什么不足，以后怎么改进？回答思路：诚实说出两点不足，比如没接真实支付、没做消息推送，然后说后续可以怎么扩展。

上面的问题不要背模板，要结合你自己的项目代码来讲。老师最怕的就是学生拿了别人的代码，一问三不知。你把每个问题背后的代码逻辑自己走一遍，答案自然就记住了。

5.3 项目如何惊艳加分，又不会翻车

如果你的进度比预期快，有余力的话，可以考虑给系统加一两个“小而美”的功能点。比较推荐的是：

• 在管理端加一个数据概览页，展示今日订单数、本月营收、最热服务项目Top5，用ECharts画柱状图和折线图。这个功能实现不复杂，但演示效果极好，老师看到图表会觉得你的系统完成度很高。
• 在用户下单时加一个简单的地址管理，用户可以先维护常用地址，下单时直接选择。这个功能逻辑简单，但能体现你对真实业务场景的理解。
• 在个人信息模块加一个头像上传功能，用本地文件存储或Base64直接存库。注意文件大小限制，答辩时不要上传大图把浏览器卡死。

不过我要泼一盆冷水：不要为了加分去动核心架构。有人非要引入Redis和RabbitMQ，结果环境搭了一个星期还没跑通，最后连基本功能都忘了完善。毕设评分看的是完整度、逻辑性、表达力，你用一个简单的触发器或定时任务做数据统计，效果不一定比分布式方案差。

最后分享一点个人感受。这个项目做完以后，我最大的收获是把大学前几年那些零散的知识点真正串起来了：一个业务从前端点击，到axios封装的请求，到后端Controller接收，再到Service层处理事务、Mapper查询数据库，最后回到前端刷新页面，整条链路清清楚楚。这种“全局视角”比任何一门课的成绩都值钱，面试聊项目的时候心里也特别有底。答辩时老师不一定要求你的项目多庞大，但他们一定能看出来你有没有亲手做过、有没有认真思考过选型。按这篇的节奏一步步来，2026届的毕业设计你完全可以稳稳拿下。