企业官网建设流程全解析

2026年了，打开毕设选题库，居然还有大量题目在坚持SSM+Vue的组合，甚至成了很多学校的标配。我这两年帮人改了不少毕业设计，见得最多的翻车现场不是功能写不出来，而是：SSM的XML配置和注解混着写、WebSocket在SpringMVC里注册不进去、Vue打包完丢到SSM之后刷新就404、答辩的时候被老师问一句"你的实时消息走的是什么协议"就愣住。这篇东西就是冲着这些坑来的。我打算以一套完整的聊天管理系统为主线，把后端SSM、前端Vue的关键实现路径、数据库怎么建模、论文怎么编排、程序怎么打包交付全部过一遍。目标人群就是2026届正在为毕设发愁的本科生，以及那些想找一个能直接参考的稳妥模板的人。

这套系统看起来简单，但实际做起来涉及的分支不少：好友关系怎么维护、单聊消息怎么保证不丢、群聊的成员状态怎么同步、前端WebSocket怎么封装、Vue路由和后端拦截器的鉴权怎么配合。下面按我做项目的顺序，从选型到交付一步步拆开讲。

1. 2026年SSM+Vue仍然值得做的三个理由

1.1 毕业设计的评分规则：技术合规性比技术时髦性更重要

你可能会觉得2026年还做SSM有点"旧"。但现实是，大部分高校的毕设题目库还是老一套，导师的验收标准、查重规则、代码考核逻辑都没变。选题阶段，你报上去的题目如果在库里没有对应项，审批就得很费劲。所以"技术合规"是第一优先级。

另外，SSM这套组合在答辩时有它的天然优势。Spring Boot是自动配置，很多学生用了大半年也讲不清楚内嵌Tomcat、自动装配、条件注解这些东西。SSM不一样，它逼着你手动配置DispatcherServlet、配置SqlSessionFactory、配置事务管理器。你只要真做过一遍，老师问SpringMVC的执行流程、MyBatis的代理原理、Spring声明式事务的生效机制，你都能从自己写的配置文件里找到线索回答上来。

1.2 SSM的核心构成与Spring Boot的对应关系

很多人搞不清SSM和Spring Boot的区别，这里用一句话说透：SSM是三个框架的手动组合，Spring Boot是对Spring生态的自动化封装。对应关系如下：

• Spring对应IoC容器和AOP，Spring Boot里照样是Spring，只是自动帮你创建Bean。
• SpringMVC对应Web层的DispatcherServlet和Controller，Spring Boot里通过spring-boot-starter-web把DispatcherServlet自动注册好。
• MyBatis对应数据访问层的SqlSessionFactory和Mapper代理，Spring Boot里通过mybatis-spring-boot-starter简化配置。

做SSM版本的聊天系统，本质上就是手动完成这三层的组装。你会在web.xml或WebAppInitializer里注册Spring的ContextLoaderListener，在spring-mvc.xml里开启注解驱动和组件扫描，在spring-mybatis.xml里配置数据源和SqlSessionFactory。这套手动过程虽然繁琐，但它能帮你把整个框架的运行机制串一遍，对后续讲"系统架构设计"那部分论文特别有用。

1.3 聊天管理系统的边界：哪些功能必须做，哪些可以砍

毕设最忌功能铺太大。聊天管理系统往小了做，只需要覆盖三块：好友管理、单聊、群聊。在此基础上加消息记录和登录注册，就是一套完整的闭环。

具体来说，必须做的功能有几个：

• 用户注册登录、头像昵称维护。
• 添加好友、好友申请、同意/拒绝、好友列表展示在线状态。
• 单聊消息的发送与接收、消息落库、未读消息统计。
• 群组的创建、加入、群聊消息广播。
• 历史消息的查询与展示，能用时间分页。

可以砍掉或者写进"后期展望"的功能有：语音视频通话、消息撤回、表情包斗图、文件传输、全员禁言。这些功能不是不能做，而是对毕设来说性价比太低。一个撤回功能要改消息状态字段、加权限校验、做前端消息状态刷新，工程量顶得上半个单聊模块。答辩时老师说"你这个撤回还挺好"，但你很难在有限篇幅里把主流程讲透。与其铺开，不如把核心链路打磨扎实。

2. 数据库设计与后端骨架：先把消息和好友关系想清楚

2.1 数据表设计：用户、好友、单聊、群聊一个都不能少

聊天系统的数据库设计是整个后端的地基，表关系想不清楚，后面写Mapper都是灾难。我建议你这六张表起步：

密码字段千万别存明文。用MD5加盐或者BCrypt都行，我建议Spring的PasswordEncoder或者简单的MD5(username + salt + password)。答辩老师看到"密码=MD5摘要"比看到明文password字段印象好很多。

好友关系表设计时要注意，它是双向冗余存储的。A添加B时插入两条记录，一条(A→B)，一条(B→A)。这样查询好友列表就非常直接：select * from t_friend where user_id = 当前用户 and state = 1，然后join用户表拿昵称和头像。

2.2 SSM常用注解扫盲：@Controller、@Service、@Autowired、@RequestMapping

SSM项目的代码结构一般是Controller层、Service层、Mapper层三层。Vue前端发请求过来，访问路径对应Controller，Controller调Service，Service调Mapper，Mapper通过XML或注解发SQL。这个链路必须烂熟于心，答辩高频问题就是"一次请求从进入到返回经历了什么"。

平时写代码最常用的注解也就这几个：

• @Controller / @RestController：标记请求处理类，后者直接返回JSON，省掉@ResponseBody。
• @RequestMapping / @GetMapping / @PostMapping：绑定请求路径和HTTP方法。
• @RequestParam / @RequestBody：接收前端传参，一个收URL参数，一个收JSON体。
• @Service：标记业务层实现类，交给Spring容器管理。
• @Autowired：依赖注入，把Service注入Controller、把Mapper注入Service。
• @Transactional：声明式事务，写消息落库、修改好友状态这些涉及多条SQL操作时一定要加。某条SQL失败自动回滚，避免出现脏数据。

写这段的时候，我建议你在论文里加一张"注解功能对照表"，把用到的注解、作用、放置位置列出来。老师看到这张表就知道你是真用过，而不是把别人的代码复制下来改了改名字。

2.3 登录鉴权：JWT + 拦截器怎么就比Session在Vue项目里好用

前后端分离的Vue项目，最痛的一点就是跨域和Session维护。用Session方案需要开启axios的withCredentials，还要处理Cookie跨域，在开发环境里特别容易出这种尴尬问题：前端明明登录成功了，刷新页面后仍提示未登录，因为Cookie同源策略把会话丢了。

JWT方案的逻辑是：登录接口校验用户名密码，成功后生成一个带用户ID和过期时间的令牌返回给前端。前端把令牌存在localStorage，每次axios请求在拦截器里往Authorization头里塞。后端加一个拦截器，所有接口先解析令牌，解析成功才放行。

核心代码大概长这样：

public class JwtInterceptor implements HandlerInterceptor { public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { response.setStatus(401); return false; } UserContext.set(JwtUtil.parseToken(token)); return true; } }

然后在spring-mvc.xml里注册这个拦截器，拦截路径配置成下面的方式，把登录接口和静态资源放行。SSM里配置拦截器拦截路径时要注意顺序，一个常见坑是拦截了静态资源导致前端页面白屏。

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/api/**"/> <mvc:exclude-mapping path="/api/user/login"/> <mvc:exclude-mapping path="/api/user/register"/> <bean class="com.xxx.chat.interceptor.JwtInterceptor"/> </mvc:interceptor> </mvc:interceptors>

3. 实时聊天的核心链路：SSM整合WebSocket的完整方案

3.1 为什么轮询在聊天场景里必死

聊天系统最核心的实时性，用传统HTTP轮询做不到。轮询就是前端每隔几秒发一次HTTP请求，问服务器"有没有新消息"。这样做的坏处很明显：消息到达最多延迟一个轮询周期，要快就得缩短间隔，间隔短了服务器压力巨大。一个在线用户每3秒一个请求，100个在线用户就是每秒33个请求，大部分还在空转。

更麻烦的是，HTTP请求是短连接，服务端没法主动推送。WebSocket则是全双工长连接，建立一次HTTP握手后，客户端和服务端都随时可以互发消息。这正好匹配聊天场景：服务端能第一时间把对方的消息推到你浏览器上，你发消息时也走同一条通道。

3.2 SpringMVC的WebSocket接入：握手、会话、消息处理器

SSM整合WebSocket，需要在pom.xml引入spring-websocket依赖，然后做三件事。

第一，写一个配置类实现WebSocketConfigurer接口，注册你的WebSocket处理器和握手拦截器：

@Configuration @EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { @Autowired private ChatWebSocketHandler chatHandler; @Autowired private WebSocketHandshakeInterceptor handshakeInterceptor; @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(chatHandler, "/chatServer") .addInterceptors(handshakeInterceptor) .setAllowedOrigins("*"); } }

第二，写握手拦截器。这个拦截器的作用是在连接建立前把用户身份绑定到WebSocketSession上。因为Vue端用JWT鉴权，握手的时候可以在URL上带token参数，拦截器解析token取出用户ID，然后塞进session attributes里。这一步非常关键，稍后消息处理器要拿这个来判断"这个连接属于谁"。

public class WebSocketHandshakeInterceptor implements HandshakeInterceptor { @Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) { String token = request.getURI().getQuery(); // token=xxx Integer userId = JwtUtil.parseUserIdFromQuery(token); attributes.put("userId", userId); return true; } }

第三，写消息处理器，继承TextWebSocketHandler。核心是重写三个方法：afterConnectionEstablished连接建立、handleTextMessage收到消息、afterConnectionClosed连接关闭。

public class ChatWebSocketHandler extends TextWebSocketHandler { private static final ConcurrentHashMap<Integer, WebSocketSession> ONLINE_SESSIONS = new ConcurrentHashMap<>(); @Override public void afterConnectionEstablished(WebSocketSession session) { Integer userId = (Integer) session.getAttributes().get("userId"); ONLINE_SESSIONS.put(userId, session); // 用户上线，注册会话 } @Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { // 解析JSON消息，判断toUserId，然后推给对方 } @Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) { // 用户下线，清理会话 } }

3.3 在线状态维护与离线消息补推

消息推送给谁的依据是上面那个ONLINE_SESSIONS映射表。handleTextMessage收到一条消息后，先解析消息体里的receiverId，然后从这个Map里取对端的WebSocketSession，取得到就推，取不到就把消息标记成离线。

这里有个关键设计：无论对端在不在线，消息都必须先落库。也就是先写t_message表，把is_read字段设为0，然后尝试推送给在线用户。推送成功后可以选择把is_read改成1，但更简单的做法是等对端发送"收到确认"再改已读；毕设不需要做到确认机制这么细，只需要保证前端再拉取时能看到离线消息就行。

用户上线后，前端WebSocket建立成功的回调里发一条"pullOffline"消息，服务端收到后从数据库查未读消息批量推给该用户。这一步做完，"离线消息补推"功能就完整了，论文里还可以画一张时序图，说明消息发送→落库→推送→离线拉取这四个环节。

3.4 心跳检测和异常断线的处理

WebSocket看起来是长连接，实际上经过NAT设备或代理服务器时，长时间没有数据交互会被静默断开。表现就是页面显示在线，但消息已经收不到了。解决方案是心跳机制。

前端每30秒发一条ping消息，服务端收到ping后回一条pong。如果服务端发现某个连接连续三次没收到心跳，就主动关闭这个会话并清理在线状态。相应地，前端WebSocket的onclose回调里要做断开重连逻辑，重连不能太频繁，用退避策略，比如第一次等1秒、第二次等2秒、第三次4秒，最多30秒。

这个模块看着不起眼，但答辩时如果老师问"系统在弱网下怎么保证可用性"，心跳检测就是你最好的答案。

4. Vue 3端到端开发：从脚手架到聊天气泡的完整串联

4.1 环境准备与项目初始化：Vite、Node版本、依赖安装坑

前端我用的是Vite + Vue 3 + Vue Router + Pinia + Element Plus这套组合。Node版本至少18以上，版本太低直接跑不起来。

npm create vite@latest chat-web -- --template vue cd chat-web npm install npm run dev

new一个项目出来，真正让人头大的是依赖安装过程。npm默认源在境外，即便网络不错也很容易卡。建议项目根目录建一个.npmrc文件：

registry=https://registry.npmmirror.com

装Element Plus、axios、pinia、sass这几个常用依赖：

npm install element-plus axios pinia sass

如果你用路由的时候发现页面刷新后404，那是history模式在开发服务器的historyApiFallback问题，Vite开发模式一般不出现；部署之后出问题，要在路由里改hash模式，这个放到部署章节细说。

4.2 路由与登录守卫：没有这一步，后端拦截器就是摆设

前端路由设计其实很常规，我通常只设置这三个一级路由：/login、/register、/，主界面下面再挂好友列表、聊天窗口、群聊页这些子路由。

真正要紧的是路由守卫。Sidebar需要登录后才能看，没登录的用户访问任何页面都重定向到登录页：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('chat_token') if (!token && to.path !== '/login' && to.path !== '/register') { next('/login') } else { next() } })

配合这个守卫，axios封装再统一加请求拦截器。每次请求自动带上token，响应拦截器检测到401就清空本地token并跳登录页。这套组合的意义在于：前端路由守卫管"看不见"，后端JWT拦截器管"不能用"，两层都到位系统才安全。

4.3 WebSocket的前端封装：连接管理、断线重连与消息分发

前端WebSocket不能直接裸写在某个组件里，不然切到别的页面连接就断了。建议封装成composable函数，配合Pinia存全局连接状态。

基本连接代码：

function connectWebSocket() { const token = localStorage.getItem('chat_token') const ws = new WebSocket(`ws://localhost:8080/chatServer?token=${token}`) ws.onopen = () => { isConnected.value = true } ws.onmessage = (event) => { const data = JSON.parse(event.data) handleServerMessage(data) // 按type分发到友列表、聊天框、通知 } ws.onclose = () => { isConnected.value = false setTimeout(connectWebSocket, 2000) // 断线重连 } }

消息分发逻辑建议用type字段区分：friend_request表示收到好友申请，single_chat表示收到单聊消息，group_chat表示收到群聊消息，status_change表示好友上线/下线。前端收到single_chat后，先判断当前聊天窗口是否是发送方，是就直接插入消息列表，不是就更新未读计数。

4.4 聊天界面组件拆分：好友列表、消息流、输入框

界面我建议按左右布局拆三个核心组件：左侧FriendList显示好友和群组，中间ChatWindow显示当前会话的消息流，底部MessageInput负责输入和发送。

这里要点是组件之间的通信不要层层传props传得头大，用Pinia存store统一管理。store里维护三个核心状态：

const state = { friends: [], groups: [], currentChat: null, // { type: 'friend' | 'group', id, name } messages: [], // 当前会话的消息列表 }

发送消息时，组件把消息内容提交给store，store调WebSocket发送JSON，同时本地立即把这条消息追加到messages里。服务端推送回来的消息也走同一套store更新逻辑，界面自动响应。

组件拆分开后还有个好处的写法上很清晰：friendList只负责展示在线状态和点击事件，chatWindow只负责渲染消息列表和滚动到底部，messageInput只负责输入和发送。答辩时老师问"你怎么管理前端状态"，你答"用Pinia统一派发，组件不直接通信"就够了。

5. 毕业论文怎么编排：从目录到答辩页的结构拆解

5.1 论文的章节框架：七章结构的字数分配

聊天管理系统这类题目，论文框架基本是固定的，靠这七章可以稳妥拿分：

大部分学校本科毕设正文要求15000字左右，按这个表分配，整体节奏不会乱。细节章节不要超过一章的去写某一个功能，比如WebSocket单独写三节，这样整篇论文的重心就偏了。

图比文字重要。架构图用简单的矩形框图表示浏览器→Vue前端→SpringMVC Controller→Service→Mapper→MySQL这条链路。用例图要有三种角色：游客（注册登录）、普通用户（好友管理、单聊群聊）、系统管理员（后台管理，可选项）。这些图不需要多高级，PowerPoint或者draw.io画得清爽就行，但一定要与代码实现一致，答辩时被抽查到"你的图与实际功能对不上"很减分。

5.2 系统实现章节的写法：为什么"贴代码"是死路一条

论文第4章写"详细设计与实现"是翻车重灾区。直接把Controller、Service、Mapper代码一坨一坨贴进去，老师看到前两页就失去兴趣了。正确的写法是，每个功能模块按这个结构组织：功能描述、业务流程、关键代码、运行效果。文字为主，代码为辅，代码只贴最能体现实现思想的片段，长度控制在20行以内。

比如写"单聊消息发送"这一个小节：

1. 业务描述：用户A在Vue前端输入消息，点击发送，消息通过WebSocket发送到服务器，服务器解析JSON后存入数据库，并推送消息给用户B。
2. 时序描述：用一段文字按时间顺序把消息从浏览器A到浏览器B的整个路径写清楚。
3. 关键代码：贴ChatWebSocketHandler的handleTextMessage方法，删掉异常处理和业务分支，只留核心逻辑。
4. 运行效果：放一张两个浏览器窗口互发消息的截图，这是论文中最重要的实证材料。
5. 关键点说明：解释为什么消息需要先落库再推送、离线状态下消息怎么处理。

还有一种更高级的写法是画一张时序图，把用户A、Vue前端、WebSocket服务端、MySQL、用户B这几个参与者的消息交互按时间轴画出来，配合文字描述，答辩老师一眼就看懂你的设计。这一步做好了，比正文写三千字还有说服力。

5.3 答辩的演示顺序与必背问题

答辩现场的演示顺序建议固定，不要即兴发挥。我整理过一套顺利走完的流程：

• 30秒简介：项目由SSM后端和Vue前端组成，登录后进入聊天主界面。
• 1分钟登录注册演示：注册一个账号，看一眼数据库里User表多了一条记录。
• 2分钟好友Demo：A账号添加B账号为好友，B通过申请，A的好友列表刷新出现B，状态显示在线。
• 3分钟单聊演示：两个账号互发消息，聊天框实时接收回显显示，刷新页面后历史消息还在。
• 1分钟离线消息演示：B退出登录，A发一条消息给B，B重新登录，刷新后看到未读消息。
• 2分钟群聊演示：A建群，邀请B进群，两人发群消息，群成员列表更新。
• 1分钟数据库验证：打开MySQL客户端，展示t_message表的多条记录，说明消息确实落库了。

必背的几个高频问题，提前准备好答案：

• 为什么用WebSocket，和HTTP的差别是什么？答：HTTP请求响应式短链接，服务端不能主动推。WebSocket一条长连接双向通信。
• 消息如果发过去对方不在线怎么办？答：消息先写数据库并标记未读，对方上线时拉取未读消息。
• 你如何判断一个用户是否在线？答：WebSocket连接建立时维护一个Map，连接关闭或心跳超时移出Map，在线状态实时更新。
• 群聊消息是所有人都推吗？答：群聊消息推给当前在线群成员，不在线的群成员靠重新进群时拉取最近记录。

6. 部署打包与交付避坑：从本地跑通到交到老师手上

6.1 前端打包放进SSM工程：路径与404问题根治

这是每年毕设最高频的翻车点，因为Vite默认构建出的资源路径是绝对路径/，直接丢到SSM的webapp下，打开页面白屏或者CSS加载不出来。解决办法就是构建时改base为相对路径。

在vite.config.js里加一行：

export default { base: './', // ... }

改完再build，你会发现index.html里的script和link都变成了./assets/xxx的写法，这样无论是放在SSM的webapp还是Spring Boot的static目录，都不会有路径问题。

Vue Router在部署环境里强烈建议用hash模式。history模式在浏览器端看起来干净，但Tomcat服务器上目录结构复杂，前端路由刷新时Tomcat会去磁盘找对应的物理文件，找不到就404。改成hash模式之后URL带#号，所有路由切换都在浏览器端完成，刷新也不会请求服务器，彻底隔绝这类问题。代码就一行：

const router = createRouter({ history: createWebHashHistory(), routes: [...] })

然后就是常规的Maven打包和Tomcat部署。SSM项目一般打成war包，把前端构建出来的dist目录整个拷贝进src/main/webapp下，接着mvn clean package。

部署成功后访问路径要特别留意Tomcat的项目上下文路径。假设war包叫chat.war，Tomcat默认上下文路径就是/chat，前端WebSocket连接的URL也要相应改成ws://localhost:8080/chat/chatServer。改漏了一个地方，页面能打开，但聊天连接一直失败。

6.2 源码整理和文档交付的规范

毕业设计最终要交的东西一般包括：源码、数据库脚本、演示文档、毕业论文。源码整理有规范，别让学生把node_modules也压缩进去，那玩意动辄几百MB。

建议交付包的结构：

chat-project/ ├── chat-backend/ # SSM后端工程，Maven结构 │ ├── src/ │ ├── pom.xml │ └── sql/ │ └── chat.sql # 初始化脚本，建库建表兼基础测试数据 ├── chat-web/ # Vue前端工程 │ ├── src/ │ ├── package.json │ └── README.md └── README.md # 项目总说明

README里必须写清楚环境要求、后端启动步骤、前端启动步骤、默认账号密码。这个文件写得好，老师运行起来的体验完全不一样。数据库SQL脚本要保证在一台新的MySQL5.7或8.0上能直接source执行，不要有遗漏的外键引用顺序。如果学校查重连代码一起查，记得在论文附录里只放关键代码，不要整个工程贴进去。

6.3 常见运行错误对照表

最后列一张我在实际过程中遇到最多的错误对照表，90%的本地运行问题都逃不过这些：

这套聊天管理系统，从数据库建表到WebSocket推消息，从Vue组件拆分到论文答辩，我的建议是别急着一次写完，按后端接口→前端页面→WebSocket通信→论文整理这个顺序推进。先把后端接口用Postman调通，再写前端对接，最后才处理WebSocket的实时推送。这样每个阶段都有可验证的产出，不会攒到最后几天通宵赶工。

我实际带人做完这个项目最深的一个体会是：聊天系统的难点不在某个单独的技术点，而在于链路长。消息从A的浏览器出发，经WebSocket到后端，落库，再推给B，中间哪一环断了，整个功能就废了。所以调试的时候一定要"分环节验证"——先确认数据库写没写入，再看WebSocket有没有推送，最后看前端有没有渲染。每一步单独验证过了，链路自然就通了。把这条思路贯彻下去，你的SSM+Vue聊天管理系统不仅能跑通，还能在被老师追问的时候，讲得清清楚楚。