大三下学期帮一个学弟把他毕业设计的文学创作社交论坛项目完整跑了一遍，这个项目用的就是很经典的 SpringBoot + Vue + MySQL 组合，压缩包里源码、数据库脚本、毕业论文、部署文档全都有。刚开始我以为是普通的增删改查管理系统，结果真正动手才发现，这种“内容社区”方向的毕设复杂度比想象中高不少：用户体系、作品发布、评论互动、后台审核、数据统计，前后端接口要联调，部署上线还要处理各种环境问题。这篇文章就把这个项目从功能设计、表结构、核心代码到部署上线整个链路拆开讲清楚，哪些地方容易翻车我也会重点标出来。如果你正在做同类型的毕设，或者想拿一个全栈项目练手，这篇内容可以直接当参考手册来用。
1. 项目全貌：文学创作平台到底在做什么
1.1 先拆功能：这类平台一般包含哪些模块
文学创作社交论坛，简单说就是让用户在网上写小说、发散文、贴诗歌，同时可以互相关注、评论、点赞、收藏的社区。毕业设计的范围通常包含两部分：对外用户使用的论坛前台，和对管理员使用的后台管理页面。
前台核心功能大概分这几块：
- 用户系统：注册、登录、个人信息、修改资料、密码找回、关注/粉丝关系。
- 作品模块：发布文章、写连载小说、设置分类、配置封面图、草稿箱、作品删除与修改。
- 互动模块：评论、点赞、收藏、举报、浏览量和热度排行。
- 社区模块：首页信息流、分类浏览、关键词搜索、作者主页、热门榜单。
- 后台管理：用户管理、作品审核、评论审核、分类配置、数据统计面板。
我拿到的这套带 xabo 标识的项目源码，基本就是这个结构。后台用 SpringBoot 提供 REST 接口，前端 Vue 通过 axios 调接口，数据库里是几张核心业务表加若干关联表。对照论文里的功能需求分析会发现，几乎每个用例都能在代码里找到对应实现，这也是这个选题能够顺利通过评审的原因：功能完整度足够，业务闭环清晰，演示的时候有东西可讲。
1.2 为什么“做个社区”比“做个管理系统”更适合毕设
很多同学之所以选这个题目，是因为它正好卡在“简单管理系统”和“高并发互联网项目”中间，难度梯度非常友好。如果只做一个单表增删改查的宿舍管理系统，论文写出来会显得单薄，整个项目就是 CRUD 的堆叠，技术展示度不够；如果硬要做秒杀系统、分布式中间件，本科生很难在有限时间内完成，答辩也容易被追问得焦头烂额。文学创作社区这个定位，业务上足够练手，技术上又不会失控。
第二个理由是数据模型有天然的复杂度。用户和作品是一对多，作品和评论是一对多，用户和作品之间还有收藏、点赞、关注这些多对多关系。多表联查、分组统计、分页排序，这些恰好是数据库课程里最重要、也最容易被考核的知识点。做完这个项目，数据库设计能力会有非常明显的提升，而且这些表结构可以直接复用到博客系统、问答社区等场景里。
第三个理由是“创作内容”这个场景有很好的演示效果。答辩现场给老师演示时，发布一篇图文作品、评论区漫游、查看排行榜，整个过程比纸质管理系统直观很多。老师看着有兴趣，问的问题也会更聚焦在业务上，不容易出现你完全答不上来的偏题。
2. 技术选型拆解：SpringBoot、Vue、MySQL 是怎么配合的
2.1 后端分层：源码拿到手先看这几个目录
拿到源码之后，第一件事不是立刻启动，而是先把目录结构看懂。一个标准的 SpringBoot 工程通常是这样组织的：
- controller：接收前端请求，做参数校验和结果封装，不写业务逻辑；
- service：放业务逻辑，比如发布作品时同步更新用户的发布数量，业务规则都写在这里；
- mapper（Dao）：对数据库的操作，一般配合 MyBatis 或 MyBatis-Plus 使用；
- entity/model：对应数据库表结构的实体类；
- config：配置类，比如跨域、拦截器、WebMvcConfigurer；
- utils：通用工具，例如 JWT 工具类、日期工具、统一返回结果封装。
核心配置文件 application.yml 放在 src/main/resources 下，数据源、端口、MyBatis 映射路径都在里面。如果部署文档或论文里给了项目结构图，绪论章节可以直接复用。
这样分层的核心意义在于职责单一。接口出问题，先查 controller；业务逻辑不对，查 service；SQL 慢或者查不到，查 mapper XML。答辩被问“你的项目如何维护”，能答出这一层，基本就过关了。很多人只会说“项目能跑”，但说不清代码分层，答辩时很容易露怯。
2.2 前端页面组织：Vue 的目录与路由
前端部分常见的组合是 Vue 2 + Element UI，或者 Vue 3 + Element Plus。无论哪种，目录结构都差不多：
- src/views：页面组件，如首页、作品详情、个人中心、后台管理；
- src/router：路由配置文件，包含每个页面地址和组件映射；
- src/api：按模块封装的请求文件，比如 user.js、article.js；
- src/utils/request.js：基于 axios 封装的实例，统一加 token、统一处理错误码。
Vue 最大的优点就是组件化。首页信息流是一个组件，评论区是一个组件，排行榜是一个组件，每个组件只负责自己那块渲染，修改起来互不影响。路由用 Vue Router 管理，页面跳转不用整页刷新，体验比传统 JSP 好很多。开发阶段前端通过 npm run serve 启动，默认监听 8080 端口，接口请求通过代理转发到后端端口，这一步通常在后端跨域配置里已经处理好了，等部署阶段再用 Nginx 做同源反代。
2.3 数据库设计：这几张核心表决定了项目上限
先不用急着建表，把业务关系画出来再动手。这个项目里最核心的关系是：
- 用户（user）一对多作品（article）
- 用户一对多评论（comment）
- 作品一对多评论
- 用户和作品多对多，通过中间表 like_record、collect_record
- 用户和用户多对多，通过中间表 follow_record
核心表字段可以参考这样设计：
用户表 user：id、username、password、nickname、avatar、introduction、role（0 普通用户 / 1 管理员）、status、create_time。
作品表 article：id、user_id、category_id、title、cover、content（LONGTEXT）、status（0 草稿 / 1 待审核 / 2 已发布 / 3 封禁）、view_count、like_count、collect_count、create_time、update_time。
评论表 comment：id、article_id、user_id、parent_id、content、create_time。parent_id 用来支持楼中楼回复。
点赞记录表 like_record：id、user_id、article_id、create_time，并为 user_id 和 article_id 建唯一索引，确保一个人只能点赞一次。
收藏表 collect_record：结构和点赞表类似。
关注表 follow_record：id、user_id、follow_user_id、create_time。
分类表 category：id、name、sort。
设计要点有三个。第一，点赞数、收藏数、浏览数这种统计字段冗余在 article 表里，列表页直接展示，避免每次都用 count() 全表统计，性能好很多。第二，点赞收藏一定要单独存记录表，不只靠数量字段，否则没办法判断当前用户是否已经点过，也无法做取消操作。第三，逻辑删除（用 status 字段）比物理删除更安全，用户反悔恢复数据也容易，而且后台审核流程天然依赖这个状态字段。这套表设计写进论文的 E-R 图和数据字典部分，内容会非常充实。
3. 核心模块实现：从登录到互动的完整链路
3.1 登录注册与 JWT 鉴权：很多人写不对的一步
几乎每个全栈毕设都要处理登录。这个项目用的是 JWT，也就是无状态 token 方案。流程是：注册时用 BCrypt 对密码做哈希，数据库里不存明文；用户登录后，后端把 user_id、角色、过期时间加密生成一个 token 返回给前端；前端把 token 存在 localStorage，每次请求在 header 里带 Authorization: Bearer token；后端写一个拦截器，对所有需要登录的接口统一校验。
核心拦截器代码一般长这样：
@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException("未登录"); } String userId = JwtUtils.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", userId); return true; } }再把拦截器注册到 WebMvcConfigurer，并放行登录、注册、首页列表这些公开接口。
这里有两个坑要专门提一下。一个是 token 有效期不要设太长，一天到一周比较合理，前端拿到 401 后自动跳到登录页重新登录；另一个是后端校验 token 时一定要从请求头读取，不要接受 URL 参数传 token，也不要随便在前端把 token 打印到控制台，容易被截获。密码加密必须用 BCrypt，不要用 MD5，MD5 撞库太容易，这属于保护用户数据的底线操作。
3.2 作品发布：富文本内容、草稿与审核状态
作品发布是这个社区最核心的用户行为。实现逻辑通常是：前端用富文本编辑器（比如 wangEditor 或 markdown 编辑器）把内容做成 HTML 或 Markdown，提交给后端后，article 表插入一条记录，status 根据操作不同设为草稿或待审核。管理员审核通过后，status 变成已发布，其他人才能在列表和详情页看到。
后端有一个细节非常关键：作品内容在保存时一定要做 XSS 过滤，把
