SpringBoot+Vue实战：从零搭建文学创作社交论坛系统

项目标题这行字我第一眼看到的感觉是这是一个典型的“毕设/练手级”前后端分离管理系统但它的价值点在于业务场景非常具体——文学创作社交论坛。SpringBootVueJavaMySQLMyBatis这套组合放到今天依然是中小型系统中非常稳的选型。这个项目既不是纯后台的CRUD练习也不是花里胡哨的Demo而是一个有真实业务闭环的论坛系统作者写作品、管理员审核、读者评论点赞、标签分类管理。如果你正想找一个能完整练手前后端分离、又能在简历上写清楚业务亮点的项目我觉得这个方向很合适。这篇文章我打算用实战复盘的方式把我做这类系统时涉及到的需求拆解、数据库设计、后端接口实现、前端页面落地、部署排错这些环节都过一遍。很多内容是基于我自己做类似项目的常见实践补充出来的不一定和某个特定开源仓库完全一样但整体思路和关键代码写法可以直接参考。1 项目到底在做什么为什么值得做1.1 先理清业务角色和功能边界文学创作社交论坛核心不是“论坛”两个字而是围绕“创作”展开的内容生产与消费闭环。在我拆解这个项目的时候第一时间把用户分成三类普通读者、作者、管理员。一个人可以既是读者又是作者所以角色最好设计成用户表上的一个字段而不是单独建一套作者认证体系除非你要做实名、签约作者这种重度业务。普通读者端的核心诉求是找内容、看内容、反馈内容。找内容靠分类和标签筛选也可以靠搜索框看内容需要作品详情页和章节阅读页反馈内容就是评论、点赞、收藏。这三个动作看起来简单但并发场景下很考验接口设计。作者端则要提供作品创建、章节编辑、草稿保存、投稿审核、数据统计这些能力。管理员端最核心的是内容审核因为文学创作论坛内容量大如果审核不过关后面就会演变成内容安全问题所以审核列表、驳回原因、状态流转这些功能一个都不能少。把功能边界划清楚之后整个项目的开发顺序也就出来了先做用户注册登录再做作品模块再做审核流最后补评论点赞收藏这些社交动作。很多新手上来就写点赞接口结果作品模块还没影儿逻辑全是空的后面返工成本很高。1.2 技术选型不是拍脑袋SpringBootVueMySQLMyBatis这套组合在2025年依然值得选不是因为“大家都在用”而是它解决的问题刚好匹配这个项目SpringBoot负责把后端工程的配置简化到极致一个内嵌Tomcat就让部署变得非常简单开发阶段一个Application类直接跑起来。MyBatis虽然不如MyBatis-Plus写起来省事但它把SQL掌控力留给了开发者在这个项目里我要写多表关联、动态条件查询XML里手写SQL反而更直观。Vue3的组件化开发非常适合论坛这种多页面、多状态的场景单页应用切换流畅配合Element Plus做后台管理界面效率极高。MySQL不用多说中小型论坛的数据量完全够用事务支持和全文索引都可靠。可能有人会问为什么不加Redis我在项目早期也没加因为点赞、浏览计数这些热点数据在用户量没上来之前直接查数据库配合唯一索引就足够稳定。如果后面要扩展再把计数器迁到Redis用定时任务刷回MySQL这是后话但不影响当前架构的正确性。2 数据库设计先把表结构定清楚2.1 从实体关系到核心表数据库设计是整个项目里面最不能省的一步。我见过太多人没画清楚关系就写代码后面发现作品和章节对不上、评论查不出用户名、统计数量全是0最后只能重构表。这个系统的实体关系其实很清晰一个用户有多部作品一部作品属于一个作者。一部作品包含多个章节章节按sort_no排序。一个用户可以评论多个作品/章节一条评论可以有父评论形成楼中楼。一个用户可以点赞多个作品一个作品可以被多个用户点赞。一个作品可以有多个标签一个标签也可以挂在多个作品上。一个作品归属一个分类分类是一棵简单的两级树就够用。这些关系捋清楚之后表就是十张左右我列一下核心的usercategoryworkchaptercommentuser_likeuser_favoritetagwork_tagaudit_record。audit_record可能很多人会忽略其实很重要因为管理员审核通过或驳回的操作需要留痕出了纠纷可以追溯。2.2 几张核心表的字段拆解以work表为例字段设计我会这样写id主键author_id关联用户表title作品标题summary作品简介cover_url封面图category_id分类status状态word_count字数like_count点赞数favorite_count收藏数comment_count评论数create_time创建时间update_time更新时间is_delete逻辑删除标记。这里有个设计习惯我想特别提一下评论数、点赞数我直接冗余在了work表里而不是每次都去count子表。原因是论坛首页要展示一堆作品的点赞数和评论数如果每个作品都实时count一次一个列表接口会变成N1查询数据库压力非常大。冗余虽然有数据一致性问题但在这个业务场景下完全可以通过事务和定时任务去兜底性价比很高。章节表单独拆出来也很有必要。一部连载小说可能有几百章如果所有内容都塞在一张表里单行数据会很大列表查询会变慢编辑时锁表时间也会变长。拆成chapter表之后作品表负责元数据章节表只负责内容和排序两个表的职责边界非常清楚。下面是我个人的建表风格核心字段写出来大家建表时可以参考CREATE TABLE work ( id bigint(20) NOT NULL AUTO_INCREMENT, author_id bigint(20) NOT NULL COMMENT 作者ID, title varchar(200) NOT NULL COMMENT 作品标题, summary varchar(1000) DEFAULT NULL COMMENT 作品简介, cover_url varchar(500) DEFAULT NULL COMMENT 封面图, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0草稿 1待审核 2已发布 3被驳回 4已下架, word_count int(11) NOT NULL DEFAULT 0 COMMENT 总字数, like_count int(11) NOT NULL DEFAULT 0, favorite_count int(11) NOT NULL DEFAULT 0, comment_count int(11) NOT NULL DEFAULT 0, create_time datetime NOT NULL COMMENT 创建时间, update_time datetime DEFAULT NULL COMMENT 更新时间, is_delete tinyint(1) NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_author_id (author_id), KEY idx_category_status (category_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT作品表;状态字段我建议大家用tinyint不要用varchar状态迁移用数字可读性确实差一点但性能和约束能力都好很多而且在后端写枚举类做映射代码层面反而更规范。2.3 设计时我踩过的几个坑第一个坑是字符集。建库如果不指定utf8mb4默认字符集在插入emoji表情时直接报错Incorrect string value论坛评论里用户发个表情是很正常的事情所以建库SQL里必须加上CHARSETutf8mb4。第二个坑是时间字段我建议统一用datetime不要混合timestamp否则后面做统计查询时时区问题会让人很崩溃。第三个坑是逻辑删除评论、作品这些核心表一定要有is_delete字段但点赞表、收藏表不要做逻辑删除直接物理删因为它的意义就是一条关系记录删除后重新点赞反而更自然。另外唯一索引一定要到位。点过赞之后不能重复点赞这是业务硬约束与其在代码里先查一遍再插入不如直接在表上加联合唯一索引数据库层面挡住重复数据代码逻辑就算漏了也不会出大问题。3 后端核心实现SpringBoot MyBatis3.1 工程结构与基础配置后端工程我习惯按功能分包而不是按技术层分包。也就是com.forum.controller、com.forum.service、com.forum.mapper之外再按业务模块划分包比如user、work、chapter、comment、admin。这样做的优点是当你想看某个业务模块的完整代码时直接进一个包就能看全流程不用在各个层级之间反复跳。核心配置都在application.yml里下面这段配置是我每次搭建类似项目都会先写好的一版server: port: 8080 servlet: context-path: /api spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/forum?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case这个配置一定要打开否则数据库里的author_id映射不到JavaBean的authorId查出来全是null。日志打印也建议在开发阶段打开这样能直接在控制台看到MyBatis生成的SQL和参数排查问题效率翻倍上线前再关掉。3.2 JWT登录态与请求拦截这个项目是前后端分离Session方案天然不适用我选了JWT做无状态认证。流程很简单用户登录成功后后端用userId和role生成一个带过期时间的token返回给前端前端把token存到localStorage后续每次请求在Authorization头里带上后端用一个HandlerInterceptor统一解析验证。拦截器里有个细节要特别注意登录接口、注册接口、首页作品列表接口、作品详情接口都要放进白名单否则用户还没登录就什么都看不了那种体验非常差。很多新手会把拦截器加到所有路径上结果登录接口自己都被拦住了反复调不通。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 )) { token token.substring(7); } try { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write({\code\:401,\message\:\登录已过期请重新登录\}); return false; } } }这里的逻辑虽然简单但包含了两个容易忽视的点一是token前缀Bearer的截取前后端约定必须一致二是解析失败时直接返回401响应体而不是抛异常往后抛否则会变成500让前端一脸懵。3.3 作品发布与审核流程的实现作品发布是这个系统最核心的业务状态流转一定要设计严谨。我先定义状态枚举0草稿、1待审核、2已发布、3被驳回、4已下架。作者的操作为创建作品时是草稿可以编辑内容点击投稿后状态变成待审核管理员审核通过变成已发布审核不通过变成被驳回同时写一条驳回原因已发布作品也可以被管理员主动下架。这里最容易出错的地方是状态跳转校验。比如已发布的作品不能再提交审核被驳回的作品必须编辑后才能重新提交。我在Service层写了一个状态机方法每次变更状态前先判断当前状态是否合法。Override Transactional(rollbackFor Exception.class) public void audit(Long workId, Integer status, String reason) { Work work workMapper.selectById(workId); if (work null) { throw new BusinessException(作品不存在); } if (!work.getStatus().equals(WorkStatus.PENDING.getCode())) { throw new BusinessException(该作品当前状态不允许审核); } work.setStatus(status); work.setUpdateTime(new Date()); workMapper.updateById(work); AuditRecord record new AuditRecord(); record.setWorkId(workId); record.setOperatorId(CurrentUser.get().getUserId()); record.setAction(status 2 ? pass : reject); record.setReason(reason); auditRecordMapper.insert(record); }注意我在审核方法上加了Transactional。因为更新作品状态和插入审核记录必须在一个事务里如果先改了作品状态、后面插入审核记录失败那整个状态就错乱了。事务的rollbackFor一定要写成Exception.class否则抛出非RuntimeException时事务不会回滚这是很多人踩过的坑。3.4 用XML手写动态SQL的列表查询前台的作品列表需要支持多条件筛选分类、标签、状态、关键词、发布时间排序、最热排序。这种需求用MyBatis的XML动态SQL写起来非常顺手。select idselectWorkPage resultTypecom.forum.vo.WorkVO SELECT w.id, w.title, w.summary, w.cover_url, w.like_count, w.comment_count, u.nickname AS authorName, c.name AS categoryName FROM work w LEFT JOIN user u ON w.author_id u.id LEFT JOIN category c ON w.category_id c.id where if testcategoryId ! null AND w.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (w.title LIKE CONCAT(%, #{keyword}, %) OR w.summary LIKE CONCAT(%, #{keyword}, %)) /if AND w.status 2 AND w.is_delete 0 /where ORDER BY choose when testsort hotw.like_count DESC/when otherwisew.create_time DESC/otherwise /choose LIMIT #{offset}, #{pageSize} /select这个SQL有两个关键点。第一个是LEFT JOIN查询列表时把作者昵称和分类名称join出来避免在Java代码里循环查表全部一次查出。第二个是WHERE条件我把“已发布”和“未删除”这种固定条件直接写在where标签里作为一个全局兜底防止条件拼接出错时查出草稿内容。动态SQL还有一个非常实操的点新手经常在用 拼接条件时因为第一个条件前面带了AND导致SQL报错所以我会把固定条件放在 之后保证至少有一个无条件约束存在。上面这个语法里第一个if前面没有AND后面的if都用AND开头配合 标签会自动去掉最前面的AND这是比较稳妥的写法。4 前端实现细节Vue3 Element Plus4.1 前端工程搭建与目录规划前端我用的Vue3 Vite Pinia Vue Router Element Plus这套组合是目前Vue生态里最顺手的。Vite的冷启动速度比Webpack快太多开发体验完全不一样Pinia比Vuex写法更简洁省了很多样板代码。目录结构我建议按视图和功能混合组织src ├── api # 接口请求模块按业务拆分 │ ├── user.js │ ├── work.js │ └── admin.js ├── assets ├── components # 通用组件 │ ├── WorkCard.vue │ └── Pagination.vue ├── router │ └── index.js ├── store │ └── user.js ├── utils │ └── request.js ├── views │ ├── Home.vue │ ├── login/Login.vue │ ├── work/WorkDetail.vue │ ├── write/WriterCenter.vue │ └── admin/AdminAudit.vue └── App.vueapi目录单独抽出来是必做的一步因为前端所有请求都封装在api模块里后端接口变动时只需要改一个文件不用在页面里到处找。很多小项目把axios请求直接写在组件里开始只有两三个接口还行后面会长到完全没法维护。4.2 Axios封装、登录状态与路由守卫Axios封装是前端工程质量的分水岭。我的做法是统一实例里设置baseURL请求拦截器里从Pinia或localStorage取token加在请求头上响应拦截器统一处理后端返回结构遇到401自动跳登录页其他业务错误统一Message提示。import axios from axios import { ElMessage } from element-plus import router from /router import { useUserStore } from /store/user const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer userStore.token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response error.response.status 401) { const userStore useUserStore() userStore.logout() router.push(/login) } ElMessage.error(error.response?.data?.message || 网络异常) return Promise.reject(error) } ) export default request看了这段代码你应该能理解为什么我不在组件里直接写axios。组件只关心业务数据token注入、错误处理、登录过期这些横切逻辑全在拦截器里做掉了每个页面减少十几行重复代码。路由守卫我这里分了两层。第一层是登录权限凡是需要登录才能访问的页面如果没有token就跳登录页。第二层是角色权限后台管理页只有role为admin的用户才能访问。router.beforeEach((to, from, next) { const userStore useUserStore() if (to.meta.requiresAuth !userStore.token) { next(/login) return } if (to.meta.requiresAdmin userStore.role ! admin) { next(/403) return } next() })这套写法不难但很实用。把权限逻辑集中在路由守卫里比在每个页面去判断角色要省心太多而且不会漏。4.3 创作中心与作品详情页的实现思路创作中心是这个项目前端最有挑战的部分因为它不是一个简单的表单页而是多步骤创作流程。我的设计是左侧作品列表右侧章节编辑区。点击作品后展示章节列表每章可以独立编辑标题和正文然后保存草稿或提交审核。为了降低用户流失率我做了两个细节。第一个是本地上稿暂存每次编辑内容自动调用保存草稿接口而不是等用户手动点保存当然这个动作要加防抖第二个是章节拖拽排序让连载作者调整章节顺序时不用重新输入序数。作品详情页则要处理三个核心信息流正文阅读、章节目录、评论区。正文阅读我用了简单的分页加载一页一章章节目录做成侧边抽屉点击章节后局部刷新正文内容区而不是整个页面跳转。评论区有个常见问题是父子评论的嵌套如果后端返回的是扁平数组前端就要自己构建树结构。我建议后端直接按parent_id和create_time排序返回前端在递归组装时注意层级深度限制最多两级就够了再深会出现DOM层级过深和缩进错乱。4.4 富文本编辑、图片上传与安全过滤作者写小说、散文正文肯定不能只用一个textarea我用的是富文本编辑器创作中心里的章节内容就用富文本去编辑。但富文本编辑器的安全风险要想清楚用户粘贴过来的内容可能包含script标签、内联事件如果直接入库再原样渲染就是一个存储型XSS漏洞。后端在做内容保存时必须做HTML白名单过滤把script、iframe、on*事件全部剥掉只保留p、br、img、strong这些常用标签。前端展示时我也会再做一层转义兜底双保险。图片上传这里开发环境我直接把图片存到本地目录配置一个静态资源映射让前端能访问。生产环境我建议接入MinIO对象存储的好处是图片访问走独立域名可以减轻应用服务器磁盘压力。PostMapping(/upload) public ResultString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(文件不能为空); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; String datePath new SimpleDateFormat(yyyyMMdd).format(new Date()); File dir new File(uploadPath / datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir.getAbsolutePath(), fileName)); String url /upload/ datePath / fileName; return Result.success(url); }文件名必须重命名这个习惯一定要养成。直接用用户原始文件名一是中文和特殊字符会导致URL编码问题二是同名文件会互相覆盖。用UUID生成文件名是最省心的。5 联调、部署与常见问题排查5.1 前后端联调阶段的高频问题联调阶段是报错最多的阶段我梳理几个必定会遇到的问题。首先是跨域。开发时前端跑在5173端口后端跑在8080端口两个端口不同就是跨域。解决方式是在后端写一个CorsFilter允许指定来源访问但上线后我建议走Nginx反向代理让前端静态资源和后端API处于同一个域名之下这样就没有跨域问题了。很多人在本地把Axios的baseURL写成http://localhost:8080/api上线后忘了改成/api结果一片404所以在部署时我会把开发环境和生产环境的baseURL拆成不同环境变量。其次是Long类型的精度丢失。数据库表主键是bigint返回给前端时在JS里超过Number最大值会丢失精度。如果后面你用了雪花ID这个问题立刻就会出现。解决方式是在Jackson配置里把Long序列化为字符串。第三是日期格式问题。后端返回的LocalDateTime默认序列化出来的格式是带T的ISO格式前端如果不处理页面上直接显示一串字母。我在后端配置了全局Jackson格式为yyyy-MM-dd HH:mm:ss前端再配合dayjs做格式化两边统一。如果不统一列表页的时间列会乱得一塌糊涂。5.2 从本地到服务器的部署步骤这个项目部署起来其实不复杂但每个环节都容易出细节问题。我把完整步骤理一遍。第一步准备服务器环境装JDK8、MySQL5.7/8.0、Nginx。MySQL导入项目里的schema.sql注意建库时指定utf8mb4字符集。第二步后端打包在项目根目录执行mvn clean package -DskipTests生成的jar包通过ftp或scp传到服务器用java -jar forum-server.jar启动。为了让服务在后台稳定运行我用的是systemd配置服务脚本设置Restartalways省得进程一崩还得手动拉起来。第三步前端打包在vue项目里执行npm run builddist目录上传到服务器比如放到/opt/forum-web。第四步配置Nginx核心配置如下server { listen 80; server_name your-domain.com; root /opt/forum-web; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } client_max_body_size 10m; }location / 里的try_files是Vue Router history模式必须加的否则用户刷新详情页时Nginx会返回404。location /api/做API反向代理这样前端请求/api开头的地址后Nginx会转发给后端8080端口。client_max_body_size必须设置默认值是1m不改的话上传封面图稍微大点就413了。5.3 常见错误速查表我整理了一个速查表这几类问题是论坛项目里反复出现的大家可以直接按表排查。错误现象根本原因解决办法登录接口401登录请求被JWT拦截器拦截在拦截器白名单里放行/login接口前端登录成功但刷新后丢失登录态token只存在内存里没持久化用localStorage或Pinia持久化插件保存tokenMyBatis查询结果全是null驼峰映射没开启mybatis.configuration.map-underscore-to-camel-case设为true列表接口SQL一直报错where标签里的AND位置写错用 标签或固定条件兜底上传图片413Nginx默认限制1m设置client_max_body_size插入数据中文乱码数据库/表字符集不是utf8mb4重建库表并指定utf8mb4部署后刷新404Nginx没有try_files配置try_files $uri $uri/ /index.html点赞后数字不变前端缓存或接口无响应检查响应体里的like_count是否由后端增量维护这个表看起来平淡但每个都是真实发生过的。特别是第一和第二项拦截器白名单和token持久化我见过太多人在这两个问题上折腾一整天。5.4 几个值得长期保持的编码习惯第一MyBatis的XML文件里动态SQL拼接时建议统一用 嵌套不要自己在SQL里写where 11虽然能解决and开头问题但代码很难看。第二所有列表接口都必须分页不管现在数据量有多大这是习惯而不是需求。第三涉及金额、状态流转的操作必须加事务而且事务里不要捕捉异常吞掉否则回滚逻辑会失效。还有一点是关于日志的。开发阶段把MyBatis的SQL日志打印打开出问题时直接看控制台但是上线前一定要关掉因为生产环境打印全量SQL会导致日志文件暴涨和性能下降。可以用logstash或基于SpringBoot的日志框架来分级控制但最小可用方案就是logback.xml里调整成info级别。6 一些个人经验复盘6.1 如果重新做一次我会怎么改这个项目如果我再做一遍最大的改动会是把“作者创作”和“读者阅读”彻底拆成两个子系统来思考而不是在同一个服务里堆功能。倒不是说一定要微服务而是说在代码结构上创作端的作品保存、章节编辑、审核提交和阅读端的详情查询、评论列表其实是两类不同的访问模式。前者是低频写操作后者是高频读操作。如果把读写混在一起后面做缓存优化时你会非常痛苦。另外我会在项目初期就把搜索方案定下来。只靠MySQL的LIKE查询在数据量过万后就会变得很慢如果一开始就预留搜索的表结构或者直接引入Elasticsearch/OpenSearch后面做全文检索就不会伤筋动骨。论坛内容的搜索和筛选是这个项目的核心体验不能等到数据量大了才去补救。6.2 给想拿这个项目练手的人三条建议第一不要急着写代码。花两天时间把所有表结构设计好把状态流转图画明白再开始动手整体效率反而更高。第二一定要自己从头搭一遍工程不要直接用别人整合好的脚手架。SpringBootVue这套组合的配置细节非常多只有自己踩过坑才能说真正掌握了。第三把异常处理和参数校验当成一等公民来做一个接口没有参数校验传入空值直接空指针这种代码在简历上是减分项而不是加分项。最后说一句实在话这类论坛系统的技术点其实不难难的是把内容审核状态、点赞防刷、评论排序、数据一致性这些业务细节处理干净。当你把这些细节都扛下来这个项目的含金量就真的出来了。