做毕设选题最怕碰到两类下场：一类是系统太简单，答辩时被老师连环追问直接问穿；另一类是功能堆得花里胡哨，实际开发周期根本撑不住，最后通宵赶工也交不出一份能跑的代码。“java+Spring Boot+MySQL 中国历史故事展播系统”这套名字听起来挺唬人，但它本质上是一个“内容管理与展示系统”的经典变体——技术栈主流、功能边界清晰、业务主题自带辨识度，正是那种卡在“简单”和“复杂”中间的最优解。这篇文章我会把选题理由、数据库设计、核心功能实现、开发中容易翻车的细节，以及最后怎么应对答辩和写进简历，完整地拆开讲一遍，给准备走这条路的人一条可以直接照抄的作业。
1. 这套系统凭什么值得选：选题价值与工作量盘点
1.1 内容管理系统为什么是毕设里的“常青树”
你打开任何一个毕设选题库里，翻来覆去最不缺的就是“XX管理系统”：图书管理、学生管理、仓库管理、酒店管理。这些题目被选了这么多年，说明一个道理——对于本科阶段的毕设，内容管理类系统的覆盖面特别合适。它天然包含前端页面展示、后端接口设计、数据库建模、增删改查、分页搜索、权限控制这些Web开发的核心模块。你只要能把这几块完整走通，计算机专业毕业设计要求的“完整开发流程”就已经达标了。
但传统管理系统的通病在于业务太单薄。“图书管理”就是一个图书表加借阅表，数据库撑死五张表，代码写起来像填空题，答辩时老师问“你系统里有什么亮点”，你很难说出个一二三。而“中国历史故事展播系统”虽然底层架构同样是内容管理，但业务外延大得多：故事有朝代归属、有历史人物关联、有分类标签，前台需要“展播”即浏览与检索的体验，后台要支撑内容的持续录入和维护。这些额外属性让项目的分析设计环节有话可说，也让数据库的ER图不至于单薄到拿不出手。
1.2 中国历史故事主题带来的差异化优势
选题也需要有“记忆点”。同样的技术实现，如果题目叫“基于Spring Boot的某网站系统”，老师扫一眼就过去了；但如果叫“中国历史故事展播系统”，项目名称里就有明确的文化场景。中国历史故事这个主题，天然把用户群体定义为泛历史爱好者、学生群体、教育场景使用者，你可以非常自然地在系统里加入“按朝代浏览”“按故事类型筛选”“热门故事排行”这些功能点，而它们不显得生硬。
从评阅角度看，历史故事主题还有一个隐形好处：数据获取零门槛。故事内容属于公开文化知识，不存在版权纠纷和敏感内容问题，你可以合法合规地整理上百条故事素材导入数据库，让系统启动后就有真实丰富的内容可看。做过毕设的人都知道，一份数据量饱满、打开页面能看到满满当当内容的项目，演示效果比空壳系统好太多。
1.3 一个人独立开发的合理工期推算
我按一个在校学生每天能投入4到6小时的节奏算过一笔账。这个系统的合理工期在3到4个月之间，具体拆分如下：
| 阶段 | 主要任务 | 参考耗时 |
|---|---|---|
| 需求分析与开题 | 用例图、功能清单、技术选型 | 1周 |
| 数据库设计与文档 | 建库建表、ER图、字段说明 | 1~2周 |
| 后端框架搭建与登录权限 | 项目初始化、统一异常、JWT或Session登录 | 2周 |
| 核心业务功能开发 | 故事管理、分类、朝代、前台展示 | 4~5周 |
| 前端页面美化与联调 | 页面布局、接口对接、富文本展示 | 2~3周 |
| 测试完善与论文写作 | 功能自测、修复BUG、论文初稿 | 2~3周 |
这个节奏整体可控，不会出现做到一半发现进度失控的局面。真正有风险的环节通常在数据库设计阶段，因为一旦表关系没想清楚，后续所有功能代码都会被返工拖累。这也是为什么我强烈建议你在写任何一行业务代码之前，先把数据模型聊透。
2. 技术栈定版：版本选择比“用了什么”更重要
2.1 我的最终选型：Spring Boot 2.7还是3.x，JDK 8还是17
如果只看最新版，现在官方主推的是Spring Boot 3.x配合JDK 17。但作为毕设项目，我个人建议你优先选Spring Boot 2.7.x配JDK 8。原因很现实：Spring Boot 3.x底层是基于Jakarta EE命名空间的，很多网上的旧教程和现成代码片段在3.x下会直接报错，比如javax.servlet改成了jakarta.servlet，一些小众依赖也未必跟进了新版本。而2.7.x是2.x系列的最后版本，资料极其丰富，遇到问题几乎搜索一下就有答案。
JDK 8同理。虽然17已经非常普及，但学校机房、指导老师电脑上装的环境很可能还是Java 8。你用JDK 8开发部署，兼容性最稳妥；写论文的时候技术描述写成“使用Spring Boot 2.7.18框架、JDK 1.8环境”也没有任何问题。毕设考察的是你对技术的掌握程度，不是版本新旧。
2.2 MySQL 8.0配置里最容易踩的字符集与时区问题
数据库我建议使用MySQL 8.0，它已经是目前最广泛使用的社区版。真正值得注意的是连接配置。很多同学的数据库本身建立得没问题，但一启动项目，插入中文就变成“???”，查看时间字段总是跟本地时间相差8小时。这两个问题其实都出在JDBC连接串上。
你需要在application.yml里这样配置：
spring: datasource: url: jdbc:mysql://localhost:3306/history_story?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver这里有几个点要说明：characterEncoding=utf8mb4比utf8更保险，虽然MySQL 8.0默认字符集已经是utf8mb4，但连接串上显式指定可以避免一些环境差异；serverTimezone=Asia/Shanghai解决的是时区偏差；allowPublicKeyRetrieval=true是MySQL 8.0在非SSL连接下常见的一个认证报错项。这些配置不在同一时间排错，可能每一项都要浪费你半天。
2.3 持久层用MyBatis-Plus还是Spring Data JPA
这是这类项目最经典的选择题。我的建议很明确：用MyBatis-Plus。原因有三点：第一，MyBatis-Plus的BaseMapper提供了开箱即用的单表CRUD，你不需要手动写大量的XML映射文件，开发效率极高；第二，它自带分页插件PaginationInnerInterceptor，实现分页查询只需要几行代码；第三，国内绝大多数Java岗位面试都在问MyBatis相关的经验，你做完这个项目掌握的技能，可以直接转化为面试中的谈资。
Spring Data JPA确实在对象建模上有优势，但对习惯SQL思维的学生来说，JPA的自动建表、懒加载、级联操作这些机制反而容易产生“黑盒感”。答辩时如果被问到底层SQL怎么执行，MyBatis-Plus的使用者能答得更扎实。
2.4 前端方案：服务端渲染还是前后端分离
这里给你两条路，按你的基础选：
- 不会Vue，或者前端基础一般：用Thymeleaf服务端渲染。Spring Boot对Thymeleaf的支持非常成熟，页面里直接通过
th:each遍历故事列表，后端返回一个包含数据的ModelAndView，整站能跑起来再说。部署时打成一个Jar包，内置Tomcat直接启动，演示不折腾。 - 已经学过Vue，想写得“现代”一些：用Vue 3 + Axios做前后端分离。后端提供JSON接口，前端用Vite工程开发。这条路视觉效果好，但你需要额外考虑跨域配置（用CORS或者Spring Boot的全局跨域配置）和前端构建产物的部署方式。
绝大多数毕设，我的态度是：别在界面上追求过度工程化。老师更看重功能的完整性和逻辑的正确性，Thymeleaf加上一个相对用心的CSS页面，完全足够支撑一场顺利的答辩。
3. 数据模型：先想清楚“故事”在数据库里长什么样
3.1 核心表结构清单
数据库是整个系统的地基，表设计的好坏直接决定后面写代码是顺畅还是痛苦。针对中国历史故事展播系统，我给出这么几张核心表：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| dynasty | 朝代 | id, name, period, intro, sort_order |
| story_category | 故事分类 | id, name, description |
| story | 故事主表 | id, title, cover_image, summary, content, dynasty_id, category_id, author, view_count, favorite_count, status, create_time, update_time |
| sys_user | 前端用户 | id, username, password, nickname, avatar, status, create_time |
| admin_user | 后台管理员 | id, username, password, role, create_time |
| user_favorite | 用户收藏 | id, user_id, story_id, create_time |
| comment | 故事评论 | id, story_id, user_id, content, create_time, status |
这里最核心的是story表。一个故事必须挂在朝代和分类下，形成按朝代数、按分类筛两条浏览路径。view_count和favorite_count两个计数字段是典型的“牺牲一点规范化换性能”的冗余设计——如果不冗余，你用的时候就得每次连表去统计，拿到首页排行列表时压力会明显更大。
3.2 主键策略与多表关联的取舍
主键我建议用数据库自增BIGINT，不要在这个项目里引入雪花ID。自增主键对MySQL的索引性能最友好，代码写起来也最直观。雪花ID是为分布式场景准备的，一个单机部署的毕设项目用它纯属给自己找不痛快。
外键关联上，我更推荐你保留逻辑外键而不是物理外键。也就是说，在story表里用dynasty_id字段维护与朝代的关系，但不在建表语句里写FOREIGN KEY约束。原因很现实：物理外键在删除数据、批量导入时会带来很多麻烦，而且MyBatis-Plus的分页插件和逻辑删除功能跟物理外键之间偶尔会有摩擦。实际开发中，外键关系由业务代码来保证，这也是业内主流的做法。
3.3 关于“删除”的约定
业务系统里的“删除”到底是真的数据行消失，还是仅仅标记不可见？这个抉择很关键。对故事内容这种有积累价值的资源，我用逻辑删除：在story表加一个deleted字段（0/1），查询时候自动过滤掉deleted=1的数据。MyBatis-Plus提供一个@TableLogic注解，加在字段上之后，删除操作会变成更新操作，查询自动追加过滤条件，非常省心。
朝代和分类同理。哪怕用户把某个分类下所有故事都删了，保留分类记录也方便后续恢复。逻辑删除的另一个好处是，你在论文里可以写“为了防止误操作导致数据不可恢复，系统采用逻辑删除策略”，这本身就是答辩时的一个加分话术。
3.4 初始化数据怎么准备
系统完成后你需要一批像样的数据去展示。历史故事素材从哪里来？现在很多公共资源网站可以找到白话文历史故事，你可以选50到100条，覆盖中国历史上主要朝代：先秦诸子故事、秦汉风云、三国演义经典片段、唐宋文人轶事、明清历史掌故。每条故事填写标题、封面图、简介、正文内容。正文可以分段存放，也可以用富文本格式，取决于你前端展示组件的方案。
数据准备好之后，写一个DataInitializer类，在项目启动时自动检测story表是否为空，为空则从本地SQL文件或数据字典里导入种子数据。这样项目克隆下来一跑，页面就有内容了，指导老师验收时第一印象会好很多。
4. 功能实现路径：从需求到可以演示的代码
4.1 前台“展播”怎么做才有体验感
“展播”这个词听起来高大上，落到功能上就是让用户打开网站后，能舒服地逛。我建议前台至少包含这五个区块：
- 首页轮播/推荐位：放3到5个精选故事封面，背后对应
story表里status=1且view_count较高的数据。 - 朝代导航：顶部按朝代展示入口，点击进入该朝代的故事列表页。
- 分类筛选：故事类型（如神话传说、名人轶事、战争谋略、诗词背后的故事）提供侧边栏Tab筛选。
- 故事列表：卡片式展示封面、标题、简介、浏览量、收藏量。
- 故事详情：标题、朝代、分类、发布时间、正文本体、评论区和收藏按钮。
实现上，故事列表接口我建议用MyBatis-Plus的条件构造器封装，在Service层提供一个支持多条件查询的方法：
public IPage<StoryVO> queryStoryPage(int page, int size, Long dynastyId, Long categoryId, String keyword) { LambdaQueryWrapper<Story> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Story::getStatus, 1); // 只展示已上架 wrapper.eq(dynastyId != null, Story::getDynastyId, dynastyId); wrapper.eq(categoryId != null, Story::getCategoryId, categoryId); wrapper.like(StringUtils.isNotBlank(keyword), Story::getTitle, keyword); wrapper.orderByDesc(Story::getViewCount); return storyMapper.selectPage(new Page<>(page, size), wrapper); }注意eq和like前加了条件判断，传进来为空时不参与查询。这种写法能避免你为每一种组合写一个Mapper方法，也是面试时会被问到“怎么处理多条件不确定查询”时的标准答案。
详情页每访问一次就把view_count加1。这里有两条路：简单做法是直接在Service里update一次，高并发下会有性能问题，但毕设完全不用担心；讲究一点的做法是先把浏览量从Redis里取并自增，再异步落库。如果你要写进简历，把Redis方案写出来会显得更有层次，但前提是你真的理解它。
4.2 管理端支撑文档：内容维护怎么做到高效
管理端是给“运营人员”用的，我建议只做最必要的功能：故事管理、分类管理、朝代管理、评论审核，外加一个管理员登录与仪表盘统计。
故事管理页要支持：新增、编辑、删除（逻辑删除）、上下架切换、按标题搜索。编辑故事的表单里，正文部分用一个富文本编辑器。富文本的选型我踩过不少坑，wangEditor是目前使用成本最低的选项，无需后端额外配置，纯前端集成。UEditor功能虽强但年久失修，集成过程容易出兼容性问题。编辑后的内容会以带HTML标签的字符串放进content字段，前端展示时用th:utext输出，或者Vue里用v-html。
仪表盘统计可以简单做：故事总数、朝代数量、分类数量、评论总数、近七日新增故事数。把这些数字用ECharts画两个柱状图/饼图放在后台首页，视觉上立刻显得完整。
4.3 用户注册登录：密码加密是最低底线
如果系统开放用户评论和收藏，就一定要有用户注册登录模块。密码存储，绝对不要用MD5直接存。MD5速度太快，现在GPU破解MD5已经是秒级的事情。项目里最低也要用BCryptPasswordEncoder，这也是Spring Security里默认推荐的加密器。
不引入Spring Security的话，你可以单独用spring-security-crypto包里的BCrypt实现：
// 注册时 String encodedPwd = new BCryptPasswordEncoder().encode(rawPassword); // 登录校验时 boolean matched = new BCryptPasswordEncoder().matches(rawPassword, encodedPwd);登录后的会话保持，简单的用Session就行，讲究一点用JWT发放Token。对毕设项目，我用Session方案写起来快，但如果你想在简历里突出“无状态认证”，JWT是值得一做的加分项。实现JWT也不复杂：引入jjwt依赖，登录成功后生成一个带用户名和过期时间的Token返回前端，前端在请求头里带上Authorization，后端加一个拦截器统一校验。
4.4 搜索与分页：模糊查询的正确姿势
站内搜索是一个容易被忽视但高频被问的功能。最直观的写法是老一代教程里泛滥的：
SELECT * FROM story WHERE title LIKE '%三%'这个写法在小数据量场景没问题，但你要知道它的性能问题。LIKE '%keyword%'由于前置模糊匹配，即使title字段加了普通索引也无法走索引扫描，全表扫描在所难免。毕设的演示数据量有限，这种写法可以接受，但答辩时最好能说出它的局限。
更优的方案是：如果只搜索标题，LIKE 'keyword%'可以用得上索引；如果搜索范围扩大到标题和简介，可以研究一下MySQL的全文索引FULLTEXT或者用简单的倒排策略。对本科毕设，我用个折中方案：搜索以标题和摘要（summary）为主，分页返回结果时加一个order by，用上查询的索引条件。有一个细节：分页和搜索同时存在时，一定要在查询里正确拼接LIMIT和OFFSET，最好用MyBatis-Plus的Page对象，不要自己在XML里拼字符串，否则很容易引入SQL注入风险。
5. 开发中真正卡住我半天以上的问题
5.1 中文乱码和时区问题：两个最隐蔽的配置陷阱
这类问题一度是Java Web开发者的老朋友。我自己的亲身经历是：数据库建表时忘记指定字符集，建出来默认可能是latin1，然后插入中文就乱码；还有一种情况是代码和连接串都正确，但Linux服务器系统字符集是POSIX，导致容器日志里看中文全是问号。
排查链路的顺序是这样：先用Navicat直接往表里插入一条中文数据，如果数据库里正常，说明问题出在应用侧；如果数据库里就乱了，检查建表语句有没有指定字符集。确认数据库没问题后，检查application.yml的JDBC连接串，重点看我前面写的那几个参数。最后再看代码侧的IO读写有没有指定编码。按这个顺序排查，比我当年盲目在代码里加编码转换快得多。
5.2 富文本存储带来的XSS风险
富文本编辑器让你“所见即所得”，但也让用户能往你的数据库里塞任意HTML。如果不做过滤，恶意脚本会以故事内容的名义在别的用户浏览器里执行，这就是典型的存储型XSS漏洞。
处理办法分两层。第一层：入库时做白名单校验，过滤掉script标签、onerror等属性；第二层：前端展示时尽量用纯文本模式渲染摘要，详情页如果必须展示富文本，也要在输出时对危险标签做转义。Java这边可以用jsoup库来净化HTML：
String safeHtml = Jsoup.clean(richContent, Safelist.relaxed());relaxed()允许常用的排版标签，但会过滤掉脚本和事件属性，对故事正文展示完全够用。
5.3 删除朝代后，故事去哪了
这个业务关联问题是我在联调时发现的一个设计缺陷。最初我的朝代管理页只提供了一个删除按钮，结果运营一点删除，该朝代下所有故事在前台全部显示不出来。表面看功能“正常”，但其实故事数据变成了孤儿数据，而且因为故事表外键不被强制约束，删完之后你想查“哪个故事属于已删除的朝代”还得用子查询找。
正确的做法是把删除分成两种情况：一是朝代下还有故事时，后端直接返回提示“该朝代下存在故事，请先转移或删除故事”；二是提供“朝代合并”或者“批量迁移”功能。无论哪种，核心原则是：主数据删除前必须先检查关联数据。这个逻辑虽然简单，但它是很多初级开发者在设计接口时容易漏掉的一环。
5.4 图片上传：本地存储路径与部署环境打架
开发时图片上传到本地磁盘一个临时目录，点击页面图片正常显示；把项目打成Jar放到服务器上一跑，发现上传的图片全部404。原因很朴实：图片以绝对物理路径存在你开发机的某个文件夹里，部署到服务器后路径不存在了。
我给这个问题的标准解是：单独配置一个upload.path属性，上传接口把文件写入该目录，同时生成一个/images/**的静态资源映射指向这个外部目录。Spring Boot配置如下：
@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${upload.path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceLocations("file:" + uploadPath + "/"); } }这样开发时配置本地目录，部署时配置服务器目录，上传和展示都走/images/xxx.jpg的相对URL，代码层面不需要改动。图片本身的命名我建议用UUID + 扩展名，避免中文文件名和重名问题。
6. 从“运行成功”到“高分答辩”：演示与扩展的那几步
6.1 演示流程请站在用户视角，而不是开发者视角
许多学生最后答辩翻车，不是系统没做完，而是演示顺序一塌糊涂。一上来就打开数据库给老师看表结构，或者一上来就登录管理后台新增故事，老师看不到系统的全貌，自然难以产生好感。
我的建议是固定一条演示主线：从首页进入，走一遍“用户逛网站”的完整旅程——先看首页推荐和朝代导航，点击进入某个朝代的故事列表，筛选一个分类，打开一个故事详情页，然后展示评论和收藏功能；再切换到登录状态，演示收藏后的“我的收藏”列表；最后才进入管理后台，演示新增故事、上传封面、数据统计面板。这条线走下来，老师对功能结构的理解是清晰且直观的，答辩PPT也可以按这个顺序组织。
6.2 简历上怎么写这个项目
如果你以后打算找Java开发实习或工作，这个项目的简历写法很有讲究。项目描述不要只写“实现了故事的增删改查”，要写清楚技术挑战和解决方案。我建议提炼成三四条：
- 基于Spring Boot + MyBatis-Plus + MySQL实现历史故事内容管理与展播平台，包含用户端浏览检索与管理端内容维护双端功能。
- 设计朝代、分类、故事、用户、评论、收藏等多张业务表，通过逻辑删除与冗余计数字段在数据可靠性与查询性能之间取得平衡。
- 使用Bean Validation实现参数校验，通过统一异常处理与自定义响应体封装接口规范，集成BCrypt密码加密与登录拦截。
- 引入富文本编辑器支撑故事内容录入，并对HTML内容做XSS白名单过滤；配置静态资源外部映射以支持图片上传与访问。
面试官看到这样的描述，至少能判断你有能力独立完成一个完整业务闭环的后台管理系统。接下来他追问的任何问题，你在本项目中都能给出实际案例，这就比简历上堆一堆“精通”要有说服力得多。
6.3 还能扩展哪些实用模块
如果时间和精力允许，这个系统还有几个自然的扩展方向。
一是推荐模块：根据用户收藏的历史记录，在故事详情页下方推荐同朝代或同分类的其他故事，用简单的“基于内容的推荐”就可以实现，不需要机器学习。
二是历史人物关系图谱：在故事正文中提取出现的历史人物，建立人物表和人物关系表，用ECharts的关系图在一张页面上展示人物关联，这在文史类系统里是很加分的可视化亮点。
三是故事音频朗读：调用现成的TTS服务把故事正文转成音频，在详情页加一个播放器按钮。这个功能工作量不大，但演示效果非常好，尤其契合“展播”这个题目的字面含义。
我个人在实际操作中最推荐的还是先做点评模块。评论区天然涉及用户权限、数据校验、排序展示、敏感词过滤这些知识点，把评论区做干净了，项目完整度会肉眼可见地提升一个档位。
最后再分享一个小技巧：整套系统做完之后，把项目代码提交到代码托管平台，同时在README里写好启动步骤、数据库脚本和功能截图。不要小看这件事——指导老师检查工作量时首先关注的是项目能不能一键跑起来，你把这些都梳理清楚，省下的是双方的时间，留下的印象分却多出一大截。
