做这个“基于JavaSSMFlask的古诗词展演系统”项目之前我一直在想一个问题市面上的诗词网站这么多无非是列表加详情页凭什么你的东西值得被多看一眼后来我意识到题目里的“展演”两个字才是真正的题眼——在新媒体视域下它要求的不是把诗词存进数据库再查出来而是要让诗词“活”在屏幕上让用户有画面感、有参与感、有分享的冲动。所以我最终把系统拆成两条技术线JavaSSM负责用户、权限、诗词资源管理这些重业务Flask服务单独处理词频统计、词云生成、相似推荐这类轻量但偏算法的活两边通过HTTP接口协作。整套项目做完源码、调试文档、讲解视频、论文材料加起来大概是两个多月的业余工作量。这篇文章我就把从架构选型到落地的完整过程拆开讲适合正在做JavaWeb课程设计或毕业设计的人参考也适合想了解双技术栈项目如何协同的开发者。1. 项目整体设计与技术选型解析1.1 新媒体视域下“展演”到底意味着什么我见过很多同名项目叫“古诗词管理系统”“诗词检索网站”点进去一看就是表格加表单本质上还是CRUD。但“展演”这个词放在新媒体语境下含义要重得多。新媒体时代用户的注意力是碎片化的一条内容如果不能在3秒内抓住人基本就划走了。所以诗词展演不能只是把文字堆在页面上它需要有视觉节奏、有交互触点、有传播属性。我当时给自己定了三个关键词看见、听懂、参与。“看见”指通过水墨风UI、动态词云、时间轴图谱让诗词有画面感“听懂”指引入朗诵音频、背景音乐让诗词有声音“参与”指用收藏、点赞、推荐、分享功能让用户产生动作。这三个词直接决定了功能清单和页面设计的优先级。换句话说技术实现本身并不难难的是把“展演”的产品逻辑想清楚再落到具体的模块上。这套系统的目标用户也分两类前台是普通用户——可能是学生、教师、传统文化爱好者后台是内容运营者——需要管理诗词内容、审核用户、配置展演素材。两类角色的需求完全不同所以前后台在交互设计和权限控制上必须分开设计这也是我选择SSM做后台管理强项的核心理由。1.2 为什么选 Java SSM Flask 这个组合选型这件事很多人纠结了很久我也纠结过。最开始想过全用Spring Boot后来又想过全用Django最后定为JavaSSMFlask理由是“让每种技术干它最擅长的事”。SSM这套组合也就是Spring、SpringMVC、MyBatis在国内Java Web开发里的地位不用多说。Spring管对象和事务SpringMVC管请求路由MyBatis管SQL和ORM。它的优势在于业务逻辑清晰、事务控制严密、权限体系成熟特别适合系统里有明确角色划分和复杂数据关系的场景比如我这套系统里的用户管理、诗词分类管理、评论审核。用SSM写这些重业务代码结构很稳后期调试也方便。Flask则补上了SSM的短板。Java处理中文分词、词频统计、词云生成这些文本分析任务不是不能做而是代码量大、效率低。Python这边有现成的jieba分词、wordcloud、matplotlib几行代码就能出图出数据。我用Flask单独架了一个轻量服务专门对外提供两个能力一是根据用户浏览记录返回相似诗词推荐二是动态生成词云图片供前端展示。这样SSM不需要引入一堆笨重的算法库Flask也不需要跟数据库和权限体系纠缠两边各司其职通过JSON通信耦合度很低。从学习角度看这个组合还有一个隐藏好处一份项目同时覆盖了Java和Python两大技术栈对课程设计、毕业设计甚至找工作面试都是加分项。面试官问“你了解微服务吗”你可以说在项目里实践过服务拆分与HTTP联调问“你会Python吗”你也能拿出实际案例。1.3 功能全景与最终交付物功能上我拆成三条线。第一条线是前台用户端包括诗词浏览、按朝代/作者/标签筛选、全文关键词搜索、诗词详情页含译文、注释、赏析、收藏与点赞、朗诵音频播放。第二条线是后台管理端包括管理员登录、诗词CRUD、用户管理、评论审核、统计报表热门诗人Top10、朝代分布、访问量趋势。第三条线是Flask服务端包括词频统计接口、相似诗词推荐接口、词云图生成接口。交付物方面除了可运行的源码我还整理了一套完整的项目文档设计文档说明系统架构和数据库设计调试文档记录了每个模块联调时踩过的坑操作手册给非技术用户看教他们怎么启动项目、导入数据库、配置环境。此外配了一段讲解视频按模块过代码。这些东西对毕业设计答辩尤其重要因为答辩老师不只看代码跑不跑得起来还要看你的文档习惯和逻辑表达能力。2. SSM 主后端三件套的分工与实现逻辑2.1 Spring 容器与事务控制在项目里的实际用法SSM项目里Spring的核心价值就是IoC和AOP。IoC把对象创建和依赖关系交给容器管理好处是代码解耦Service层不用自己new MapperController也不用自己new Service。我用注解方式管理Bean启动时扫描com.portal.*包所有Service、Repository、Controller自动注册。事务控制这块容易被忽略但诗词系统的收藏、点赞、评论这些操作都涉及多表更新不加事务很容易出数据不一致。比如用户点赞时既要往like表插记录又要更新poem表的like_count字段两步操作必须在一件事务里完成。我直接在Service方法上标注Transactional并设置回滚规则。需要说明的是Transactional默认只回滚运行时异常如果在方法里catch住了异常并吞掉事务是不会回滚的这个细节很多人栽过跟头。Spring的AOP我还用在日志记录上。写了一个切面类拦截Controller层的所有请求记录访问时间、参数、返回状态。这个东西在联调和排错时特别好用前端调接口报错了后端日志里能看完整请求链路。2.2 SpringMVC 的请求分发与参数绑定细节SpringMVC的核心是前端控制器DispatcherServlet所有请求先经过它再由HandlerMapping找到对应的Controller方法。项目里我规范了接口风格前台接口统一用/api/**前缀后台管理接口用/admin/**前缀这样拦截器配置可以直接按路径区分权限。参数接收有几种方式我建议按场景选GET请求的查询参数用RequestParamPOST请求的JSON体用RequestBody路径里面的ID用PathVariable。这里有个坑——如果用RequestBody接收前端传来的JSON必须保证前端Content-Type是application/json而且字段名要和实体类属性名一致否则会反序列化失败。我在调试文档里专门记了一笔前端明明传了数据后端却接收到null八成是字段名对不上或者缺少无参构造方法。为了统一返回值格式我封装了一个Result类包含code、message、data三个字段。所有Controller方法都返回这个对象成功是code200业务异常是400或500。这样前端处理响应时逻辑统一不用一个个接口去猜返回结构。2.3 MyBatis 的动态 SQL 与多表关联查询MyBatis在这套系统里的核心优势是动态SQL。诗词筛选功能看起来简单实际是组合条件查询用户可能只选朝代可能只选作者可能既选朝代又按标题模糊搜索还可能按标签过滤。如果用Java代码拼SQL会很痛苦用MyBatis的where加if标签就优雅很多。select idsearchPoems resultMappoemResultMap SELECT p.*, a.name AS author_name FROM poem p LEFT JOIN author a ON p.author_id a.id where if testdynasty ! null and dynasty ! AND p.dynasty #{dynasty} /if if testauthorId ! null AND p.author_id #{authorId} /if if testkeyword ! null and keyword ! AND (p.title LIKE CONCAT(%, #{keyword}, %) OR p.content LIKE CONCAT(%, #{keyword}, %)) /if /where ORDER BY p.create_time DESC /select这里要注意的是模糊查询的SQL注入问题。MyBatis用#{}做预编译占位符不会注入但${}会所以模糊查询里一定不能把用户输入直接拼进SQL。我全部用CONCAT(%, #{keyword}, %)这种写法。多表关联主要是查询诗词详情时需要带上作者信息、标签列表、朗诵音频地址。我配置了resultMap用association和collection来处理一对多关系。一个常见的坑是N1查询——先查诗句100条再逐条查作者导致数据库压力大。解决办法是用联表查询一次性查出或者配置懒加载但懒加载在关闭SqlSession后容易报错所以我倾向于直接联表。3. Flask 辅助服务数据加工与智能推荐3.1 为什么用 Python 处理文本分析比 Java 省力在纯Java项目里做中文分词一般引入HanLP或IK Analyzer也不是不行但环境配置和代码量都比较重。而且词云生成需要先分词、再统计词频、再渲染图片用Java写一套至少几百行效果还不一定好。Python这边完全不一样jieba一行代码分词wordcloud几行代码出图。开发效率的差距在个人项目里是决定性的。我在Flask里拆了三个接口/api/analyze/hotwords接收朝代或作者参数返回高频词列表/api/analyze/wordcloud返回词云图片的base64编码或图片URL/api/recommend/similar根据用户最近浏览的诗词ID返回5首相似诗词这三个接口都是用Python标准库加第三方库完成的代码量总共不到200行。Flask开发起来也很轻app对象注册路由request对象取参数jsonify做响应前后端联调非常快。3.2 相似诗词推荐一个轻量但很出彩的功能推荐的实现思路不复杂给每首诗建立一个特征向量特征来自朝代、作者、风格标签、内容高频词四部分然后计算余弦相似度。核心代码如下from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def find_similar(poem_id, top_n5): poems load_poems_from_db() corpus [p[tags] p[content] for p in poems] vectorizer TfidfVectorizer(tokenizerjieba.lcut) matrix vectorizer.fit_transform(corpus) idx get_index_by_id(poem_id) scores cosine_similarity(matrix[idx], matrix)[0] top_idx scores.argsort()[::-1][1:top_n 1] return [poems[i][id] for i in top_idx]这段代码在生产数据量几千首诗词下跑得很快完全够用。如果数据量到十万级可以改成离线计算相似度并缓存但个人项目没必要过度设计。3.3 Flask 与 SSM 的联调细节双服务架构最大的麻烦是联调。我先约定好接口协议Flask服务统一返回{code: 0, data: ..., message: success}结构SSM这边用RestTemplate封装了一个FlaskClient工具类专门发HTTP请求。跨域问题必须解决。前端页面如果直接请求Flask接口浏览器会拦截跨域响应。我在Flask里配置了CORS允许SSM所在域名的请求from flask_cors import CORS CORS(app, resources{r/api/*: {origins: http://localhost:8080}})联调时还遇到一个典型问题Flask返回的中文被转成Unicode编码类似\u8bd7\u8bcd前端拿到后显示乱码。解决办法是在Flask里设置app.config[JSON_AS_ASCII] False或者在响应头加Content-Type: application/json; charsetutf-8。另外SSM调用Flask接口后要记得处理超时网络抖动可能导致接口卡死我给RestTemplate设置了5秒超时并且加了重试逻辑。4. 核心功能实现从数据入库到展演呈现4.1 古诗词数据清洗与批量导入网上能找到的古诗词数据集很多但质量参差不齐。我选了一个包含约3万首诗词的数据集包含标题、作者、朝代、正文、注释、译文、赏析字段。清洗时有几个关键步骤去重同一首诗可能出现多个版本、处理空字段赏析缺失的自动填充“暂无赏析”、统一朝代名称唐朝、唐代统一成唐朝、格式化正文中的换行和空格。数据库设计了五张核心表用户表、作者表、诗词表、标签表、收藏表外加评论表和操作日志表。诗词表和作者表是一对多关系诗词表和标签表是多对多关系用中间表关联。ER设计上要特别注意索引诗词表的dynasty、author_id字段要建索引content字段做全文搜索时用LIKE查询数据量大了会慢可以后续升级为全文索引。批量导入我用MyBatis的批量插入每次500条提交一次3万条数据大概十几秒导入完成。这里有个经验MySQL默认单条SQL有长度限制如果一次性插入太多会报max_allowed_packet错误所以批量插入必须分批。4.2 展演页面的视觉呈现与交互设计展演页是系统的门面我在视觉上下了不少功夫。整体UI采用水墨风格主色调是米白和黛青字体用衬线体模拟书法质感。诗词详情页用左右布局左边是诗词原文和讲解右边是配图和词云卡片。词云是“展演感”最强的一块。我让用户可以选择生成“李白词云”“唐诗高频词”等Flask服务调用jieba分词后用wordcloud生成图片返回给前端。前端拿到图片URL后做懒加载并配了一个淡入动画。除此之外我用ECharts做了两个图表一个是“历代诗词数量趋势图”让用户直观看到诗词发展的起伏另一个是“诗人关系图谱”基于共同标签和同朝代关系展示诗人之间的连接。不要小看这些图表。答辩时老师问“你的系统相比传统网站多了什么”这些可视化和交互功能就是最好的答案——它们不是花架子是新媒体展演能力的直接体现。4.3 收藏、点赞的防重复与计数一致性设计收藏和点赞最怕的是用户重复操作。做法有前端限制和后端限制两种前端限制只是不显示按钮用户可以绕过所以必须后端兜底。我采用的方案是唯一索引加事务收藏表加user_id poem_id唯一索引重复插入直接捕获DuplicateKeyException提示“已收藏”点赞表同样加唯一索引点赞数更新放在同一个事务里先插入再更新计数Transactional Override public Result addLike(Long userId, Long poemId) { try { likeMapper.insert(new Like(userId, poemId)); poemMapper.incrementLikeCount(poemId); } catch (DuplicateKeyException e) { return Result.error(400, 你已点过赞了); } return Result.success(); }更新计数时我没用count(*)再update而是直接increment避免并发下计数不准。如果要更强的一致性和更快的读写可以引入Redis做缓存计数再加异步落库但个人项目里数据库方案已经足够。4.4 管理后台的权限控制实现细节后台权限用SpringMVC拦截器加自定义注解实现。定义了一个RequireRole(ADMIN)注解在需要管理员权限的Controller方法上标注拦截器解析注解判断当前登录用户的角色字段。这种注解方式比直接判断用session.getAttribute(role)优雅得多权限逻辑集中在拦截器里代码更干净。这里有个容易忽略的点拦截器只拦截了Handler方法的执行静态资源CSS、JS、图片不受保护但前端页面本身需要在后台登录后才能访问。我用的方案是在登录成功后把用户对象写入Session后台页面每次请求都会加载一个全局拦截器判断Session里的用户是否为空为空就跳到登录页。5. 调试文档编写与常见问题排查5.1 调试文档应该怎么组织才不白写很多人的调试文档是流水账把自己怎么配置环境、怎么启动项目一步步写下来。说实话这种文档有一定价值但价值有限。我更推荐按“问题驱动”组织记录你实际遇到过的报错、排查思路和解决结果。比如问题现象排查步骤根因解决方案前端请求接口返回404检查URL是否拼写正确 → 检查Controller的RequestMapping → 检查配置类是否扫描到该包Controller所在包未被Spring扫描在Spring配置中增加包扫描范围诗词查询接口响应慢先查SQL执行时间 → 用EXPLAIN分析执行计划content字段LIKE查询全表扫描增加前缀索引或改用全文索引Flask接口返回中文乱码检查响应头 → 检查Flask配置JSON_AS_ASCII默认开启设置app.config[JSON_AS_ASCII] False用户登录后页面仍跳回登录页查看浏览器Cookie → 检查Session和Cookie的name冲突Session被拦截器误判断在登录拦截器白名单中排除登录接口我建议你在开发过程中随时记录不要等到最后再补。我当时就是准备了一个云笔记文档遇到问题马上记一笔最后整理成调试文档只花了一个晚上。答辩时老师翻到这样的文档第一印象就是“这个学生有工程素养”。5.2 环境搭建和部署踩过的坑环境问题往往是新手卡住的第一关。JDK版本和Maven版本不匹配、Tomcat版本过低导致Spring注解失效、MySQL 8的驱动类和旧版不同这些坑几乎每个人都踩过。我的建议是严格按照官方文档的版本要求来不要想当然用最新版。部署方面如果只是本地演示用IDEA一键启动就够。但如果你想有一个远程可访问的地址可以在一台Linux服务器上部署MySQL和Redis用Docker跑SSM项目打包成war包丢到Tomcat的webapps目录Flask服务用gunicorn加上nginx反代。Flask部署有个容易忽略的点开发服务器app.run()只适合本地调试它不支持并发请求必须换gunicorn这类WSGI服务器否则访问一多直接卡死。5.3 源码组织和讲解材料的整理思路源码不是写完就完事了还要让别人看得懂。我在项目根目录加了README写清楚项目结构、技术栈版本、数据库导入方式、启动步骤。包名用com.xxx.poetry按controller/service/mapper/entity/config分包每个类加必要的注释。Controller是薄的一层只做参数接收和结果返回Service是厚的逻辑层Mapper只写SQL。这种分层对答辩和后续维护都很有帮助。讲解材料我做了个PPT大纲先讲背景和痛点再讲技术选型接着讲架构图然后选三个核心功能做代码走读搜索、推荐、权限最后是总结与展望。讲的时候千万不要把每个类都念一遍要挑有技术含量和故事性的点讲比如“我在做收藏功能时发现并发会导致计数不一致所以加了事务和唯一索引”这种表述远好过“我实现了一个添加收藏的方法”。6. 项目复盘与进阶方向6.1 复盘哪些地方做得对哪些地方可以更好做得对的地方有三处。一是“展演”定位想清楚了整个项目不是无聊的CRUD而是有一套完整的产品逻辑这让系统在同类项目中有了记忆点。二是双技术栈的取舍合理SSM和Flask各干各的没有硬把Python塞进Java项目也没有让Flask去处理复杂的权限逻辑架构上很清爽。三是文档意识强调试文档和操作手册在答辩和后续复用中发挥了很大作用。可以更好的地方也有。一是前端用了传统的服务端渲染加少量JQuery交互体验不如现在的Vue/React流畅。如果重新做我至少会把前台用户端用Vue3重写后台管理用Element Plus搭界面前后端完全分离。二是搜索功能用的LIKE模糊查询2万条数据下响应时间在200毫秒左右还能接受但如果数据规模扩大应该引入ElasticSearch。三是Flask的推荐算法比较简单只是标签加词频的余弦相似度没有考虑用户行为权重准确率有限。6.2 从课程设计到生产级项目的三道门槛如果你想把这个项目做得更深入有三件事值得投入。第一件是引入Redis缓存热点数据。诗词详情页往往是访问最频繁的每次请求都查数据库会浪费资源。把Top100热门诗缓存到Redis里设置过期时间能显著提高接口响应速度。第二件是把Flask服务和SSM服务改造成可独立部署的容器化服务写一份Docker Compose配置把MySQL、Redis、Tomcat、Flask一起编排起来一键启动。第三件是补全测试。我当时的项目基本没写单元测试靠手动测试后期改代码经常担心改崩。至少应该对Service层的核心业务逻辑写单元测试用JUnit加Mockito。6.3 新媒体传播这块还能怎么玩如果跳出“课程设计”的范畴这套系统的展演能力其实还能扩展很多。比如接入语音合成接口把诗词文本转成标准朗读音频甚至可以按不同风格配音儿童音、古风音再比如做一个“诗词接龙”小游戏用户出上句系统对下句吸引用户留在页面里互动还可以利用微信小程序端做分享裂变用户读到一首好诗生成一张带词云的卡片分享到朋友圈让古诗词以新媒体内容的形态在社交链路上流动起来。这些设计不为炫技而是让传统文化在数字化载体中找到与当代用户对话的方式。技术说到底只是手段让用户看完之后愿意多读一首诗这个系统就多一分价值。我自己在实际做完这套系统后最大的体会是技术选型没有绝对的最好只有合不合适。SSM加Flask的组合放在大型互联网项目里确实不够现代化但作为一个需要完整覆盖业务逻辑、算法逻辑、前后端联调、工程文档的项目它的学习曲线恰好是最平滑的。如果你正在做类似的项目建议不要把时间花在争论“Spring Boot比SSM好”上而是先把展演的体验做透把每一个模块的边界划清楚把坑记下来。做到这三件事你的项目在答辩和求职里都不会平庸。最后再分享一个小建议项目里所有关键接口的返回格式一定要统一这看起来是小事但联调时能帮你省下大量无意义的排查时间。