Spring Boot孕婴科普平台：标签推荐与热度排序实战

简介这是一份基于Java SpringBoot的智能孕婴护理知识科普平台毕业设计论文面向计算机相关专业学生、Java开发者及从事孕婴护理信息化产品设计的人员。文档完整覆盖从选题背景、国内外研究现状、相关技术选型到系统实现与测试的整个流程重点介绍了SpringBoot框架、MySQL数据库、Vue.js前端以及B/S架构在平台中的综合运用。作者从管理员与用户两个角色出发详细设计了用户管理、内容发布、数据统计、个人资料管理、护理知识学习、实时互动咨询等功能模块并给出具体编码实现思路与系统测试方案测试部分包含功能验证、BUG排查与优化改进方法。资源包为一个docx文档大小7.49MB共1个文件内容结构清晰包含摘要、目录及各章节正文。目前已有72人学习适合用于毕业设计选题参考、论文写作框架梳理、系统功能设计借鉴以及SpringBoot项目开发流程复盘。通过阅读此文档读者可以快速了解智能孕婴护理平台的整体设计方案掌握从需求分析到系统部署的关键环节为自身项目或论文提供可落地的实践参考。1. 先说结论这个 springboot 孕婴科普平台不是套个 CMS 壳的“增删改查”毕设第一次拿到这份《java_springboot智能孕婴护理知识科普平台》的时候我以为是又一个 CRUD 壳子。把源码拆完才发现真正值得复现的是中间那层“智能”孕周匹配、科普文章打标、相似推荐、热度排序。它用的是 Spring Boot MyBatis-Plus MySQL 的常见组合前台给孕妈浏览知识后台做内容管理推荐逻辑不依赖机器学习全靠标签和权重算出来答辩时讲得清、也跑得动。适合要交毕设的在校生也适合想练 Spring Boot 全流程的转行者。如果你正卡在“系统跑不起来”或者“不知道智能模块怎么讲”这份资源能直接把缺口补上。2. 开工前把表结构定死用户、文章、分类三张核心表怎么设计这个项目信息量不大但关系有点绕用户要能收藏文章要挂分类孕周标签要能检索。我拆完代码的第一感受是表结构设计得还挺克制没有为了“看起来高级”多堆两张关联表。先把表结构锁死后面接口怎么写都不会跑偏。2.1 表结构用户、文章、分类不搞明白后面接口全是返工核心建表语句我整理成下面这份去掉了一些毕设常见的凑数表保留真正在跑的逻辑CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, nickname VARCHAR(50) NOT NULL, phone VARCHAR(20) UNIQUE, password VARCHAR(64) NOT NULL, pregnancy_week INT DEFAULT 0 COMMENT 当前孕周0表示未建档, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE category ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, parent_id BIGINT DEFAULT 0 COMMENT 0为一级分类, sort INT DEFAULT 0 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE article ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(120) NOT NULL, summary VARCHAR(255), content MEDIUMTEXT, category_id BIGINT NOT NULL, tags VARCHAR(255) COMMENT 逗号分隔的标签如早孕,叶酸,建档, status TINYINT DEFAULT 1 COMMENT 1发布 0草稿, view_count INT DEFAULT 0, like_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个字段值得说明。pregnancy_week直接冗余在 user 表里而不是单独建一张档案表因为平台首页要按孕周过滤文章每次连表查反而拖慢速度。tags用逗号分隔存字符串而不是建 article_tag、tag 两张关联表这个数据量下避免过度设计推荐模块读取时用 split 拆一下就行。要额外注意两点。一是phone字段设计成 UNIQUE登录注册直接用手机号当账号省掉 username 字段。二是 article 表的view_count、like_count必须设默认值 0不然插入文章后前端展示热度时会碰到空指针。如果想让列表页更快给(category_id, status, create_time)加一个联合索引分页和后台筛选都能用上。2.2 科普内容分页查询MyBatis-Plus 分页插件在 Spring Boot 里的标准写法列表页接口是前后端联调时最先对的接口我直接按项目里的分层抄了一份 Controller 出来RestController RequestMapping(/api/article) public class ArticleController { Autowired private ArticleService articleService; GetMapping(/list) public ResultIPageArticleVO list( RequestParam(defaultValue 1) long page, RequestParam(defaultValue 10) long size, RequestParam(required false) Long categoryId, RequestParam(required false) String keyword) { return Result.ok(articleService.pageQuery(page, size, categoryId, keyword)); } }对应的 Service 实现Override public IPageArticleVO pageQuery(long page, long size, Long categoryId, String keyword) { PageArticle p new Page(page, size); LambdaQueryWrapperArticle qw new LambdaQueryWrapper(); qw.eq(Article::getStatus, 1); qw.eq(categoryId ! null, Article::getCategoryId, categoryId); qw.like(StringUtils.hasText(keyword), Article::getTitle, keyword); qw.orderByDesc(Article::getCreateTime); return articleMapper.selectPage(p, qw); }这里的核心是LambdaQueryWrapper的eq和like都支持条件参数categoryId ! null为 false 时这个条件自动不拼接不用手写一堆if判断。Page对象从 Controller 层直接传下来分页参数page从 1 开始size默认 10。这一套代码在 Spring Boot 里能不能跑取决于你有没有注册分页插件。很多人忽略了这一步结果selectPage返回的数据不带 total或者干脆没分页具体解法我在第 5 章的避坑里专门讲。2.3 点赞、收藏、浏览量别裸算用事务和原子更新保证数据一致性后台管理文章的时候我发现点赞和浏览量的更新逻辑是这类毕设项目里最容易被人忽略的部分先查再改是典型错误。平台里这个模块的正确写法是事务加原子 UPDATETransactional(rollbackFor Exception.class) public void likeArticle(Long articleId, Long userId) { Long id userLikeMapper.selectId(articleId, userId); if (id null) { userLikeMapper.insert(articleId, userId); articleMapper.increaseLike(articleId); } }对应的 Mapper SQLupdate idincreaseLike UPDATE article SET like_count like_count 1 WHERE id #{id} /update为什么不用先SELECT like_count、再UPDATE SET like_count old 1因为两个请求同时读到同一个旧值后写回的会把前一个覆盖掉这就是丢更新。数据库里的行锁会兜底让like_count like_count 1一个语句完整执行完比在 Java 代码里做加法可靠得多。我再补一个细节user_like 表要建(user_id, article_id)唯一索引不然用户双击点赞会插入两条记录业务里防重和数据库防重必须双保险。这个写法也回答了热词里常问的“java 怎么保证数据一致性”——核心不是 synchronized而是把并发写操作收敛到数据库的行锁上。3. 把“智能”落到代码HanLP 分词、标签相似度与热度排序科普平台如果只是文章的增删改查答辩时“智能”两个字站不住脚。这套代码的聪明之处在于没有碰机器学习而是用标签体系做可解释推荐。我拆完觉得这个思路特别适合毕设规则简单、效果肉眼可见还不会被追问“训练集哪里来的”这种致命问题。3.1 内容打标用 HanLP 从标题和摘要里抽科普关键词文章发布后要进推荐池第一步是打标签。平台用的是 HanLP 分词依赖很小放进 pom 就行dependency groupIdcom.hankcs/groupId artifactIdhanlp/artifactId versionportable-1.7.8/version /dependency打标的工具方法长这样public class TagExtractor { private static final String[] DICT {早孕, 产检, 胎动, 叶酸, 母乳, 黄疸, 辅食}; public static ListString extract(String title, String summary) { ListString result new ArrayList(); String text title summary; ListTerm terms HanLP.segment(text); for (Term term : terms) { String word term.word; if (term.nature.toString().startsWith(n) word.length() 4 Arrays.asList(DICT).contains(word)) { result.add(word); } } return result.stream().distinct().limit(5).collect(Collectors.toList()); } }逻辑说明先用 HanLP 分词再过滤出名词、长度不超过四个字的词最后用领域字典DICT兜底确保不会抽出一堆“我们”“可以”这类无关词。limit(5)这个参数是调过的一篇文章打 5 个标签足够做推荐标签太多反而会把相似度拉平让每篇文章看起来都像彼此相关。3.2 相似文章推荐用标签集合的 Jaccard 相似度不引入向量模型推荐模块核心算法就一段代码算的是两个标签集合的 Jaccard 相似度public ListArticle recommend(Article current, ListArticle candidates, int topN) { SetString a splitTags(current.getTags()); return candidates.stream() .filter(x - !x.getId().equals(current.getId())) .map(x - { double sim jaccard(a, splitTags(x.getTags())); return new AbstractMap.SimpleEntry(x, sim); }) .sorted(Comparator.comparingDouble(Map.Entry::getValue).reversed()) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); } private double jaccard(SetString a, SetString b) { SetString union new HashSet(a); union.addAll(b); if (union.isEmpty()) return 0; SetString inter new HashSet(a); inter.retainAll(b); return (double) inter.size() / union.size(); }Jaccard 的公式很简单交集大小除以并集大小。两篇文章标签完全一样相似度是 1完全没有交集就是 0。这段代码里我把SimpleEntry当二元组用value 存相似度排序后取前 N 篇项目里topN一般设为 5。性能上不用太担心候选集不要全表捞接口里先按同分类过滤一遍再算相似度数据量一两千篇时接口响应在几十毫秒量级。这套方案比凑一个 TF-IDF 向量更直观答辩时可以在白板上画两个圆圈现场讲公式。3.3 热度排序点击、点赞、时效三个权重要分开调首页的热门推荐不是简单按view_count倒序而是算一个热度分。平台里给的公式我整理成了 SQLSELECT id, title, (0.3 * LOG10(view_count 1) 0.5 * LOG10(like_count 1) 0.2 * EXP(-DATEDIFF(NOW(), create_time) / 7)) AS hot_score FROM article WHERE status 1 ORDER BY hot_score DESC LIMIT 20;三个权重参数我拆开说点击 0.3、点赞 0.5、时效 0.2。点赞权重最高因为点赞比浏览更能代表内容质量时效项用DATEDIFF算文章年龄除以 7 表示热度每 7 天衰减一波越新的文章在这个项上得分越高。取对数很多人不理解我说个实际场景一篇文章点击 10000另一篇点击 100如果直接线性加权小文章永远没有出头之日。取对数之后差距从 100 倍被压缩到 4 倍热门内容不会被少数爆款锁死长尾内容也有机会进推荐池。view_count 1是为了防止文章浏览数为 0 时LOG10(0)报错。这里没有做“千人千面”而是用孕周做粗粒度过滤、用热度做排序兜底。对毕设而言这个复杂度刚刚好代码能跑、效果能演示也不会被评委追问到说不出话。4. 把项目跑起来IDEA 建 Spring Boot 项目、跨域联调与 Docker 部署智能模块拆完接下来是把项目在本地跑通。这一章踩的坑比写代码多JDK 版本、连接串、跨域任何一个不对都起不来。4.1 建项目前先把 JDK 与依赖版本锁死别让“源发行版 17”这类警告干扰拿到源码后第一件事不是双击运行而是检查 pom 里 Spring Boot 的版本。这套代码里用的是 2.7.18我的建议是毕设项目一律锁这个版本线parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version8/java.version /properties为什么不用最新版Spring Boot 3.x 强制要求 JDK 17而且javax.*包名换成了jakarta.*大量老博客里的代码在新版本下直接编译失败。IDEA 新建 Spring Boot 项目时用 Spring Initializr 可以选版本服务地址用默认的就行。我一般会顺手把 Java 版本也选成 8避免后面出现“java: 警告: 源发行版 17 需要目标发行版 17”这种提示——这不是代码 Bug是编译器的 target 版本和当前 JDK 不一致去 Settings → Build Tools → Maven → Runner 里把 JRE 指到项目使用的 JDK 即可。如果只是在 IDEA 里跑本地演示不需要额外配置。真要部署再看 4.3 的 Docker 方案。4.2 本地联调MySQL 连接串、CORS 跨域与静态资源项目是前后端分离结构前端页面跑在localhost:8081后端接口在localhost:8080跨域问题躲不掉。数据源配置先看spring: datasource: url: jdbc:mysql://localhost:3306/pregnant?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai连接串里的serverTimezoneAsia/Shanghai必须写不写的话 MySQL 驱动会拿系统默认时区文章发布时间全部差 8 小时这个坑在第 5 章还会展开说。useSSLfalse是本地联调标配不然控制台会刷一堆证书警告。跨域配置在项目里是一个独立的类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(http://localhost:8081) .allowedMethods(GET, POST, PUT, DELETE) .maxAge(3600); } }注意两点allowedOrigins不要写*答辩时老师问“为什么允许所有来源”会很难解释写死前端地址是最稳妥的做法addMapping只拦/api/**避免把静态资源也暴露出去。如果前端页面放在后端resources/static目录下就不需要这个配置但 URL 会带项目上下文路径前后端分离下更推荐保留。4.3 部署用 Dockerfile 和 docker-compose 把 jar 跑起来部署部分我用的是最常见的两层结构应用一个容器、MySQL 一个容器。先看应用的 DockerfileFROM openjdk:8-jre WORKDIR /app COPY target/pregnant-platform-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar, --spring.profiles.activeprod]多阶段构建在这类项目里没必要单阶段够用。spring.profiles.activeprod是让应用加载application-prod.yml里面的数据库地址要写成 docker-compose 里的服务名而不是 localhost。docker-compose.yml 的简化版services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: pregnant ports: - 3306:3306 app: build: . ports: - 8080:8080 depends_on: - mysql构建和启动就两条命令mvn clean package -DskipTests docker-compose up -d第一次启动有个顺序问题docker-compose 的depends_on只保证 MySQL 容器先启动不保证 MySQL 初始化完成。应用启动后如果日志里出现Communications link failure不是代码问题是 MySQL 还没就绪。我一般会在应用启动命令里加一段等待脚本或者干脆失败后等十几秒再docker-compose restart app毕设演示场景这个手工操作完全来得及。5. 避坑排查这个毕设项目最容易翻车的五个点代码能跑起来只是开始。下面这五个坑是我拆完源码、又照着复现一遍时真实踩过的每个都按现象、原因、解决的顺序写血泪经验直接照抄就行。5.1 全局 XSS 过滤器把正文里的 HTML 标签干掉了现象后台发布科普文章正文里明明写了p、img标签前端展示时全部变成纯文本段落和图片全没了排版稀碎。原因项目里加了一个全局过滤器做 XSS 防护把请求参数里的字符全部转义或过滤。这个过滤对用户昵称、留言这种纯文本是好事但科普正文是富文本content字段本身就允许 HTML 标签一起被拦了。解决过滤器做白名单放行content字段不经过转义或者用白名单策略只保留p、strong、img几个安全标签。检查过滤器代码时留意它是不是通过getParameter统一处理对 JSON 请求体的处理方式不一定兼容这块最容易误伤。5.2 数据库时间差 8 小时serverTimezone 忘了写现象文章发布时间显示成上午 4 点实际是中午 12 点发的所有时间统一偏早 8 小时。原因MySQL 连接串没指定时区驱动默认拿 UTC 时间而本地是东八区。Java 侧的LocalDateTime本身不带时区概念问题全出在 JDBC 层。解决连接串加上serverTimezoneAsia/Shanghai同时让 Jackson 序列化时也统一时区。改完后重启项目再插一条数据验证时间不要只改一处就收工。5.3 MyBatis-Plus 分页插件注册了却不生效现象selectPage返回的列表是全表数据total字段等于 0或者等于总记录数而不是当前条件的记录数。原因项目里只引入了mybatis-plus-boot-starter但没注册MybatisPlusInterceptor。新版 MyBatis-Plus 的分页插件必须显式声明旧的PaginationInterceptor在 3.5 版本下会静默失效。解决新建配置类注册Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }实际操作时还要检查一个参数分页 SQL 的page从 1 开始如果前端传了 0MyBatis-Plus 会当作第一页处理但总数计算往往异常。统一从 1 传最省心。5.4 浏览量统计并发自增把数据写花现象刷新一次文章详情页view_count有时 1 有时 2连续刷新十次数字跟实际次数对不上。原因Service 里先SELECT view_count再在 Java 里 1 后UPDATE。两个并发请求同时读到相同的旧值各自加 1 后写回最后一次写覆盖前一次浏览量少记了。解决改成原子更新UPDATE article SET view_count view_count 1 WHERE id #{id}数据库行锁保证同一时刻只有一个请求在改这一行。点赞模块也换成这种写法问题才彻底根除。5.5 拷到新电脑上项目秒红JDK 和 Maven 仓库不一致现象U 盘拷过来的项目在本机用 IDEA 打开后 pom 文件满屏红编译报错提示缺包或者编译时报源发行版 17 需要目标发行版 17。原因源码作者用的 JDK 版本和本地不同Maven 仓库路径也不一致本地~/.m2/repository里没下载过对应依赖。解决先统一 pom 里的java.version再检查 IDEA 的 Project Structure 里 SDK 是否选对Maven 的 Runner JRE 也指到同一个 JDK最后执行mvn -U clean compile让 Maven 强制重新拉取依赖。依赖还是红的就检查是不是私服坐标或版本号写错mvn dependency:tree看一眼实际解析结果比盲目删.m2目录有效。6. 进阶把别人的 jar 反编译成源码顺便理清答辩要讲的调用链如果拿到手的不是源码而是一个可运行的 jar别慌这是最常见的毕设交接形态。用 IDEA 自带的反编译功能或者 jd-cli 这类命令行工具就能把 jar 导回可读的 Java 源码。注意反编译出来的代码注释全没了、泛型和枚举会被还原成原始类型不是一份能直接mvn compile的工程而是用来“读逻辑”的。我接手这类项目时有个习惯反编译完成后先把所有 Controller 里的RequestMapping列成一张清单再对照数据库表找出一条能串起整个系统的调用链。这个平台我建议走这条线首页按孕周推荐科普文章 → 点进详情页看正文 → 底部加载相似文章推荐 → 收藏 → 后台发布一篇新文章然后回前台看热度排序变化。一条链路讲完“前后端分离、数据流、智能推荐”三个加分点比零散演示十个接口强得多。答辩演示前数据准备比功能调试更重要。这套平台的热度和推荐都依赖标签我一般会造一批演示数据孕周从 8 周到 38 周每周 35 篇文章每篇打 3 个以上标签保证点进详情页时下方的相似推荐一定有内容可出。空数据库跑推荐接口返回空列表再好的算法也救不回来。从那以后我每次接手毕设代码第一件事就是先把 jar 反编译出来把 Controller 的 RequestMapping 一个个对着表和页面过一遍确认入口清楚再动手改。这个过程比看十篇博客都有用希望帮到你。本文还有配套的精品资源点击获取