企业官网建设流程全解析

写这个题目的经验，我其实积攒了不少。每年到毕设季，总会有学生拿着"基于SpringBoot+大数据技术的诗词信息系统"这类题目来问我，说看了半天不知道从哪下手，担心大数据组件太重跑不起来，又怕业务系统写得太浅撑不起"大数据"这三个字。今天就把我从选题、架构到编码、排错、答辩的完整思路捋一遍，给准备做类似题目的同学一个可以直接参考的路线。

这个项目的核心词是"基于SpringBoot+大数据技术"，按毕设标准看，它属于典型的"业务系统+数据分析"复合型题目：SpringBoot负责网站业务，Hadoop/Spark这类组件负责数据采集、清洗、分析和可视化。诗词这个领域选得其实很聪明——数据公开、结构丰富、分析维度多，而且做出来的可视化大屏很有辨识度，评委基本都会多看一眼。

1. 为什么我推荐把"诗词信息系统"当大数据毕设选题

1.1 大数据毕设的常见误区

很多学生对"大数据毕设"的第一反应是要搭一个几十台机器的集群，不然不好意思叫大数据。这是个认知偏差。本科阶段的毕设，评委真正考察的是你有没有走通"数据采集—数据清洗—分布式存储—离线分析—可视化展示"这条完整链路，而不是看你的节点数量。

我见过不少学生把时间全花在搭环境上，三台虚拟机起Hadoop集群，内存16G的笔记本跑得风扇狂转，结果业务系统没怎么写，最后答辩时能展示的东西很少。反过来，有人用单机伪分布式模式，配合Spark本地模式，把重点放在"分析出了什么结论"和"系统能不能用"上，反而拿了高分。

所以做这类题目第一件事是摆正心态：大数据毕设的关键词是"链路完整"和"分析有价值"，不是"集群规模大"。

1.2 诗词数据为什么适合做分析

诗词信息系统的数据基础，天然适合大数据技术发挥。全唐诗收录了近5万首，宋词也有两万多首，加上元曲、诗经、乐府等，公开可获取的诗词数据轻松超过10万条。这个量级用MySQL直接查询也能跑，但一旦涉及全量词频统计、情感分析、风格聚类这类计算，传统的单机SQL处理起来就很吃力了，这正是Spark可以登场的地方。

更重要的是，每首诗词都带有丰富的结构化字段：朝代、作者、体裁、词牌、标题、正文。这就意味着你可以做历朝历代的诗词数量趋势分析，可以做高频意象统计（"月""风""酒""花"这些字在哪个朝代出现得最多），可以做李白和杜甫的风格对比，甚至可以做基于情感词典的诗词情感倾向分析。这些分析结果随便拿出几个，都能让大屏内容丰富起来，论文的第七章"系统测试"也有的写。

1.3 选这个题目的实际性价比

和做电商数据分析、舆情分析这类题目相比，诗词系统的优势在于数据不用花时间造，也基本不涉及隐私合规问题。你不需要模拟用户点击流，不需要从零伪造订单数据，网上的公开诗词数据集拿过来就可以用。

对比一下：电商数据分析的难点在于数据造假痕迹重、分析维度雷同；舆情分析则需要持续采集实时数据，做起来很累。诗词系统则是"数据现成、分析有趣、可视化漂亮"，属于性价比很高的选择。

当然它也有短板——业务系统如果只做单纯的诗词浏览和搜索，功能上会显得单薄。所以我的建议是无论如何都要加上"用户收藏+笔记批注"这类交互功能，让系统不是只有一个展示壳子。

2. 整体架构设计：SpringBoot 与大数据组件的分工边界

2.1 技术选型清单与职责划分

整个系统我推荐的分层方式是：SpringBoot 管业务，Hadoop 体系管数据，MySQL 既存业务数据也存分析结果，ECharts 做可视化。具体分工如下表：

有一个细节值得注意：SpringBoot 和 Spark 在职责上要严格分开。SpringBoot 只读取 MySQL 里的分析结果，不直接去读 HDFS，也不在业务请求里跑 Spark 任务。这样做的原因很简单——Spark 任务的启动和计算耗时通常在秒级甚至分钟级，如果每次用户请求都触发一次 Spark Job，系统的并发能力会非常差，而且业务链路会被拖死。

2.2 数据流向：一条链路串起所有组件

我习惯把整个系统理解成一条单向数据管道：

1. 爬虫（或开源数据集）拿到的原始 JSON/CSV 先做一轮清洗和结构化；
2. 清洗后的数据存两份：一份进 HDFS 作为大数据分析的原始数据，一份解析后写入 MySQL 作为业务系统的诗词表；
3. Spark 定时任务读取 HDFS 数据，执行统计分析，把结果写回 MySQL 的统计结果表；
4. SpringBoot 提供统计查询接口，从 MySQL 读取分析结果返回给前端；
5. ECharts 大屏通过接口拿到数据，渲染成图表。

这套流程最大的好处是边界清晰：每个组件只干自己擅长的事。MySQL 管事务，HDFS 管大批量文件存储，Spark 管分布式计算，SpringBoot 管接口和业务逻辑。哪个环节出了问题，排查范围都很小。

2.3 为什么保留 MySQL 而不是全部用 Hive 存

这是个很实际的问题。既然用了大数据组件，为什么不索性连业务数据都放进 Hive 或 HBase？

毕设场景下我强烈不建议这么做。原因是你的业务系统里有大量高频、小粒度的操作——用户登录、查询一首诗、保存一条笔记，这些操作对响应时间要求在毫秒级。Hive 底层是 MapReduce，查询延迟很高，根本不适合承担在线业务；HBase 虽然查询快但需要额外的集群资源和运维成本。MySQL 是最稳妥的选择，而且 MyBatis-Plus 做 CRUD 的效率远高于操作 Hive。

"大数据"体现在分析环节就好了，不要为了用技术而用技术，这个原则在答辩时也可以明确讲给评委听。

3. 数据采集与清洗：从爬取到入库的完整链路

3.1 数据来源：先找开源数据集，再决定要不要爬虫

我建议优先使用 GitHub 上现成的开源中文诗词数据集，比如 chinese-poetry 这类项目，里面已经按朝代、作者整理好了 JSON 格式的诗词，下载下来就能用。这样做至少有三个好处：

• 数据质量有保障，字段齐全，不需要费太多功夫去解析乱七八糟的 HTML；
• 不用承担爬虫可能带来的访问频率、内容版权等方面的麻烦；
• 节省下来的时间可以用到更有价值的功能开发和分析上。

如果导师要求必须体现"数据采集"过程，或者你确实想展示爬虫能力，那就自己写一个爬虫作为补充。技术栈有两种选择：纯 Java 用 HttpClient + Jsoup，或者用 Python 的 Requests + BeautifulSoup。前者和项目主体语言统一，后者更简洁。考虑到数据清洗和后续处理大概率会用到 Python 的 jieba 分词，我建议采集环节也直接用 Python，一条链走通。

3.2 爬虫采集的合理姿势

爬虫代码本身不复杂，关键是要克制。我见过有人用高并发多线程去爬一个静态网站，结果IP被封，数据没拿到，还浪费时间。正确的做法是控制频率，加适当延时，设置合理的 User-Agent，先爬少量页面验证解析逻辑，再批量执行。

一个简单的示例逻辑如下：

import requests from bs4 import BeautifulSoup import json import time base_url = "https://example.com/poems?page=" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" } poems = [] for page in range(1, 101): resp = requests.get(base_url + str(page), headers=headers, timeout=10) soup = BeautifulSoup(resp.text, "html.parser") for item in soup.select(".poem-item"): poems.append({ "title": item.select_one(".title").text.strip(), "author": item.select_one(".author").text.strip(), "dynasty": item.select_one(".dynasty").text.strip(), "content": item.select_one(".content").text.strip() }) time.sleep(1) with open("poems_raw.json", "w", encoding="utf-8") as f: json.dump(poems, f, ensure_ascii=False, indent=2)

这里只是演示结构，实际网站的选择器要根据页面结构调整。数据落地之后，一定要抽样检查几个样本，确认没有乱码、没有解析错位，再进入清洗环节。

3.3 清洗规则：去重、补全、统一编码

原始数据不管来自开源项目还是爬虫，都不可能直接入 HDFS，必须先清洗。我的清洗规则一般包含以下几项：

• 去空白和不可见字符：正文中混入的换行、空格要统一处理，比如把连续多个空格合并成一个；
• 繁体转简体：很多数据源是繁体字，为了后续检索和分析统一，需要做转换，Python 的 opencc 库可以很好地完成这件事；
• 去重：基于"标题+作者+内容哈希"做全量去重，避免同一首诗在数据源里出现两次；
• 字段结构化：统一朝代、作者、体裁字段的格式，比如把"唐代""唐""唐朝"统一成"唐"；
• 异常值过滤：正文过短（少于10个字）的记录直接丢弃，这类多半是解析错误产生的碎片。

处理完的干净数据，我建议每行一条 JSON 的形式存储，因为后续 Spark 读取 JSON 比 CSV 更灵活，不用关心字段顺序。示例格式如下：

{"title":"静夜思","author":"李白","dynasty":"唐","genre":"五言绝句","content":"床前明月光，疑是地上霜。举头望明月，低头思故乡。"}

清洗代码最好和采集代码分开独立成脚本，在论文里也可以单独作为一个小节描述。

3.4 中文分词：分析的地基

如果不做分词，Spark 做词频统计时就只能按字切分，像"床前明月光"会被切成单个汉字，统计出来的结果全是"前""明""月"这种单字，分析价值不大。所以清洗之后要加一道分词。

Java 生态推荐 HanLP，Python 生态推荐 jieba。两者的词频统计效果都不错。我的习惯是用 HanLP 的标准分词模式，再加上自己维护的停用词表，把"之""乎""者""也""啊""呀"这类虚词和标点过滤掉，保留有实际意义的意象词。

分词后的数据可以增加一个字段seg_content，这样后续 Spark 做词频统计时连分词的步骤都省了，直接按空格 split 就行。这也是一个典型的"把计算前移到预处理环节"的思路，在大数据工程里很常见。

4. 业务系统搭建：SpringBoot 核心功能模块拆解

4.1 业务模块规划与数据库设计

业务模块我建议围绕四条主线设计：用户、诗词、交互、统计。不要贪多，功能在精不在多，但一定要保证每个功能是完整闭环的。

推荐的核心表结构如下：

• t_user：用户表，字段包括 id、username、password（BCrypt加密）、nickname、avatar、create_time；
• t_poem：诗词表，字段包括 id、title、author、dynasty、genre、content、seg_content、create_time；
• t_author：作者表，字段包括 id、name、dynasty、description、poem_count；
• t_favorite：收藏表，字段包括 id、user_id、poem_id、create_time；
• t_note：笔记表，字段包括 id、user_id、poem_id、content、create_time；
• t_stat_result：统计结果表，字段包括 id、stat_type、stat_name、stat_value、extra_json、update_time。

其中 t_stat_result 这张表是用来承接 Spark 分析结果的。它设计得很灵活，stat_type表示分析类型（朝代分布、作者Top10、词频Top50等），stat_name是分析对象名称（朝代或作者名），stat_value是对应的数值，extra_json可以存额外的数据（比如词云图需要的词列表）。这样表结构不需要为每种分析单独建表，Spark 写入时只要拼 JSON 就可以了。

4.2 认证授权与公共能力

用户模块推荐直接使用 JWT 做无状态认证，Spring Security 能用但配置成本稍高，如果是为了"简洁够用"，用一个自定义拦截器加 JWT 工具类就够了。注册时密码用 BCrypt 加密，登录成功后返回 token，前端后续请求在请求头里带上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 ")) { token = token.substring(7); if (JwtUtil.verify(token)) { return true; } } response.setStatus(401); return false; } }

这样处理的好处是代码量少、逻辑清晰，论文里也好写。实际使用中记得在 WebMvcConfigurer 里注册拦截器，并放行登录注册接口、诗词列表和详情接口——毕竟游客浏览诗词内容是合理的需求。

4.3 搜索与筛选功能的实现层次

诗词检索是系统的门面，至少要支持三种方式：关键字搜索（匹配标题或正文）、按朝代筛选、按作者筛选。用 MyBatis-Plus 的 LambdaQueryWrapper +like条件就能覆盖。

如果想让这个模块更有含金量，可以引入 Elasticsearch，把诗词数据同步到 ES，利用 IK 分词器做中文分词检索，这样可以支持"输入一句词就能搜到出处"的体验。不过 ES 的加入会显著增加部署复杂度，对资源有限的毕设环境确实是个负担，我一般是把它作为论文的"扩展与展望"章节来写，而不是要求在系统里必须落地。

4.4 一个能加分的"每日推荐"模块

每日推荐是那种成本低但看起来高级的功能。实现思路很简单：基于用户的收藏记录计算朝代偏好。比如用户收藏了10首诗，其中6首是唐代的，那系统每天推荐诗词时就优先从唐代诗词里随机选取，再混入一些其他朝代的高评分诗词。

数据量小的时候直接写 SQL 就能算，不需要写协同过滤算法，但在论文里可以把它包装成一个"基于用户行为的简单推荐策略"，并且注明未来可以替换为基于 Spark ALS 的协同过滤推荐——这样既脚踏实地，又体现了对大数据算法的理解。

5. 数据分析引擎：Spark 与 Hive 如何产出有价值的分析结果

5.1 分析维度怎么规划最出效果

分析维度的规划决定了论文的价值天花板。我推荐从浅到深安排四个分析任务，保证既有统计类结果，又有算法类结果：

• 历代诗词数量趋势：按朝代聚合，输出柱状图，直观反映唐诗宋词的繁荣周期；
• 高频词与意象分析：统计全量诗词分词后出现次数最多的 Top50 词汇，用词云展示；
• 作者创作风格对比：选取李白、杜甫等代表性诗人，统计他们作品中的高频词和平均句长，做对比分析；
• 诗词情感倾向分析：基于情感词典统计每首诗的正负情感分数，再按作者聚合，判断不同诗人的情感基调。

其中第四个维度最有"研究感"，但情感词典的质量直接影响结论，所以如果搞不到一个足够大的中文情感词典，我建议退一步，做"意象词统计"而不是"情感分析"，这样结论更容易自圆其说。

5.2 Spark 离线统计任务示例

用 Java 写 Spark 任务可能显得有些啰嗦，但既然后端主体是 SpringBoot，全栈 Java 对毕设来说统一性更好、答辩讲解也省事。下面给一个从 HDFS 读取诗词数据并统计词频 TopN 的完整示例：

import org.apache.spark.sql.Dataset; import org.apache.spark.sql.Row; import org.apache.spark.sql.SparkSession; import static org.apache.spark.sql.functions.*; public class PoetryWordCount { public static void main(String[] args) { SparkSession spark = SparkSession.builder() .appName("PoetryWordCount") .master("local[*]") .config("spark.sql.shuffle.partitions", "4") .getOrCreate(); Dataset<Row> df = spark.read().json("hdfs://localhost:9000/data/poetry/clean_poems.json"); df.createOrReplaceTempView("poems"); Dataset<Row> words = spark.sql( "SELECT word, COUNT(*) AS cnt FROM (" + " SELECT explode(split(seg_content, ' ')) AS word FROM poems" + ") t " + "WHERE length(word) > 1 " + "GROUP BY word " + "ORDER BY cnt DESC " + "LIMIT 50" ); words.coalesce(1) .write() .mode("overwrite") .option("driver", "com.mysql.cj.jdbc.Driver") .option("url", "jdbc:mysql://localhost:3306/poetry_db?useUnicode=true&characterEncoding=utf8") .option("user", "root") .option("password", "123456") .option("dbtable", "t_stat_result") .format("jdbc") .save(); spark.stop(); } }

这个任务用到了 Spark SQL 的explode和split函数，从清洗好的seg_content字段中切分出单词并统计，逻辑简单但完整体现了"读取分布式存储—执行分布式计算—结果写回数据库"的链路。如果需要把多个统计维度都跑一遍，可以在同一个 SparkSession 里注册多个临时表，最后统一写结果。

5.3 Hive SQL 作为补充

如果环境里装了 Hive，也可以把清洗后的数据建一个外部表，这样就能用纯 SQL 做聚合统计。比如统计历代作品数量：

CREATE EXTERNAL TABLE IF NOT EXISTS poems ( title STRING, author STRING, dynasty STRING, genre STRING, content STRING, seg_content STRING ) ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION '/data/poetry/clean_poems'; SELECT dynasty, COUNT(*) AS cnt FROM poems GROUP BY dynasty ORDER BY cnt DESC;

注意 Hive 的 JSON SerDe 对数据格式有要求，文件必须是每行一个 JSON 对象，不能是 JSON 数组，这也是我在清洗环节强调"每行一条 JSON"的原因。

5.4 分析任务的调度策略

Spark 任务不需要常驻系统里，我建议采用定时调度方式：每天凌晨1点由 Crontab 或 SpringBoot 的@Scheduled触发一次全量分析，结果覆盖写入 MySQL 的统计结果表。毕设场景数据量不大，全量分析完全跑得动，不需要设计增量分析的复杂逻辑。

一个具体的 Spark 提交命令模板如下：

spark-submit \ --class com.example.PoetryAnalysisJob \ --master local[4] \ --driver-memory 2g \ poetry-analysis-1.0.jar

local[4]表示本地模式用4个线程模拟并行，--driver-memory 2g控制驱动程序内存，这两个参数在环境差的机器上尤其重要。

6. 可视化大屏与后端联调：从 Spark 结果到 ECharts 大屏

6.1 大屏的布局与图表规划

可视化大屏是整个项目最直观的成果展示，也是答辩时最容易吸引评委注意力的部分。布局上我建议参考常见的"左中右"结构：

• 顶部：系统标题 + 数据更新时间 + 核心指标卡片（诗词总数、作者总数、朝代数量、收藏总数）；
• 左侧：诗人作品 Top 10 柱状图、词牌名 Top 10；
• 中间：历代诗词数量趋势折线图，这是全场视觉焦点；
• 右侧：高频词汇词云、各朝代作品占比饼图。

做之前先画一个简单的布局草图，确定每个图表的位置和尺寸，再去写代码，可以避免反复返工。

6.2 SpringBoot 统计接口设计

大屏的数据来自统计结果表，SpringBoot 需要提供对应的查询接口。我一般会设计一个聚合接口，一次请求返回大屏所需的全部数据，减少前端请求次数：

@GetMapping("/api/dashboard/overview") public Result<DashboardVO> overview() { DashboardVO vo = new DashboardVO(); vo.setPoemCount(poemMapper.selectCount(null)); vo.setAuthorCount(authorMapper.selectCount(null)); vo.setDynastyTrend(statService.queryDynastyTrend()); vo.setTopAuthors(statService.queryTopAuthors(10)); vo.setTopWords(statService.queryTopWords(50)); vo.setDynastyPie(statService.queryDynastyPie()); vo.setUpdateTime(statService.queryLastUpdateTime()); return Result.success(vo); }

这里queryTopWords返回的数据需要包含词名和出现次数，格式上要和 ECharts 词云组件的数据结构对齐。

6.3 ECharts 渲染与数据刷新

ECharts 的代码不在多，关键是数据拼装正确。以词云为例，数据格式是[{ "name": "月", "value": 2314 }, ...]，ECharts 词云插件按 name 显示词、按 value 决定字号。有了接口之后，前端只需要用 Axios 拉数据再 setOption 即可。

数据刷新我推荐用轮询，每30秒请求一次接口。对大屏来说这已经足够实时，而且实现起来比 WebSocket 简单得多。如果要加分，可以在后端用 Redis 缓存统计结果，并给前端返回一个"上次更新时间"，让用户看到数据不是静态的。

6.4 联调阶段最容易忽略的两个问题

跨域问题。SpringBoot 默认禁止跨域请求，大屏页面如果和接口不在同端口（比如前端 Vue 跑在 8081，后端跑在 8080），必须配置跨域过滤器。一般实现WebMvcConfigurer的addCorsMappings方法即可解决。

数据字段命名问题。Java 后端习惯用驼峰命名（dynastyTrend），前端 ECharts 可能习惯下划线（dynasty_trend），如果两边没对齐，图表就是空白的。最省事的办法是在后端 DTO 统一用驼峰返回，前端照单全收，不要在联调阶段来回改字段名。

7. 毕设排错实录：环境与代码层面最常遇到的问题

7.1 Spark 与 SpringBoot 的版本冲突

这是新手最容易踩的坑。SpringBoot 3.x 默认基于 JDK 17，而 Spark 3.2 之前的版本对 JDK 17 的支持并不好，运行时经常出现Unsupported class file major version的错误。我的建议是：SpringBoot 用 2.7.x，JDK 用 8 或 11，Spark 用 3.3.x，Hadoop 用 3.3.x。这套组合我实测下来最稳，网上的教程也最多。

如果你非要上 SpringBoot 3.x，那就要注意 Spark 版本必须 3.3 以上，且还需要处理很多兼容性问题，对一个赶毕业设计的学生来说没必要。

7.2 Windows 环境下 Hadoop 的 winutils 报错

很多同学在 Windows 上跑 Spark 程序，启动时会报类似Could not locate executable null\bin\winutils.exe in the Hadoop binaries的错误。这是因为 Hadoop 的本地库没有 Windows 版本。

解决办法：去 GitHub 下载对应版本的 winutils 和 hadoop.dll，放到一个文件夹里，然后配置系统环境变量HADOOP_HOME指向该文件夹，并把%HADOOP_HOME%\bin加到PATH里。配置好后重启 IDE，问题就消失了。

7.3 中文乱码的三种来源

中文乱码是诗词系统里最容易出现的问题，而且可能出现在三个环节：数据文件编码、数据库连接、前端显示。

数据文件统一用 UTF-8 编码保存，清洗脚本里写入文件时显式指定encoding="utf-8"；JDBC 连接 URL 加上characterEncoding=utf8参数；前端 HTML 页面设置<meta charset="UTF-8">。这三处都做了，乱码基本不会出现。

还有一个隐蔽的点：Spark 读取 JSON 时如果数据文件带 BOM 头，会影响字段解析，导致读出来全是 null。处理办法是清洗阶段用不带 BOM 的 UTF-8 写文件。

7.4 Spark 任务频繁 OOM 的调参思路

本地模式下 Spark 任务 OOM，大多数情况不是集群瓶颈，而是默认参数不合适。常见的调整方向有三个：

• 减少并行度：spark.sql.shuffle.partitions默认200，对数据量不大的任务来说太多了，改成4或8；
• 限制 Driver 内存：--driver-memory 2g，根据自己的机器内存情况调整，不要贪大；
• 用 Kryo 序列化：在 SparkConf 里设置spark.serializer为org.apache.spark.serializer.KryoSerializer，能减少内存占用。

另外，数据量不大的情况下就用local[2]或者local[4]，不要用local[*]，后者会把笔记本所有 CPU 核心都拿去跑任务，容易把机器弄死。

7.5 远程调试与交付环境准备

标题里提到的"远程调试"是毕设交付阶段很现实的需求。导师不一定在你的电脑上看演示，所以交付前一定要把项目环境整理成"一键可运行"的状态。我一般会做三件事：

• 写一个清淅的 README 启动文档，包含 JDK、Maven、MySQL、Hadoop/Spark 的安装版本、配置步骤、启动顺序、账号密码；
• 提供脚本化的启动工具，比如start_all.bat或start_all.sh，依次启动 MySQL、Hadoop、Spark 任务和 SpringBoot 应用，避免手工敲一堆命令；
• 远程调试时，确认 SpringBoot 端口和数据库端口在防火墙里放行，如果用的是云服务器，还要注意安全组规则。

远程调试最怕的是"本地能跑，远程一跑就崩"。崩的原因大半出在路径和版本差异上：本地写死的绝对路径、本地独有的环境变量、Hadoop 版本不一致等。所以我建议把 HDFS 的路径尽量配置在配置文件里，不要硬编码在 Java 代码中。

8. 论文写作与答辩演示的实战建议

8.1 论文结构怎么搭

这类题目的论文结构其实很成熟，按学校给的模板走就行，核心是内容的颗粒度。我特别想提醒的是第三章"需求分析"和第四章"系统设计"不要写得像流水账，每个功能模块的设计要讲清楚"为什么这么设计"。

比如搜索功能，你不仅要说"用户输入关键词可以搜索诗词"，还要说明"搜索采用 MySQL LIKE 匹配，考虑到数据量在十万级，这个方案足够；如果数据量达到百万级，可以引入 Elasticsearch 做分词检索"。这种写法就是典型的"体现思考深度"，评委很吃这一套。

8.2 演示顺序的编排逻辑

答辩演示环节一般只有五到十分钟，顺序安排很关键。我的建议是：

1. 先用一分钟展示系统整体界面，让评委建立直观印象；
2. 接着走一遍核心业务闭环：注册→登录→搜索诗词→查看详情→收藏→写笔记；
3. 然后切换到大屏页面，说明"这些图表的数据全来自 Spark 对 HDFS 上十万条诗词数据的离线计算"；
4. 最后展示爬虫脚本和 Spark 任务的运行日志，证明数据链路的真实性。

注意第4步可以只展示代码和日志，不用现场跑，因为现场跑 Spark 任务有可能因为环境问题翻车。

8.3 高频答辩问题与应答策略

我把评委针对这类题目最常问的问题整理了一下，每个都给出参考应答方向，供大家准备答辩时参考：

这些问题回答的关键是"诚实但不露怯"：遇到没做的功能就说是"后续展望"，不要现场编造。

8.4 那些论文里可以写但工作量不大的加分点

如果还有多余的时间和精力，下面这些点可以只写论文不做系统，也可以作为"展望"章节的内容，效果都不错：

• 引入 Elasticsearch 做全文检索引擎，替换数据库模糊匹配；
• 引入 Kafka 做实时诗词数据流的采集管道；
• 引入 Flink 做流式计算，实现"用户访问热度实时排行"；
• 引入协同过滤推荐算法，基于用户收藏行为做个性化诗词推荐。

这几点写进第九章"总结与展望"里，评委一看就知道你对技术生态有整体认识，而不是只会照抄代码。

最后分享一点我的真实体会。带过这么多届毕设，我发现"诗词信息系统"这个题目最大的价值不是代码量有多少，而是它把 SpringBoot 和大数据技术串成了一个完整故事：数据从哪来、怎么洗、怎么存、怎么算、怎么展示，每一环都在做实实在在的工作，每一环又都能在论文里找到对应章节。做完这个项目，你收获的不仅是一个能通过的毕设，更是一条可以讲清楚的大数据处理链路。如果你正在准备这个题目，把心思花在"数据链路的完整性"上，而不是纠结界面美不美观，方向就对了。