Spring Boot 前后端分离实战：家乡特色推荐系统源码解析

简介：这是一套基于Java与Spring Boot框架开发的家乡特色推荐系统源码，面向Java Web方向初学者、课程设计及毕业设计人群，用于搭建一个支持家乡特色文章分类浏览、在线分享与管理维护的完整网站应用。压缩包含784个文件，大小约19.69MB；除Java后端源码、Vue前端页面、JavaScript脚本、CSS样式外，还携带SQL数据库脚本、XML配置文件、启动脚本及大量SVG图标素材，前后端资源完整，目录划分清晰，便于快速定位业务模块。目前已有65人学习下载。通过这份源码，可系统学习用户管理、文章分类管理、文章分享、评论收藏、轮播图管理等典型功能从数据表设计到接口与页面联调的实现思路；附带数据库初始脚本和一键启动脚本，能够直接部署运行，也能为二次开发提供完整参考。总体适合作为Spring Boot与Vue前后端分离项目的实训或课题支撑。

1. 从一份家乡特色推荐系统源码看 Spring Boot 前后端分离的落地方式

做 Java 开发这几年，Spring Boot 项目看过不少，但第一次打开一份“基于 Java 和 Spring Boot 框架的家乡特色推荐系统”源码时，最先吸引我的不是 Java 代码，而是一堆.vue.bak和index.html.bak。这说明它大概率不是传统的 Thymeleaf 模板应用，而是 Spring Boot 提供接口、Vue 负责渲染的前后端分离项目。这个系统的业务面很完整：文章分类、最新文章、个人中心、用户管理、文章分享、评论收藏、轮播图管理一应俱全。对刚学完 Spring Boot 四层架构、需要课程设计或毕业设计的在校生而言，这是一个能逐层拆开、照着改造的源码样例；对已经工作几年的开发者，也能从中看到一套简易 CMS 类系统从文件组织到权限校验的典型写法。

2. 解压即懂：从.bat和.vue.bak反推工程结构

项目里没有给出完整 README，但文件列表已经暴露了足够的架构信息。拿到一个陌生 Spring Boot 源码包，第一步不是急着用 IDEA 打开，而是先看文件后缀和命名习惯。bak是备份文件，多半是原作者调试前留下的旧版本；.vue是 Vue 单文件组件；.bat是 Windows 批处理脚本。三者组合起来，基本可以确认这是一个前后端分离项目，并且作者的本地开发环境是 Windows。

2.1 文件列表与项目结构的对应关系

把项目正文里出现的文件按功能归类，可以画出一张很清晰的工程地图。

提示：.bak不是标准资源后缀，Maven 的spring-boot-maven-plugin在打包时不会主动排除它。如果前端静态目录被复制进后端，记得在.gitignore中把*.bak去掉，否则备份文件可能被一起打进 jar。

从命名看，IndexAsideStatic.vue并不是说菜单永不变化，而是指菜单结构不会像动态表单那样频繁改变。作者用静态菜单组件承载后台管理入口，是课程设计里最节省开发成本的做法。

2.2 1-install.bat 在做什么

虽然我这里看不到原始脚本内容，但这类源码包中的安装脚本通常分成后端依赖安装和前端依赖安装两步。合理的实现大致如下。

@echo off chcp 65001 >nul set JAVA_HOME=D:\dev\jdk17 set MAVEN_OPTS=-Xmx1024m cd /d %~dp0backend call mvn clean install -DskipTests -Dfile.encoding=UTF-8 if errorlevel 1 goto :fail cd /d %~dp0frontend call npm install --registry=https://registry.npmmirror.com if errorlevel 1 goto :fail echo 依赖安装完成，请运行 2-run.bat pause exit /b 0 :fail echo 安装失败，请检查 JDK、Maven、Node 环境变量 pause exit /b 1

这段脚本的逻辑很简单：先切到 UTF-8 代码页，避免中文路径导致 Maven 读取 pom.xml 乱码；然后将JAVA_HOME指向本地 JDK 17，并用MAVEN_OPTS限制 Maven 堆内存为 1GB，防止小内存机器在编译时崩溃。之后分别进入 backend 和 frontend 目录执行依赖安装。

这里最容易翻车的点是JAVA_HOME。很多人安装 JDK 后没有配置系统环境变量，而是直接把目录改成了自己的解压路径。脚本如果写死D:\dev\jdk17，换一台机器必然启动失败。所以网上关于“java环境变量配置详细教程”的搜索一直很热门，因为大量课程设计跑不起来的原因不是代码，而是环境变量缺失。更稳妥的写法是在脚本里先尝试java -version，再决定是否提示用户手动设置。

2.3 2-run.bat 与 3-build.bat 的开发/生产差异

开发时我们希望后端热部署、前端实时刷新，生产时则希望输出一个独立 jar。两套命令的侧重点完全不同。

# 开发环境：前端使用 Vite 或 Webpack dev server，后端独立启动 cd frontend npm run dev # 生产环境：前端先构建，再把静态资源复制到后端 resources cd frontend npm run build cp -r dist/* ../backend/src/main/resources/static/ # 最后打包后端 cd ../backend mvn clean package -DskipTests java -jar target/hometown-server.jar --server.port=8080

开发环境由 Node 提供页面热更新，后端只暴露localhost:8080/api接口；生产环境则需要把前端产物交给 Spring Boot 托管，这是国内课程设计项目最常见的部署方式。要注意--server.port的优先级高于application.yml，如果后端和前端端口相同，会让静态资源请求冲突。我在实际改造时通常让前端 dev server 跑 5173，后端固定 8080，两者通过 vite 代理转发/api请求。

3. 功能模块拆解：Spring Boot 四层架构与关键数据模型

一个完整的家乡特色推荐系统，核心业务可以浓缩成：用户发布文章、管理员审核、其他用户查看/评论/收藏。如果在这里引入 Spring Boot 四层架构的讨论，就必须说清楚 Controller、Service、Mapper 和实体之间的边界。

3.1 六张核心表的结构设计

业务实体包括：用户、文章分类、文章、评论、收藏、轮播图。对应 MySQL 至少六张表。字段设计不必过度复杂，但需要满足课程设计答辩时评委最常问的“表关系”问题。

给出关键建表语句。字符集统一使用 utf8mb4，这是国内做中文内容类项目的基本要求。

CREATE TABLE `article` ( `id` INT NOT NULL AUTO_INCREMENT, `title` VARCHAR(120) NOT NULL, `summary` VARCHAR(255) DEFAULT '', `content` LONGTEXT, `cover` VARCHAR(255) DEFAULT '', `category_id` INT DEFAULT NULL, `user_id` INT DEFAULT NULL, `views` INT DEFAULT 0, `status` TINYINT DEFAULT 1 COMMENT '1: 审核通过 0: 待审核', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_user` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `favorite` ( `id` INT NOT NULL AUTO_INCREMENT, `article_id` INT NOT NULL, `user_id` INT NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_article_user` (`article_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

两张表里最值得解释的是article.status和favorite.uk_article_user。文章默认status = 0，管理员审核通过后变为 1，这是“文章分享管理”和“首页只显示最新已审核文章”的关键。收藏表的联合唯一索引则是数据库层的幂等保护，反复点击收藏不会插入重复记录。

3.2 从 Controller 到 Mapper 的完整链路

我在写课程设计代码时，尤其看重分层是否清晰。下面展示“首页最新文章”和“发布文章”两个最典型的入口。

@RestController @RequestMapping("/api/article") @RequiredArgsConstructor public class ArticleController { private final ArticleService articleService; @GetMapping("/latest") public Result<List<ArticleVO>> latest(@RequestParam(defaultValue = "6") int size) { List<ArticleVO> articles = articleService.latest(size); return Result.ok(articles); } @PostMapping("/publish") public Result<Void> publish(@RequestBody @Valid ArticlePublishDTO dto, @RequestAttribute Long currentUserId) { articleService.publish(dto, currentUserId); return Result.ok("发布成功，等待审核"); } }

@RequestParam(defaultValue = "6") int size会让前端不传参数时也能拿到 6 条默认数据；@RequestAttribute Long currentUserId则是从登录拦截器写入的 request 属性中取值，而不是信任前端传过来的userId，这是防止越权的一个基本思路。Controller 只做参数转发和结果包装，真正的校验与业务在 Service 层。

@Service @RequiredArgsConstructor public class ArticleServiceImpl implements ArticleService { private final ArticleMapper articleMapper; private final CategoryMapper categoryMapper; @Override @Transactional(rollbackFor = Exception.class) public void publish(ArticlePublishDTO dto, Long userId) { if (dto.getCategoryId() == null || categoryMapper.selectById(dto.getCategoryId()) == null) { throw new BusinessException(400, "文章分类不存在"); } Article article = new Article(); article.setTitle(dto.getTitle()); article.setContent(dto.getContent()); article.setCategoryId(dto.getCategoryId()); article.setUserId(userId); article.setStatus(0); articleMapper.insert(article); } }

为什么这里要主动查一次分类是否存在？因为外键约束只能保证数据库层面的完整性，如果分类被软删除，文章发布后首页会出现一个不存在分类的“孤儿内容”。@Transactional(rollbackFor = Exception.class)保证后续如果插入文章失败，整个事务回滚，不会留下半条数据。

Mapper 层我会更推荐 XML 写法，尤其是涉及多表连接时，注解容易把 SQL 堆得不可读。

<select id="findLatestWithCategory" resultType="com.example.vo.ArticleVO"> SELECT a.id, a.title, a.summary, a.cover, a.views, c.name AS categoryName, u.username FROM article a LEFT JOIN category c ON a.category_id = c.id LEFT JOIN sys_user u ON a.user_id = u.id WHERE a.status = 1 ORDER BY a.create_time DESC LIMIT #{size} </select>

这里的LEFT JOIN是有意为之，不是随手写的。如果某个分类被管理员删除，文章依然要出现在首页，只是分类名显示为空；如果用INNER JOIN，文章会跟着消失，这对内容型站点来说是不能接受的损失。所以列表查询时，主表数据永远不能被关联表缺失带走。

3.3 用户和管理员的角色区分

很多人做权限时习惯在每个 Controller 里写if (!"admin".equals(role))，虽然能跑，但代码味道很差。我更习惯用注解加拦截器完成统一拦截。

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String[] value() default { "ADMIN" }; }

@Component public class RoleInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod method) { RequireRole requireRole = method.getMethodAnnotation(RequireRole.class); if (requireRole == null) { return true; } Long currentUserId = (Long) request.getAttribute("currentUserId"); String role = getRoleFromContext(currentUserId); if (!Arrays.asList(requireRole.value()).contains(role)) { response.setStatus(HttpStatus.FORBIDDEN.value()); response.getWriter().write("{\"code\":403,\"msg\":\"无权限\"}"); return false; } } return true; } }

这段代码把权限判断从业务方法里完全抽离。@RequireRole标注在管理端接口上，比如用户管理、文章审核、轮播图管理；普通用户发布文章、评论和收藏则不需要加。这样即使有人跳过前端直接调/api/admin/user/delete，也会在进入 Controller 前被拦截下来。

4. 前端组件与接口联调：首页、后台管理和互动逻辑

.vue.bak文件里出现IndexMain、IndexAsideStatic、BreadCrumbs、IndexHeader，说明后台管理界面是一个经典的后台布局。这章重点解释组件之间怎么配合，以及文章收藏、评论这两个互动接口怎么设计。

4.1 后台管理布局的组件关系

IndexMain.vue通常承载动态内容区，内部是<router-view />；IndexAsideStatic.vue是左侧菜单；IndexHeader.vue包含用户头像和下拉菜单；BreadCrumbs.vue从当前路由对象里读meta.title生成面包屑。

组件的通信不是互相 import，而是通过路由和状态管理完成。菜单点击后改变$route，IndexMain里的路由视图响应变化，面包屑根据route.meta更新。这个模式在几乎所有 Vue 后台项目里通用。

4.2 首页“最新文章”的加载与竞态处理

首页文章列表是对外展示的重要模块，后端已经设计了/api/article/latest接口，前端只需要在onMounted中拉取一次数据。

import { onMounted, onUnmounted } from 'vue' import { fetchLatestArticles } from '@/api/article' let controller = null onMounted(async () => { controller = new AbortController() try { const { data } = await fetchLatestArticles(6, controller.signal) articles.value = data.data } catch (e) { if (e.name !== 'AbortError') { message.error('最新文章加载失败') } } }) onUnmounted(() => controller?.abort())

AbortController是为了处理竞态问题。比如用户快速点击“首页”再点击“个人中心”，第一次请求在切换后才返回，此时页面已经卸载，旧数据再去更新状态就会形成一闪而过的脏数据，甚至触发 Vue 警告。signal作为 axios 的取消令牌，能在组件卸载时把请求取消掉，从源头避免响应回调执行。

4.3 收藏与评论接口的并发与安全

收藏操作必须考虑重复点击。配合favorite表上的唯一索引，后端可以做到无需先查询再插入。下面给出一个实用的 SQL 方案。

@Insert(""" INSERT IGNORE INTO favorite(article_id, user_id, create_time) VALUES(#{articleId}, #{userId}, NOW()) """) int insertIgnore(@Param("articleId") Long articleId, @Param("userId") Long userId);

INSERT IGNORE在遇到唯一索引冲突时不会报错，只会返回影响行数为 0。Service 层根据返回值判断是“收藏成功”还是“已经收藏过”，前端再据此切换按钮状态。这种写法比 select+insert 两段式少一次数据库往返，也避免了并发下两个请求同时判断不存在、再同时插入的问题。

评论接口则要把重点放在内容安全上。典型的低水平实现是直接把用户文本存储到 DB，再原样渲染到页面。正确的做法是在 DTO 上加@NotBlank与@Size(max = 500)，再在 Service 层做一次 HTML 转义。

public void addComment(CommentDTO dto, Long userId) { if (dto.getContent() == null || dto.getContent().isBlank()) { throw new BusinessException(400, "评论内容不能为空"); } String safeContent = HtmlUtils.htmlEscape(dto.getContent().trim()); commentMapper.insert(dto.getArticleId(), userId, safeContent); }

HtmlUtils.htmlEscape会把<script>转成<script>，浏览器渲染时只会显示字符串，不会当成脚本执行。这是最基础的防存储型 XSS 手段。如果你用 Jsoup，还可以做白名单过滤，只允许p、a、img等常见标签，这属于进阶方案。

5. 部署排错与一个提升演示效果的小技巧

5.1 三个 bat 脚本的执行顺序和常见问题

拿到源码包后，标准顺序是：1-install.bat装依赖，2-run.bat起开发环境，3-build.bat做生产构建。但我在实际复现时遇到最多的问题有三个。第一，脚本里的 JDK 路径和本机不一致，导致 Maven 直接退出，解决办法是优先使用JAVA_HOME环境变量而不是写死。第二，MySQL 版本和连接串不匹配，Spring Boot 的driver-class-name在高版本 MySQL 下应该配置为com.mysql.cj.jdbc.Driver，并指定serverTimezone=Asia/Shanghai。第三，端口被占用，Spring Boot 默认 8080，如果本机有多个 Java 进程，建议在运行脚本中加入端口检查，或者运行时用--server.port指定。

5.2 Spring Boot Actuator 未授权访问排查

热词里有不少人在搜“spring boot actuator未授权访问”，说明这个问题在课程设计和生产环境里都很常见。Actuator 暴露了大量运行时信息，如果配置过于宽松，任何访问者都可以读取系统环境变量、Bean 列表甚至堆转储。比如下面这样的配置就是不建议的。

management: endpoints: web: exposure: include: "*"

改造后应只暴露必要的端点。

management: endpoints: web: exposure: include: health,info endpoint: health: show-details: never

health用于探活，info可以预留为项目版本信息。在答辩演示时，如果评委习惯性地访问/actuator/env，看到的应该是 404 而不是一堆配置项。对使用 Spring Boot 的老项目做安全整改，这是优先级最高的一个动作。

5.3 用 Banner 在线生成器提升项目辨识度

最后分享一个不太起眼但很抓眼球的技能点。Spring Boot 启动时的 ASCII Art Banner 可以用在线 Banner 生成器制作，把生成的banner.txt放到src/main/resources下，重启项目就能看到。

_____ _____ _ _ _ | | |___ _ _ _ _ ___ ___ ___ ___ | | |_ ___ _ _ _| |_|_|___ ___ | | . | | | | | .'| . | .'| . | | | | | . | .'| | | | _| | . | | |__|__|___|_____|__,|___|__,|_ | |_|_|_|___|__,|___|_| |_| |_|___|_|_| |___|

这个细节在课程设计演示时相当有用，评委看到的不再是冷冰冰的 Spring Boot 默认 LOGO，而是项目名或学校名。更重要的是，它说明作者对 Spring Boot 的启动流程有感知，知道banner.txt的加载机制。配合上面对 Actuator 端点的罚配置，整套系统在演示时既显得完整，又经得起追问。

本文还有配套的精品资源，点击获取