提到基于SpringBoot的中华诗词文化交流平台很多人的第一反应是这不就是个“诗词列表加用户登录”的毕业设计吗说实话如果只做这两个功能确实没什么含金量。但把这套系统拆开看它要承载的是古典诗词的数字化传承、互动学习、创作分享三件事这就需要认真思考了。诗词不像普通的新闻资讯它有自己的文体结构、作者背景、朝代脉络、意象主题同时还要让用户既能“读”又能“写”写完还得有人审核、有人评论、有人点赞——这些业务场景落下来就是一个完整的社区平台。我这次要聊的就是基于SpringBoot从零搭建这样一个诗词文化交流平台的全过程。项目名称里包含了“古典诗词数字化传承与互动学习平台”“中华诗词鉴赏与创作分享社区系统”这些说法其实它们描述的是同一个系统的不同侧面对文化内容做结构化整理对用户提供互动和创作能力。文章会覆盖需求拆解、表结构设计、核心功能实现、性能优化、部署排查以及答辩时容易被问到的问题。如果你准备做类似的JavaWeb毕设或者想在企业项目之外做个有文化味的练手项目这篇应该能帮上忙。1. 项目整体拆解诗词平台不只是“诗词增删改查”1.1 核心需求定位先搞清楚平台给谁用做毕设最容易犯的错就是一上来就写代码写到一半发现需求全是“我以为”。诗词平台这种题目需求方其实是两类人。一类是普通用户他们想看诗词、搜诗词、学习鉴赏、写下自己的感想甚至自己创作一首诗发到社区另一类是平台管理方需要对诗词内容进行分类维护、对用户提交的创作做审核、对违规评论做处理。基于这个定位系统的核心链路就很清晰了用户进入平台后可以通过朝代、作者、主题、关键字等维度检索诗词进入诗词详情页看到原文、注释、译文和鉴赏内容用户可以收藏、点赞、评论用户也可以进入“创作中心”提交自己的作品作品进入待审核状态审核通过后展示在社区中。后台管理员可以维护诗词库、管理用户、审核作品和评论。这里有一个容易被忽略的点诗词数据本身是“内容资产”它不是用户生成的而是运营人员预置的。所以系统天然分成“内容管理系统”和“用户交互系统”两部分。内容管理部分要求后台能高效录入、批量导入、按条件筛选用户交互部分要求前端响应快、互动链路完整。把这两块想明白后面的技术选型才有依据。1.2 用户角色与用例边界两个角色把功能切干净从角色角度看这套平台只需要两个角色普通用户和管理员。很多毕设喜欢搞“超级管理员、普通管理员、注册用户、游客”一堆角色但角色越多权限控制越复杂演示效果反而不直观。我建议只保留两个角色把用例边界划清楚。普通用户的用例包括注册登录、浏览诗词、按条件检索、查看详情、收藏、点赞、评论、提交创作、查看自己的作品列表。管理员用例包括登录后台、维护作者信息、维护诗词信息、审核创作、删除违规评论、统计平台数据。游客可以不登录浏览诗词但点赞、评论、创作必须要求登录。我做的时候特意保留了“游客可浏览但不互动”这个边界因为它能让答辩演示更流畅先不登录演示检索和鉴赏再登录演示互动和创作流程很自然。另外游客和用户的权限区分也方便在答辩时讲清楚权限控制的实现方案。2. 技术选型与数据模型设计地基打得稳后面少熬夜2.1 技术栈选择SpringBoot为主MyBatis-Plus和JWT是刚需技术栈方面我采用的是比较稳妥的毕设组合SpringBoot 2.7.x MyBatis-Plus MySQL Redis JWT前端用Vue3 Element Plus。SpringBoot这里不用多说它的自动配置和起步依赖能省掉大量xml配置非常适合快速搭建这种业务型系统。MyBatis-Plus值得多说两句。它是在MyBatis基础上封装的增强工具内置了通用的增删改查方法分页插件也做得比较成熟。对于诗词平台这种数据表多、关联查询不少的系统用MyBatis-Plus可以省掉大量重复的Mapper XML。我实际用下来单表的增删改查几乎不需要写SQL只有联表统计才需要自定义方法。身份认证我用的是JWT而非传统的Session。理由很简单第一前后端分离结构下JWT不需要考虑跨域携带Cookie的问题前端把token放在请求头里就行第二Spring Security JWT的组合在答辩时是一个很好讲的点“无状态认证”这个概念一抛出来老师一般都会有兴趣追问提前准备好话术就是加分项。Redis在这里用来做热点诗词的缓存和点赞计数后面我会细讲为什么用Redis而不是直接查MySQL。2.2 表结构设计六张核心表把业务串起来数据表设计是这套系统的灵魂。我反复调整过几次最终稳定下来的核心表有六张用户表、作者表、诗词表、创作作品表、评论表、互动记录表。另外还加了一张分类表用于朝代和主题的归类。用户表的核心字段包括id、用户名、密码、昵称、头像、角色、状态、创建时间。密码必须加密存储我用的BCrypt它内置了随机盐同一个密码每次加密结果都不同安全性比MD5强很多。作者表相对简单就是姓名、朝代、生平简介、代表作品数量。诗词表是信息密度最高的一张表。诗词表的设计我贴一下核心SQL这个值得你抄作业CREATE TABLE poem ( id bigint(20) NOT NULL AUTO_INCREMENT, author_id bigint(20) DEFAULT NULL COMMENT 作者id, category_id bigint(20) DEFAULT NULL COMMENT 分类id, title varchar(100) NOT NULL COMMENT 诗词标题, content text COMMENT 诗词正文, annotation text COMMENT 注释, translation text COMMENT 译文, appreciation text COMMENT 鉴赏, dynasty varchar(20) DEFAULT NULL COMMENT 朝代, style varchar(20) DEFAULT NULL COMMENT 诗/词/曲, view_count int(11) DEFAULT 0 COMMENT 浏览量, favorite_count int(11) DEFAULT 0 COMMENT 收藏数, status tinyint(1) DEFAULT 1 COMMENT 状态1上架0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_author (author_id), KEY idx_dynasty (dynasty), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个设计细节很重要。第一正文和注释、译文、鉴赏都用了text类型因为诗词虽然短但鉴赏内容可能几百上千字varchar撑不住。第二检索字段都建了索引尤其dynasty这种会被频繁筛选的字段。评论区需要关联poem_id、user_id、content、parent_id、status。互动记录表我单独设计成“单表双用”字段包括id、user_id、target_id、target_type、interact_type、create_time。target_type区分是诗词还是创作作品interact_type区分是点赞还是收藏。这样一张表就可以同时处理两类内容、两种互动行为查询时用唯一索引user_id, target_id, target_type, interact_type防重。2.3 冗余字段和状态标志为了性能和审批流程做的取舍表结构里有两个地方我当时犹豫过但现在看是必须做的。一是诗词表里的favorite_count字段它本身就是冗余的因为收藏数可以通过统计互动记录表算出来。但我在列设计时还是加了原因很简单首页展示和列表页需要展示收藏数如果每次都去count互动表数据量上来后就是一场灾难。写操作时把这个字段加一减一读操作直接拿出来展示性能好很多。二是status字段。诗词内容有“上架/下架”状态创作作品有“待审核/通过/驳回”状态。这两个不是一个概念千万别混用一个状态字段。诗词的下架是内容下架创作作品的三态是审批流混在一起的话后台审核逻辑会非常混乱。我见过有人用一个字段0/1表示所有状态结果“待审核”和“已下架”语义冲突最后不得不在代码里写一堆奇葩判断。既然做内容平台就把状态区分清楚这是过来人的提醒。3. 核心功能实现从检索到创作分享的完整链路3.1 诗词鉴赏与多维度检索让你的查询好用到愿意抄用户进入系统后第一个高频动作就是找诗。如果只提供一个关键字搜索框那这个平台的“文化交流”属性就太弱了。我设计了三种检索方式导航栏的全局搜索按标题和诗句模糊匹配分类页按朝代和体裁组合筛选作者页按作者聚合展示其作品列表。三种方式最终都走同一个分页查询接口。全局搜索和组合筛选我放在同一个Service方法里做用一个宽松的查询条件对象接收前端参数Override public IPagePoemVO pagePoems(PoemQuery query) { LambdaQueryWrapperPoem wrapper Wrappers.lambdaQuery(); wrapper.eq(StringUtils.hasText(query.getDynasty()), Poem::getDynasty, query.getDynasty()) .eq(StringUtils.hasText(query.getStyle()), Poem::getStyle, query.getStyle()) .eq(query.getAuthorId() ! null, Poem::getAuthorId, query.getAuthorId()) .like(StringUtils.hasText(query.getKeyword()), Poem::getTitle, query.getKeyword()) .or(StringUtils.hasText(query.getKeyword()), wrapper - wrapper.like(Poem::getContent, query.getKeyword())) .eq(Poem::getStatus, 1) .orderByDesc(Poem::getCreateTime); return poemMapper.selectVoPage(new Page(query.getPageNum(), query.getPageSize()), wrapper); }注意这里的写法有个坑当keyword为空时like条件不会拼接但当keyword非空时title和content两个like是or关系一定要把or包在嵌套wrapper里否则动态拼接SQL时容易和前面的dynasty条件组合出错误逻辑。这个坑我调试了大半天写出来给各位避雷。详情页除了展示诗词内容我还会展示同一作者的其他作品这个非常简单根据authorId再查一次列表就好但体验提升明显。另外为了应对首页和分类页的高频访问我会把前20首热点诗词缓存在Redis里key设计为“poem:hot:page:1”过期时间30分钟。实测首页吞吐量提升非常明显这个优化点到答辩时也是亮点。3.2 创作分享与内容审核审批流才是内容平台的命门用户创作一首诗提交后并不是直接展示到社区而是进入待审核列表。这一步是内容平台和普通博客系统的本质区别。诗词内容虽然不像新闻那样敏感但创作质量参差不齐如果随意展示平台会被灌水内容淹没。所以创作模块我做成“提交即入库审核后展示”的异步流程。作品表的设计上字段和诗词表类似但多了user_id和review_status。提交创作的接口很简单校验用户登录、校验标题和正文非空然后插入作品表并设置状态为0待审核。这里我先不校验内容合规性因为违规内容在审核阶段统一处理。审核接口只有管理员角色能调用管理员看到的是“待审核列表”列表里展示作品标题、提交人昵称、提交时间、正文预览。审核通过就把review_status改成1驳回就填写驳回理由并把状态改成2。这里有个体验细节用户在“我的作品”页面能看到每个作品当前处于什么状态被驳回的能看到理由。我专门写了一个状态流转的枚举类把0、1、2三种状态和对应文案映射起来避免前端到处写魔法数字。答辩时老师问“你的平台如何保证内容安全”就可以顺势把内容和审核链路讲清楚比干巴巴地说“我用了XX组件”强得多。3.3 互动学习链路点赞、收藏、评论与消息提醒互动功能是“学习平台”这个定位的抓手。我实现的互动包括收藏、点赞、评论三层。收藏和点赞的数据都写在互动记录表中但两者的语义不同收藏是用户主动把诗词放入自己的列表点赞是轻量表达喜爱收藏会同步累加诗词表中的favorite_count点赞则通过Redis计数器维护。前端按钮状态是根据当前用户和当前内容去查互动记录表判断的。为避免用户疯狂点击导致重复记录我在互动记录表上建了唯一索引user_id, target_id, target_type, interact_type插入前先尝试查一条记录有记录就提示“您已经操作过了”。评论是分层级的普通评论挂在诗词或作品下回复评论则用parent_id指向原评论前端收到后做缩进展示。消息提醒听起来高端但实现起来很简单。当有人评论了用户提交的作品时系统会往消息表插一条记录字段是receiver_id、content、is_read。用户在导航栏能看到未读消息的红点点进去就是消息列表已读状态批量更新。这一个功能就能串起“互动学习”的产品概念用户创作、他人反馈、用户收到通知再次交互整条链路就闭环了。4. 实操过程与性能优化数据导入、缓存、部署排坑实录4.1 数据从哪来诗词库的导入与去重策略做内容平台最麻烦的不是程序而是内容本身。诗词数据不像普通测试数据可以随便造需要真实、准确、完整。我的做法是网上找公开的诗词语料库下载JSON格式数据然后写一个数据导入工具类在项目启动时或者通过一个单独的命令行Runner执行导入。导入逻辑要做三步处理一是作者去重同一个作者可能在不同数据源里出现多次我用“姓名朝代”作为业务唯一键存在就跳过不存在才插入二是诗词去重用“作者id标题”做唯一键三是内容清洗去掉HTML标签、多余空格、全角空格转半角。清洗这一步最容易忽略如果不做详情页里的排版会很丑而且检索时还会出现“词里包含了不可见字符导致搜不到”的诡异问题。导入的事务控制也得注意。我一次性导入几千条诗词时如果中途出错要能回滚。但几千条数据一把梭事务太长会锁表。我的方案是每500条一批批内开启事务批次之间独立提交这样单批失败不影响其他批次。实际执行下来大约两三千条数据也就十几秒导入完成后台展示数据量完全够。4.2 Redis缓存策略与点赞计数优化前面提过Redis两个用途缓存热点诗词、维护点赞数。这里具体讲讲实现。点赞数如果每次加一减一都写MySQL高并发下会产生大量行锁竞争虽然毕设并发量不大但既然用了Redis就顺手把点赞计数做成异步最终一致。用户点赞的接口流程是先查互动记录表判断是否已点赞如果没有插入一条互动记录同时把Redis里的点赞计数做incr操作前端展示的点赞数直接读Redis。定时任务每5分钟把Redis中变化的key同步回MySQL同步方式是遍历热点key读取当前值更新到对应记录。这中间有个时间窗口Redis里的值和MySQL的值可能短暂不一致但对一个展示型平台来说这种秒级延迟完全可接受。缓存的过期策略也要说清楚。热点诗词缓存的key我设计成“poem:hot:页码”value是序列化后的列表JSON过期时间30分钟。为了保证不出现“缓存雪崩”我在key设计时加了随机数后缀的前缀避免所有热门页同年同月同日同时过期。虽然毕设规模谈不上雪崩但你可以把这个设计作为“考虑过极端场景”的证据写进论文。4.3 部署环境与常见报错排查速查表你在自己电脑上把项目跑通和部署到云服务器上是两码事。我的建议是既然做毕设至少部署一次远程服务器给老师演示线上地址印象分完全不一样。部署方案我用的是宝塔面板 Nginx反向代理前端构建后放到网站目录后端打成jar包用systemd守护运行MySQL和Redis都装在同一个云主机上。部署过程中最容易出问题的几个点第一是端口占用SpringBoot默认8080但云服务器上可能有其他服务占用我改用8088并在Nginx里做了/api路径的反向代理第二是数据库连接配置远程MySQL必须允许指定IP地访问并注意修改防火墙规则第三是时区问题服务器默认UTC会导致创建时间差8小时我在连接串里加上serverTimezoneAsia/Shanghai解决。我把部署和本地运行时遇到的高频问题整理成了表基本都是实测过的故障现象常见原因排查与解决启动报端口占用8080被其他进程占用改server.port或kill占用进程前端请求后端404前端代理路径和后端接口前缀不一致统一通过nginx配置/api做映射登录后请求接口401token过期或请求头没带Authorization确保前端axios拦截器统一携带token中文乱码数据库建表字符集不是utf8mb4重新建表并确认连接串加characterEncodingutf8分页查不到总页数MyBatis-Plus分页插件没注册配置PaginationInnerInterceptor评论插入失败parent_id指向了不存在的评论插入前做外键存在性校验前端跨域报错后端未启用CORS或配置不匹配编写CorsFilter允许前端完整域名访问这些坑单独看都不大但会轮流消耗你的时间。我后面做类似项目时基本都会先把这份速查表过一遍省不少事。5. 答辩要点与进阶扩展让项目从“合格”变成“亮眼”5.1 高频答辩问题与回答思路答辩环节老师最常问的问题其实很集中。第一个必然是“为什么选择SpringBoot”。回答思路要往生态和效率上靠SpringBoot的自动配置和起步依赖解决了传统SSH/SSM繁琐配置的问题让开发者更聚焦于业务逻辑同时它有庞大的社区生态和MyBatis-Plus、Redis、JWT等组件都能无缝集成。第二个是“你项目中最大的难点是什么”。这个问题不要说自己没遇到难点最好选一个真实解决过的问题并展开比如我在3.1中提到的动态多条件or查询的SQL拼接问题或者4.1的数据清洗问题。第三个问题是“Redis在项目中起了什么作用”。我会从三个场景回答热点诗词缓存提升读性能、点赞计数异步落库、以及登录token的存储校验。每个场景都能说清楚技术选型的原因老师会认为你是真做过、真思考过。第四个常见问题是“数据库设计有哪些优化”。这里可以讲冗余字段、索引设计、唯一索引防重这些都是可以展开的价值点。5.2 从毕设到作品集的三个升级方向如果你不满足于交一个能跑的项目想让这套诗词平台成为简历上的作品我提供三个扩展方向。第一个是把“诗词检索”升级为“智能检索”引入分词器和拼音匹配用户输入“libai”也能搜到李白输入“静夜”能匹配到包含“思故乡”的诗句。第二个是增加一个简单的推荐模块根据用户收藏和浏览历史推荐同一朝代或同一作者的诗词用基于标签的协同过滤就能实现避免引入太重的大数据组件。第三个是增设对联或飞花令之类的互动玩法比如“飞花令”随机给出关键字用户输入包含该字的诗词系统校验诗句是否存在且包含关键字。这种模块一加平台的文化属性、互动属性、趣味性直接拉满比单纯做CRUD强太多。我个人认为毕设项目最怕的不是功能少而是功能之间没有逻辑关联。诗词平台天然有内容、有创作、有社区互动底层数据模型和业务链条本来就完整只要你在设计时把“数字化传承、互动学习、创作分享”这三句话真正落进代码里它就是一套有说服力的作品。最后说点实在的。我从需求梳理到部署上线前后大概花了三周其中纯写代码的时间不到一半更多时间花在调SQL、改权限、处理脏数据上。如果你也想做类似的平台我的建议是先把表结构设计到你自己挑不出毛病再动手写代码先跑通主流程再补细节。诗词这东西看起来偏文科但它本质是“有结构的内容”结构化内容加社区互动恰恰是后端开发者最能发挥的场景之一。做完了你会发现它既是毕业设计也是一个可以拿出去讲完整技术故事的作品。