企业官网建设流程全解析

每年这个时候，总有人捧着半成品代码来找我：“后端接口又连不上了”、“页面是有，但一打包成App就白屏”、“论文写到系统实现这章根本不知道截什么图”。2026年了，健康医生App这个题目依旧稳坐毕设选题热门榜——一套SSM后端，配一套Vue前端，再用HBuilderX套一层App壳，技术难度不高，但想把这套链路完整跑通、论文写得像样、答辩能自圆其说，中间的细节远比你想象的多。

这篇文章不打算复述SSM官方文档，而是从我实际带项目的过程出发，把技术选型、后端骨架、App端体验、业务模块、论文写作、部署踩坑这几块逐个拆开讲。看完你至少能明白两件事：这套项目应该按什么顺序做，以及每个环节最容易死在哪里。适合人群很明确：正在做SSM+Vue毕设的学生，以及想快速把管理系统套上移动端外壳的开发者。

1. 为什么2026年了还选SSM+Vue：毕设技术选型的实际考量

先聊一个很现实的问题：“SSM是不是过时了”？

从企业招人角度看，Spring Boot 和微服务生态确实是主流。但从毕设角度看，SSM 依然是很多高校软件工程、计算机科学专业的默认教学栈。你翻看自己专业的培养方案就会发现，大三的JavaWeb课程大概率还在讲Spring MVC和MyBatis，能上到Spring Boot选修课的反而是少数。毕设选题如果强制要求“基于SSM框架”，那就根本不存在选不选的问题，你只能在这个技术栈里把项目做到最好。

1.1 SSM这套组合到底在承担什么

SSM由三个框架拼接而成：Spring负责对象管理和事务控制，SpringMVC负责接收HTTP请求和路由分发，MyBatis负责数据库访问。三层各管一段，构成了典型的Controller-Service-Mapper结构。放到健康医生App里，它们的协作顺序是这样：

• 用户在App端发起请求（比如提交一条预约记录）；
• Nginx或Tomcat把请求交给SpringMVC的DispatcherServlet；
• DispatcherServlet根据@RequestMapping注解找到对应的Controller方法；
• Controller调用Service层处理业务逻辑（预约冲突校验、状态更新）；
• Service调用MyBatis的Mapper接口执行SQL；
• 结果以JSON格式返回给前端Vue渲染。

这套链路非常直白，特别适合那种“以增删改查为核心”的管理系统类毕设。健康医生App正好落在这一档：预约挂号、医生查询、健康档案录入、问诊记录保存，本质上都是在围绕几张数据库表做操作。你用SSM写出来的代码结构清晰、层次分明，论文里的架构图也容易画，答辩老师一看就能明白你的设计思路。

1.2 为什么偏偏是Vue来做App

严格来说，这个项目里的“App”并不是原生Android或iOS应用，而是用Vue写的移动端H5页面，再通过HBuilderX云打包成一套Android安装包。Vue在其中扮演的角色是前端框架：负责页面渲染、组件化开发、路由跳转和接口数据绑定。

选Vue而不是选原生开发，原因同样务实。学校的移动开发课程往往只讲基础，真正上手Android的Activity、Fragment生命周期管理，学习成本远高于Vue的模板语法。Vue全家桶（Vue Router + Vuex/Pinia + Axios）的学习曲线够平缓，加上Vant这种现成的移动端组件库，一个礼拜就能做出像样界面。更关键的是，Vue写出来的东西可以直接在浏览器调试，不依赖Android Studio和模拟器，对毕设节奏非常友好。

再退一步说，即使导师明确要求“必须交付一个App”，HBuilderX云打包也能完成从H5到APK的转换，论文里照样可以写“基于Vue技术栈的移动端应用”。

1.3 健康领域业务量与这套技术栈的匹配度

我见过有的组选“健康医生App”题目，结果把范围铺得特别大：在线视频问诊、AI辅助诊断、心率监测、医保支付，恨不得把一个互联网医院全塞进去。最后代码写不完，论文全靠编，答辩必翻车。

真实情况是，健康医生App的常规业务量很小。一种典型的规模大概是：6-8张核心表，3个角色（用户、医生、管理员），20到30个接口，前端12到15个页面。这个体量用SSM扛绰绰有余，甚至有点“大材小用”。反过来说，如果你的题目想象空间太大，技术栈还选SSM这种传统架构，那就属于“需求玩得飞起、实现兜不住底”。毕设的核心逻辑永远是用有限的技术，把有限的需求做完整，而不是用旧技术硬撑一个大而无当的方案。

下面这张表是我给毕设组做选型评估时常用的一张对照表，供你参考：

一句话总结：技术选型的目标不是“最新最潮”，而是“在你现有能力范围内，把业务闭环讲清楚”。SSM+Vue恰恰是这个目标的最优解之一。

2. 从pom.xml到六张核心表：SSM后端的落地细节

很多学生做SSM项目失败，不是死在业务逻辑上，而是死在“项目根本启动不起来”。骨架没搭对，后面全白费。所以这一节我不讲虚的，直接按照我会实际操作的顺序，把后端从配置到数据库的完整链路给你顺一遍。

2.1 Maven项目依赖：这些包一个都不能少

项目结构上，后端建议用Maven管理，直接选择war打包方式，因为最终要丢到Tomcat里跑。你新建完Maven项目后，第一步是去pom.xml把依赖补全。我是这样写的：

<dependencies> <!-- Spring核心 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.3.20</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.3.20</version> </dependency> <!-- MyBatis与Spring整合 --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.10</version> </dependency> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis-spring</artifactId> <version>2.0.7</version> </dependency> <!-- MySQL驱动与连接池 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.29</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>1.2.16</version> </dependency> <!-- JSON转换 --> <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.13.3</version> </dependency> <dependency> <groupId>com.fasterxml.jackson.datatype</groupId> <artifactId>jackson-datatype-jsr310</artifactId> <version>2.13.3</version> </dependency> <!-- Servlet --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies>

版本号我特意标成了我这边测过的一批，其他地方抄来的版本组合容易触发冲突。一个比较常见的坑是：Spring 5 + 低版本MyBatis-spring会出现ClassNotFoundException，这种问题一般就是版本没对齐。

2.2 三个配置文件：各自管好各自的边界

SSM的配置是很多人的噩梦，因为一个项目里至少有applicationContext.xml、spring-mvc.xml和mybatis-config.xml三份配置文件，它们的分工是：

• applicationContext.xml：Spring容器启动入口，负责配置数据源、事务管理器、扫描Service和Mapper；
• spring-mvc.xml：DispatcherServlet的上下文，负责扫描Controller、开启注解驱动、配置静态资源放行；
• mybatis-config.xml：MyBatis的全局配置，主要是驼峰命名映射和SQL日志。

我知道现在Spring Boot一个application.yml就能搞定全部配置，但不可否认，理解这三份配置的分工，恰恰是答辩时展示“基础扎实”的杀手锏。你至少得能指着配置文件说清楚：“数据源交给Spring管，Mapper扫描交给MyBatis管，Controller路由交给MVC管”。

2.3 核心注解：高频使用场景逐个拆

SSM风格的开发里，注解就是代码与框架之间的“暗号”。下面这组是我在健康医生App里最高频用到的，把它们的角色彻底搞明白，服务层和控制层写起来会顺很多：

需要特别注意的是，SSM项目里如果要在接口上返回JSON，@ResponseBody是标配。而如果你用@RestController，那就等于@Controller+@ResponseBody的组合，接口类上可以直接用，省得每个方法都加一遍。毕设项目里接口很多，我推荐统一使用@RestController，代码能干净不少。

2.4 六张核心表：先定好表再去写代码

我不止一次强调，做管理系统类毕设，一定要先设计数据库再写业务代码。表结构直接决定了接口怎么定义、前端页面怎么画，表一旦返工，整个项目都要跟着返工。健康医生App我从多个做过的项目里提炼了一套比较通用的表设计，覆盖用户、医生、预约、问诊、健康档案五个维度：

密码字段我建议至少存MD5（哪怕加一点盐），不要在数据库里明文保存。答辩时老师看到明文密码，很容易追问出一串安全性问题，这一块别给自己挖坑。

2.5 一个完整接口的代码示范

设想一个场景：用户点击“我要预约”，前端把userId、doctorId、appointmentDate、timeSlot通过POST方式提交到后端。Controller层写起来是这样的：

@RestController @RequestMapping("/api/appointment") public class AppointmentController { @Autowired private AppointmentService appointmentService; @PostMapping("/add") public Result add(@RequestBody Appointment appointment) { // 业务校验：日期不能是过去、医生状态必须正常 if (appointment.getAppointmentDate().isBefore(LocalDate.now())) { return Result.error("预约日期不能早于今天"); } // 核心业务：防止同一时段重复预约 if (appointmentService.isDuplicated(appointment)) { return Result.error("该时段已被预约，请选择其他时间"); } appointment.setStatus(0); // 0=待确认 appointmentService.add(appointment); return Result.success("预约成功"); } }

注意这里返回的Result，是我建议你封装的一个统一响应类，大概结构是{ code: 200, message: "success", data: 对象 }。前后端都用这一套格式，联调时脑子清醒得多，答辩也能解释清楚“统一异常响应”这个设计思想。

3. 用Vue把App体验做出来：路由、组件、axios与跨域联调

后端接口通了，接下来就是Vue前端。很多学生把Vue项目建完就开始写页面，写到一半发现接口全跨域、组件库版本不对、路由跳转乱掉。我建议先把下面这几件事做扎实，再动手画页面。

3.1 创建项目和选组件库：版本匹配是隐形大坑

创建Vue项目我一般用Vite，命令是npm create vite@latest health-app -- --template vue。目录建好之后，第一件事就是安装路由和组件库：

npm install vue-router@4 axios vant@4

新手最常见的坑就在这里：如果你脚手架用的是Vue 2，那只能配vue-router@3和vant@2；如果你用Vue 3，就配vue-router@4和vant@4。版本不对的情况下，最常见的症状就是页面组件不渲染、路由报错Cannot read properties of undefined，而且编译时还不一定报错，排查极其痛苦。所以安装前一定先确认自己的Vue大版本。

3.2 移动端布局和底部导航：先让页面有“App感”

所谓“App感”，核心就两点：窄屏布局和底部Tab栏。移动端页面我一般以375px为设计基准，内容区宽度自适应，外面套一层安全边距，按钮用Vant的van-button，输入框用van-field，列表用van-cell。底部导航用Vant的Tabbar组件：

<van-tabbar v-model="active" route> <van-tabbar-item to="/" icon="wap-home-o">首页</van-tabbar-item> <van-tabbar-item to="/doctor" icon="doctor-o">医生</van-tabbar-item> <van-tabbar-item to="/appointment" icon="calendar-o">预约</van-tabbar-item> <van-tabbar-item to="/mine" icon="user-o">我的</van-tabbar-item> </van-tabbar>

注意route属性，加了它之后点击Tab项会直接触发路由跳转，比手动写@click跳转省事很多。路由表里面这四个页面作为一级页面，其余如医生详情、问诊记录、健康档案新增页面作为二级页面压入堆栈。

3.3 axios封装：统一处理token和错误码

接口联调阶段最忌讳在每个页面里单独写一遍axios.get，一旦后端改了统一返回格式，你要改的地方多得想哭。我把axios统一封装一个文件，核心逻辑如下：

import axios from 'axios'; import { showToast } from 'vant'; const request = axios.create({ baseURL: '/api', timeout: 8000, }); request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; }); request.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { showToast(res.message); return Promise.reject(new Error(res.message)); } return res; }, error => { showToast('网络异常，请稍后重试'); return Promise.reject(error); } ); export default request;

这里统一做了三件事：请求带token、响应拦截统一校验code、错误统一弹Toast。你后端返回什么结构，这个拦截器就按什么结构写，多花十分钟，后面联调能省一整晚。

3.4 跨域问题：三步解决前后端联调

Vue跑在5173端口，SSM后端跑在8080端口，浏览器肯定报跨域。跨域不是“某一个配置能解决所有场景”的玄学，我建议按下面顺序处理：

• 第一步，后端开启CORS过滤器。加一个CorsFilter或者实现WebMvcConfigurer的addCorsMappings方法，允许3000-5173等常见前端端口访问；
• 第二步，前端配置代理。Vite项目在vite.config.js里加server.proxy，把/api开头的请求代理到后端地址；
• 第三步，统一接口路径。后端Controller统一以/api开头，这样代理规则只需要匹配一个前缀，很干净。

绝大多数“接口通了但数据拿不到”“请求状态码200却报错”的问题，都出在跨域配置或接口路径不一致这两件事上。联调测试时建议打开浏览器开发者工具，认认真真看Network面板里的请求和响应，不要凭感觉猜。

4. 从在线预约到健康档案：四个核心业务模块的实现说明

健康医生App表面上有十几个页面，但核心业务其实就是一条主线：用户认证身份，找到医生，完成预约，留下健康记录，后续查看历史。把这条主线串起来，再去补管理后台的功能，项目就完整了。

4.1 用户注册与登录：SSM时代最稳妥的会话方案

我见过不少项目在登录这块过度设计，一上来就搞JWT、Refresh Token、Redis缓存，结果把自己绕晕了。SSM阶段的毕设，最简单稳定的方案是：拦截器 + Session + localStorage搬运token。

具体做法是：登录成功时后端把用户信息放进session，同时返回一个用户对象给前端；前端把用户ID存进localStorage，用于在请求头或者路由跳转时带上用户标识。后端写一个LoginInterceptor，拦截除登录注册之外的接口，判断session里是否有用户，没有就返回401状态码。

这个方案虽然朴素，但好在完全可控。答辩时老师问“你怎么保证接口安全”，你能说清楚拦截器校验Session，这就是一个明确的、经得起推敲的回答。

4.2 医生列表与科室筛选：前端数据绑定的典型场景

医生页面的核心交互是：顶部科室横向滚动，下面医生列表跟着筛。接口层面，后端提供一个按科室查医生的接口：

GET /api/doctor/list?departmentId=2

前端拿到数据之后，用v-for渲染van-cell列表。这个模块本身不难，难点在于医生头像和简介这些字段要有模拟数据，不然页面会很空。毕设阶段不需要真实图片，用占位图或者网络图片即可，论文截图里列表有内容才好看。

4.3 预约模块：状态机和冲突校验是答辩亮点

预约模块是整个项目的业务核心。我参考真实医院挂号系统的习惯，把预约状态定义成四个：0待确认，1已确认，2已取消，3已完成。用户可以取消“待确认”状态的预约，医生端可以把“待确认”改为“已确认”，问诊结束后自动把状态改为“已完成”。

后端在新增预约时要做两件事：第一，判断该医生该日该时段是否已被预约，避免冲突；第二，判断用户是否重复提交了同一时段的预约。这两条规则我在2.5节已经示范过代码，放到Service层里实现即可。这块做扎实了，论文里的“系统核心业务流程设计”章节就不愁没内容写。

4.4 健康档案与问诊记录：数据录入和数据回看

健康档案模块要解决的是“数据从哪来、往哪去”的问题。用户可以在App的“我的-健康档案”里录入身高、体重、血压、血糖这些指标，每次录入生成一条t_health_record记录，列表反着时间排，最新记录在前。如果想让页面显得有层次，还可以引入ECharts画一个体重变化的折线图，这个属于额外加分项，工作量不大，但论文截图会好看很多。

问诊记录则和t_medical_record表挂钩。用户提交症状描述，医生写下初步诊断和用药建议，形成一条记录。这里不需要做实时聊天，用类似留言板的方式保存即可，复杂度可控，业务闭环也完整。

5. 论文不用愁：六章结构、用例图与答辩高频问题

程序和论文的关系我一句话说明白：程序是论文的论据，论文是对程序的解释。不要试图把两个事情分开做，写完代码再补论文，或者先写完论文再写代码，都会非常痛苦。最省力的方式是边写代码边留截图、边记关键设计决策，最后一个月集中整理成文。

5.1 论文六章结构，每一章到底写什么

管理类系统毕设的论文框架高度成熟，我按顺序给每一章划一下重点：

5.2 需求分析的关键产出：用例图

需求分析这一章，很多学生最大的误区是只写字不画图。其实老师最想看到的是用例图，一张图就能反映出你是不是真的想清楚了系统里有哪几个角色、每个角色能干什么。健康医生App的用例图建议画三个层次：用户能操作注册登录、浏览医生、预约、填写档案、查看问诊记录；医生能管理排班、处理预约、回复问诊；管理员能维护医生信息、管理用户、查看统计数据。

画图工具不用太高级，ProcessOn或者Visio都行，重点是让图里的用例覆盖系统所有功能。这张图放出来，需求分析章节能直接立住。

5.3 系统实现章的截图策略

论文查重和盲审阶段，实现这一章的质量很大程度决定了整体印象分。我建议你造数据阶段就把下面这组截图备齐：

• 用户端首页和医生列表页截图；
• 预约流程关键页面（选择时段 → 确认预约 → 成功提示）截图；
• 健康档案录入与列表页截图；
• 后台管理端的用户管理、医生管理截图；
• 数据库表结构截图和每个核心接口的测试截图（用Postman调接口的返回结果）。

截图配上一小段“功能描述 + 关键代码说明”，文字篇幅很快就撑起来了，而且每一页都言之有物。

5.4 答辩高频问题与标准应答思路

答辩不是技术评审，是“证明这是你自己做的”。以下几道题几乎必问，提前把答案组织好：

• “为什么选SSM而不选Spring Boot？”——回答重点：课程体系基于SSM、能够更清晰地理解Spring生态的底层协作机制、业务规模不需要微服务等。
• “系统怎么保证预约不冲突？”——回答重点：数据库约束 + Service层校验双重保证，具体描述查询逻辑。
• “密码是怎么存储的？”——说清楚MD5加盐或至少非明文存储。
• “系统有哪些不足和可改进之处？”——列出三个方向即可：引入缓存、改用JWT无状态认证、前端改成Uni-app实现多端发布。注意不要说“没有不足”。

6. 踩坑清单：跨域、日期格式、Tomcat部署与毕设节奏控制

这一节是我最想让你认真看的部分。很多学生不是不努力，而是把时间全部耗在莫名其妙的环境问题上。下面这六个坑，我在不同项目里反复见过，每一个都配好了解决方案。

6.1 接口404但代码明明没问题：包扫描路径不一致

症状是：Controller类写了注解、Tomcat也启动了，但访问接口一直404。根因九成是Spring的扫描器没扫到Controller所在的包。比如你的spring-mvc.xml里配置的是base-package="com.example.controller"，但实际类放在com.example.health.controller里，就会失效。

排查方法很粗暴：把spring-mvc.xml的扫描路径改成项目最外层父包，比如com.example，让Spring把整个包树都扫一遍。同理，applicationContext.xml里的Service和Mapper扫描也要覆盖对应包路径。

6.2 日期格式序列化炸了：LocalDateTime前后端对不上

如果你用了Java 8的LocalDate和LocalDateTime，没有额外配置Jackson的JSR310模块，接口返回就会变成一串数字数组，而不是"2026-05-20"这样的字符串。前端拿到这种数据没法解析，日历组件直接显示诡异。

解决办法分两步：pom.xml加jackson-datatype-jsr310依赖；SpringMVC配置里注册Jackson2ObjectMapperFactoryBean，设置日期格式为yyyy-MM-dd HH:mm:ss。前端提交日期时，也尽量用YYYY-MM-DD的字符串格式，避免时区偏移的问题。

6.3 中文乱码：不是加一个过滤器就完事

SSM项目中文乱码有三个层面的来源：请求参数乱码、响应输出乱码、数据库存储乱码。只配置Tomcat的URIEncoding是不够的。我最推荐的做法是，在web.xml里配置Spring的CharacterEncodingFilter，同时保证数据库连接URL带characterEncoding=utf8，表结构默认字符集也用utf8mb4。这三处对齐，乱码基本绝迹。

6.4 MySQL 8连接报错：时区问题导致连不上

如果你用的是MySQL 8.x，而连接串还是网上抄的jdbc:mysql://localhost:3306/health，大概率启动时直接报The server time zone value is unrecognized。解决办法是连接串加上serverTimezone=Asia/Shanghai&useSSL=false，顺便把驱动类改成com.mysql.cj.jdbc.Driver。这类问题属于“报错信息一看就懂，但不知道去哪里改”，提前预防能省很多时间。

6.5 前端打包后放到Tomcat：路径和history路由问题

前端开发环境很顺畅，但npm run build之后扔进Tomcat就白屏或者刷新404。这里有两个坑：第一，Vite构建配置里base要设为相对路径./，否则静态资源路径以绝对路径开头，部署到非根目录时找不到；第二，Vue Router要用createWebHashHistory而不是createWebHistory，否则刷新子路由页面时，服务器找不到对应路径返回404。这两个问题处理好，前后端共存一个Tomcat部署就非常顺利。

6.6 毕设时间节奏：最后一个月怎么安排不翻车

根据我多年观察，毕设翻车的学生大多不是技术差，而是时间安排塌了。给一个亲测有效的节奏建议：

我看了太多“前三个月拖延，最后两周爆肝”的案例，结果论文一个字没动，代码还是半成品。毕设这种事，过程是给自己说的，结果是给老师看的。哪怕你前面做得慢，按这个节奏把每周的验收标准盯死，答辩前绝对能从容收尾。

最后再分享一点我个人带项目的体会：做SSM+Vue健康医生App这类毕设，真正的核心竞争力不在于用了多厉害的技术，而在于你是否能把“用户登录 → 选医生 → 约时间 → 记录健康 → 回看历史”这条业务链完整跑通，并且论文里每一页都是在解释自己的真实代码。把这套链路吃透，你不仅答辩能稳过，这段做项目时踩坑、查资料、调接口的经历，也是你后面找工作面试时真能拿出来讲的实战素材。按这个思路一步步把工程搭起来，剩下的只是时间问题。