基于Spring Boot与Vue的校园周边美食探索分享平台设计与实现-育师

1. 项目缘起与整体设计思路

1.1 为什么是“校园周边美食探索及分享平台”

做这个平台的念头，其实来自一次很日常的痛点。某个小组在课程设计选题阶段，发现每年新生入校、老生聚餐、社团团建时，大家问得最多的一个问题就是“周边有什么好吃的”。校园周边的美食店更新迭代快，外卖平台上又充斥着大量推广店铺，真正符合学生口味、性价比高的宝藏小店反而很难被挖掘出来。于是这个小组确定了做一个“校园周边美食探索及分享平台”的方向——本质上就是一个基于校园地理范围的美食信息聚合与UGC分享社区。

这个选题很讨巧，它既不是一个纯CRUD的学生管理系统，也不是那种动辄就要对接第三方地图服务、算法推荐的宏大平台。它的业务边界非常清晰：以校园为中心，以美食为内容载体，以学生为用户群体，核心功能就是“发现美食”和“分享评价”。从技术上来说，它几乎覆盖了一个典型JavaWeb项目所有必备的技能点：用户认证与授权、数据的增删改查、文件上传、分页搜索、评论互动、以及简单的推荐逻辑。

从结果来看，这个项目最后成了答辩现场比较容易讲清楚的选题。评委老师关心的无非就是几个问题：你的系统解决了什么问题？技术选型为什么这么做？核心业务逻辑是怎么实现的？遇到过的难点是什么？这个选题恰好都能给出明确的答案。

1.2 技术选型的取舍考量

技术栈用的是Spring Boot + MyBatis-Plus + MySQL + Vue + Element UI，标准的“前后端分离 + 单体后端”组合。这里简单说一下为什么这么选，因为答辩时老师一定会问。

首先后端用Spring Boot，理由非常务实。一方面它是目前JavaWeb开发的绝对主流，哪怕毕业后找工作，Spring Boot也是必备技能，课程设计用这个技术栈对求职有帮助；另一方面Spring Boot的自动配置特性可以极大减少繁琐的XML配置，让团队把精力集中在业务代码上。Maven管理依赖、内置Tomcat一键启动，这对一个课程设计团队来说能节省大量环境折腾的时间。

持久层选了MyBatis-Plus而不是原生MyBatis，主要原因是效率。MP提供的内置CRUD方法可以直接覆盖大部分单表操作，比如用户信息管理、收藏记录、点赞记录这类简单表的增删改查，几乎不用写SQL。而那些真正涉及多表关联的复杂查询——比如“按评分+距离+销量综合排序”这种带多重条件的列表查询、美食帖子的分页搜索——仍然可以手写XML或使用注解SQL精细控制。这种“简单操作不写SQL，复杂查询保留SQL”的混合模式，在团队开发中能明显提高效率。

前端选了Vue 2 + Element UI，而不是Vue 3或React，原因比较现实：团队成员已有的课程基础就是Vue 2，Element UI的组件库能快速搭出后台管理界面，表格、表单、分页、弹窗这些组件几乎开箱即用。虽然是前后端分离，但前端不需要做得过于复杂，Vue Router管理页面路由、Axios统一处理HTTP请求、Vuex存储登录状态和用户信息，这三件套就足够了。

数据库用MySQL 8.0，存储引擎InnoDB，字符集utf8mb4。有一点需要特别注意：如果平台需要展示emoji表情——美食评价里用户很可能会发“好吃到哭泣”之类的表情——那么utf8mb4是必须的，一般的utf8字符集存不了emoji，这个问题当年调试的时候困扰了不少人。

通信协议与数据格式：前后端通过RESTful API通信，统一返回JSON格式。这里提前定义了统一的响应体结构——{code, message, data}，方便前端做全局拦截处理。登录认证采用JWT（JSON Web Token），用户登录成功后后端生成Token返回给前端，前端后续的每次请求都在Header里携带这个Token，后端通过拦截器校验身份。这个方案比传统的Session方案更适合前后端分离，因为后端的接口不依赖浏览器的Cookie，理论上可以给任何客户端使用。

1.3 整体功能模块划分

系统按用户角色分为两类：普通学生用户和管理员。

普通用户端的功能包括：

注册/登录、个人信息维护、头像上传
浏览校园周边美食店铺、查看美食详情
按分类/关键词/评分筛选店铺
发布美食图文分享帖，为其点赞、收藏、评论
收藏喜欢的店铺或帖子，在我的收藏中统一查看
查看其他用户的评价和评分

管理员端的功能包括：

用户管理：查看用户列表、禁用违规账号
店铺管理：审核新店铺入驻信息、编辑店铺资料、下架违规店铺
内容管理：审核美食帖子、删除违规评论
数据统计：查看平台用户数、店铺数、帖子数等基础数据

从这个功能列表能看出，项目的核心业务逻辑全部集中在“店铺信息管理”和“用户分享互动”这两条主线上。店铺是内容基础，用户分享是内容增量，从而形成“先有内容冷启动，再靠UGC丰富生态”的闭环。

2. 数据库设计与核心模块解析

2.1 核心数据表结构设计

数据库设计是整个项目最值得花时间的地方。表结构一旦定下来，后面的接口开发都只是“照方抓药”。这个项目大概设计了8张核心表，这里挑几张重点的表讲设计思路。

用户表（sys_user）

字段名	类型	说明
id	bigint	主键，自增
username	varchar(50)	登录账号，唯一索引
password	varchar(100)	BCrypt加密后的密码
nickname	varchar(50)	昵称
avatar	varchar(255)	头像URL
role	tinyint	角色：0普通用户 1管理员
status	tinyint	状态：0正常 1禁用
create_time	datetime	注册时间

密码加密这里特别说一下。很多学生项目直接用明文存密码，答辩时被老师一问“用户密码泄露怎么办”直接哑口无言。这个项目用Spring Security自带的BCryptPasswordEncoder做加密，每次加密结果都不一样，但校验时又能正确匹配。实现上就一行代码，却能让系统在安全性方面的评分大幅提升。

店铺表（shop）

字段名	类型	说明
id	bigint	主键
shop_name	varchar(100)	店铺名称
category_id	bigint	分类ID，关联分类表
address	varchar(255)	具体地址
longitude/latitude	decimal(10,6)	经纬度坐标
avg_score	decimal(2,1)	平均评分
avg_price	decimal(8,2)	人均消费
cover_image	varchar(255)	封面图
description	text	店铺简介
status	tinyint	状态：0待审核 1已上架 2已下架
create_time	datetime	创建时间

店铺表是平台的基础数据表，经纬度字段的引入为后续的“附近美食”功能预留了能力。虽然这个项目在最终版本里没有做真正的LBS实时距离计算，但经纬度字段存在，接口就可以通过简单的距离公式在用户设定范围内筛选店铺。

美食帖子表（post）与评论表（comment）

帖子表是核心的内容载体，字段包括id、用户id、店铺id、标题、正文内容、图片列表（用JSON字符串存储多个图片URL）、点赞数、收藏数等。评论表则是经典的父子结构：id、用户id、帖子id、内容、父评论id、回复目标用户id、创建时间。用父评论id来支持楼中楼回复，前端展示时递归组装评论树即可。

值得注意的一个设计细节是：帖子表中的“点赞数”和“收藏数”属于冗余字段。正常的做法是每次查询时COUNT点赞表里的记录，但这种方式在列表页会频繁触发聚合查询，性能不好。这里的替代方案是：在点赞/收藏的service方法里做事务操作，每次点赞成功就同步更新帖子表的like_count加一，取消则减一。这样列表页直接查整数字段就能展示，性能明显更优。代价是数据一致性存在短窗口风险，但在课程设计场景中完全够用。

2.2 业务难点：评分聚合与排序

美食平台里最核心的业务逻辑之一是轮均评分。用户在帖子中给店铺打了1到5分的评分，一个店铺的评分来自多个用户，要用平均值聚合并保持展示一致性。

这个功能如果写得草率，很容易出现“评分明明改了但列表页不更新”的bug。这个项目的实现方案是：用户提交评分时，服务层在一个事务里完成两件事——插入评分记录，同时重新计算该店铺所有评分的平均值并更新shop表的avg_score字段。这里用了一个带条件更新锁的做法：UPDATE shop SET avg_score = (SELECT AVG(score) FROM rating WHERE shop_id = ?) WHERE id = ?。因为MySQL的UPDATE语句在事务中会锁行，可以避免并发场景下两个用户同时评分导致平均值计算错乱。

排序逻辑上，列表页支持按“综合排序”（默认）、评分最高、价格最低、最新发布四种方式排序。综合排序采用的规则是：评分权重占60%，热度（点赞数+收藏数）占40%，换算成分数后排序。虽然在答辩时可以强调这种加权算法是“特色的推荐策略”，但本质上这是一种简单有效的人工规则排序，不需要机器学习就能实现。

2.3 搜索与筛选的SQL实现

搜索功能是对一个“内容平台”是否实用的基本检验。这里的搜索不是简单的LIKE模糊匹配，而是做了三个维度的条件组合：

关键词搜索店铺名称、描述或美食帖子标题
分类筛选（火锅、烧烤、快餐、奶茶等）
按价格区间过滤（人均10-20元、20-40元、40元以上）

MyBatis-Plus提供的LambdaQueryWrapper只能处理简单的等值查询，遇到这种“关键词不为空则匹配，价格区间不为空则过滤”的动态SQL场景，手写XML更合适。核心SQL片段的实现类似这样一个结构：

<select id="selectShopList" resultType="com.demo.entity.Shop"> SELECT * FROM shop <where> <if test="keyword != null and keyword != ''"> AND (shop_name LIKE CONCAT('%', #{keyword}, '%') OR description LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="minPrice != null"> AND avg_price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND avg_price &lt;= #{maxPrice} </if> AND status = 1 </where> ORDER BY <choose> <when test="sortType == 'score'">avg_score DESC</when> <when test="sortType == 'price'">avg_price ASC</when> <when test="sortType == 'newest'">create_time DESC</when> <otherwise>score_weight DESC</otherwise> </choose> </select>

这个写法看起来简单，但其实是从需求到SQL转换的关键一步。<where>标签会自动去除第一个条件前的多余AND，<choose>标签实现多选一的排序字段，既防住了SQL注入，又保证了动态拼SQL的灵活性。

3. 后端核心实现与关键代码解析

3.1 统一响应体与全局异常处理

开发前后端分离项目，最怕的就是联调时出现“接口返回格式前后端各有一套”的情况。项目开发初期就规定所有接口的返回数据格式必须统一：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

与之配套的还有全局异常处理。利用Spring MVC的@RestControllerAdvice注解统一捕获异常，业务异常返回对应的错误码，未知异常返回500。这样前端Axios响应拦截器就可以统一根据code值做提示，不需要每个接口单独写错误处理逻辑。

这个设计的价值在真实开发中才会显现：一旦接口数量超过50个，如果每个接口都写一套返回逻辑，代码会显得相当凌乱，而且极易出错。全局统一处理能从架构层面避免这个问题。

3.2 基于JWT的登录与权限控制

登录认证这部分踩过不少坑，这里把最终版本的实现思路完整说明一下。

用户登录成功后，后端生成JWT返回。JWT的payload部分放userId和role，签名密钥配置在application.yml中。为了避免Token被篡改，签名时用了HMAC-SHA256算法——这个选择的关键原因是它是对称算法，同一个密钥负责签名和验签，在单体应用里配置和部署都比较简单。

public String generateToken(Long userId, Integer role) { return Jwts.builder() .setSubject(userId.toString()) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }

Token有效期设置为7天。这个时长对学生用户来说比较友好——不用天天登录，同时也能保证一定的安全性。一个需要对所有需要登录才能访问的接口生效的拦截器，在WebMvcConfig中注册拦截器并排除登录、注册、首页列表等公开接口。拦截器里解析Token失败直接返回401状态码，前端收到后跳转到登录页。

这个流程里有一个容易被忽略的细节：拦截器放行的URL列表必须写在配置里维护好。如果某个接口漏加了拦截，前端调用时会一直报401，排查起来会有点绕——得先从拦截器配置查起，再考虑是不是代码本身的问题。

3.3 文件上传与图片访问

美食分享平台最绕不开的环节就是上传美食照片。前端用Element UI的el-upload组件把图片以multipart/form-data格式POST到后端/api/upload接口，后端接收文件后执行三个操作：校验文件类型和后缀、生成唯一的文件名（UUID替换掉-），然后存储到服务器磁盘指定目录，最后返回可访问的图片URL。

项目在开发环境下直接把图片存在了项目的/upload目录，并通过配置类映射成虚拟路径，这样外部通过http://localhost:8080/upload/xxx.jpg就能访问到图片。但部署到生产服务器或者服务器上时，这种存本地磁盘的方式磁盘空间有限。课程设计场景下，一个更稳妥的替代方案是接入阿里云OSS或腾讯云COS对象存储。如果答辩时想展示自己“有生产意识”，把这个存本地的实现换成云存储是很加分的。一个补充点：文件类型校验不要只看前端传来的文件后缀名，后端需要对文件头（magic number）做二次校验，防止有人伪造扩展名上传恶意文件。

3.4 点赞、收藏与关注的事务边界

点赞、收藏这两个功能看着简单，但它们都涉及“多表联动更新”事务。以点赞为例：插入like_record之前，首先要判断该用户是否已经对这条帖子点过赞，如果已点赞则提示“请勿重复点赞”，如果没有则插入记录并使post表的like_count加一。同时用户取消点赞时，操作恰好是相反。

这个逻辑存在一个并发问题：如果同一个用户快速点了两次“点赞”，两个请求同时到达，都通过了“是否已点赞”的判断，结果就会插入两条点赞记录，点赞数也会加两次。解决方式是在like_record表上建一个(user_id, post_id)的唯一索引，然后在代码中捕获插入时的DuplicateKeyException，这样即使并发请求穿过判断逻辑，数据库层面的唯一约束也能兜住重复数据。插入成功再更新计数，插入冲突则直接返回友好提示。

这个方案算是数据库约束兜底加业务层判断的双保险。答辩时能解释清楚这一层，会是一个加分点。

4. 前端页面构建与交互逻辑

4.1 页面结构与路由设计

前端项目用Vue CLI构建，按功能模块拆分页面：

首页：店铺列表流、搜索栏、分类导航、轮播图推荐位
店铺详情页：店铺基础信息、图文介绍、用户评分分布、位置展示
美食帖子详情页：帖子内容、配图、点赞/收藏按钮、评论楼
用户个人中心：我的资料、我的帖子、我的收藏、我的评论
管理员后台：仪表盘统计数据、用户管理表格、店铺审核表格、帖子管理表格

整套前端没有做复杂的权限控制，管理员和普通用户登录后看到的导航菜单不同，管理后台的每个接口后端都会校验role，所以前端隐藏路由菜单只算“体验优化”，真正拦截在API层面。

有个地方往往容易出问题：Vue Router的History模式在刷新页面时容易返回404，必须在后端配置路径转发。但开发阶段为了省事可以直接用Hash模式——虽然URL里带个#看起来不美观，但省掉了部署时的坑。课程设计其实不太建议花时间在History模式上。

4.2 前端关键交互的实现思路

首页的无限滚动加载用的是Element UI的el-scrollbar监听滚动到底部事件，触发下一页数据的加载。这个逻辑需要配合一个“正在加载中”的锁，避免并发触发多次请求。实现不难但细节不少：滚动到底部触发的阈值要设成50px，等滚动非常接近底部时再加载；新加载的数据要追加而不是覆盖，同时更新页码。

评价分数的展示采用“星级评分 + 进度条”的组合。星级评用Element UI自带rate组件，让用户点击出1-5分；店铺详情页的评分分布用el-progress展示每个分数段的人数占比。这对用户体验的作用很实在——看到“4星及以上占比80%”的评价分布，对决策有真正的参考价值。

4.3 前后端联调的细节

前后端分离项目有一半的时间耗在联调和排查上。开发阶段需要开启Vue的代理转发，解决跨域问题。在vue.config.js中配置devServer代理：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, ws: true } } }

这样前端页面里的请求地址写成/api/shop/list，浏览器发出请求后由Vue的开发服务器转发到后端，浏览器的同源策略就不会拦截。但这样部署到生产环境时就不行了，Nginx层面还需要做反向代理，让/api前缀的请求转发到后端服务端口。

联调阶段另一个常见的问题是对接口返回数据结构理解不一致。Excel或思维导图里约定的字段叫shopName，后端返回的数据里如果变成长下划线shop_name，前端取的shopName就会是undefined。这个项目里最稳妥的办法是后端实体属性使用驼峰命名，Jackson默认将驼峰转成驼峰返回，不额外配置下划线转换规则。凡是涉及字段名的地方，前后端最好用同一份接口文档来对齐，减少不必要的返工。

5. 推荐逻辑与平台特色功能实现

5.1 基于简单权重的店铺评分推荐

平台没有去做复杂的协同过滤推荐算法，而是设计了一套“简单权重得分”逻辑。每个店铺会计算一个综合权重分，公式如下：

综合得分 = 平均评分 * 60 + 热度得分 * 40 热度得分 = (点赞总数 + 收藏总数) / 店铺帖子数

在SQL层面用一个计算字段实现：

SELECT shop.*, (avg_score * 0.6 + (IFNULL(like_count, 0) + IFNULL(fav_count, 0)) / IFNULL(post_count, 1) * 0.4) AS weight_score FROM shop ORDER BY weight_score DESC

这个公式的逻辑是：评分高但没热度的店铺，权重不一定高；热度高但评分低的店铺也不会上位；只有评分和热度都高的店铺会稳定排在前列。作为一个课程设计项目，“推荐算法”这套东西能讲到“权重设计思路”已经够用了，老师通常也不会再追着问协同过滤怎么实现。

5.2 “附近美食”的坐标计算策略

店铺表里存了经纬度后，可以顺带实现一个“距离排序”。核心逻辑是地球球面两点之间的距离公式（Haversine公式）。考虑到校园周边的范围一般只有几公里，直接用一个简化公式就够了：

SELECT shop.*, ROUND(6371 * 2 * ASIN(SQRT( POWER(SIN((#{lat} - latitude) * PI() / 360), 2) + COS(#{lat} * PI() / 180) * COS(latitude * PI() / 180) * POWER(SIN((#{lng} - longitude) * PI() / 360), 2) )), 2) AS distance FROM shop HAVING distance < 5 ORDER BY distance ASC

这个SQL在主列表上逐行计算，数据量较小的时候没问题。当店铺量增大，性能会慢慢吃力，后续优化方向是使用空间索引或者改用PostGIS。课程设计里，如果知道怎么用这个公式、怎么按距离筛选，已经算想得比较周到了。

6. 项目部署步骤与常见问题排查实录

6.1 从代码到运行的完整部署流程

整个项目从拿到代码到在本地完整跑起来，按这个顺序去操作会比较顺：

安装并启动MySQL 8.0，创建一个数据库实例，例如campus_food，导入项目提供的SQL文件，里面包含建表语句和初始数据。
检查后端项目的application.yml配置文件，确认数据库名称、账号、密码和本地环境一致。特别注意MySQL连接URL中的serverTimezone=Asia/Shanghai参数，时区不对会导致数据时间相差8小时。
在IntelliJ IDEA中打开后端项目，等待Maven下载完依赖后，直接运行启动类。看到控制台打印出“Started Application”即启动成功。
前端项目用Visual Studio Code打开，安装依赖：npm install。这个步骤耗时较长，有时候会出现安装失败的报错，可以换用国内npm镜像源重试。
启动前端开发服务：npm run serve。浏览器访问http://localhost:8081，看到系统首页说明前后端开发环境已经联通。

部署到服务器上的时候，后端代码需要打成JAR包，上传到服务器后用java -jar方式运行，前端执行npm run build构建出dist目录，然后让Nginx托管dist目录并配置反向代理。具体Nginx的配置可以这样写：

server { listen 80; server_name your_server_ip; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /upload/ { proxy_pass http://127.0.0.1:8080/upload/; } }

图片上传路径也要保持一致。生产环境中后端图片存储的目录建议独立挂在JAR包以外的位置，因为JAR包启动时user.dir指向的是JAR包所在目录，直接存在相对路径下容易出问题，而且升级版本时可能会覆盖掉用户上传的旧图片。

6.2 典型问题与排查手段速查表

现象	可能原因	排查/解决方式
前端请求接口返回404	跨域未生效/代理没配置对	检查vue.config.js代理配置，确认接口前缀与target端口一致
前端请求返回401	Token过期或未携带	清浏览器缓存重新登录，检查Axios请求拦截器是否添加了Authorization头
图片上传成功但访问404	图片虚拟路径映射未配置	检查WebMvcConfig里对upload目录的静态资源映射配置
中文乱码	数据库连接URL未指定字符集	URL里增加`useUnicode=true&characterEncoding=utf8mb4`
日期字段差8小时	MySQL连接时区未指定	URL增加`serverTimezone=Asia/Shanghai`
npm install失败	网络源太慢或依赖冲突	切换国内npm镜像源，删除node_modules和package-lock.json重装
后端启动时端口占用	8080端口被其他程序占用	修改application.yml的server.port，或者找出占用进程结束它

6.3 答辩时容易被追问的细节

答辩环节老师比较关注是否有独立思考和动手能力，下面的几个点作为整理素材参考：

为什么用JWT不用Session：因为前后端分离，前端部署在另一个端口，Session的Cookie无法跨域传递，JWT无状态、可跨域，适配性更好。
密码安全：BCrypt加密是单向哈希，每次结果不一样，但可以通过内部算法验证匹配。就算数据库泄露，密码也不能被直接还原。
事务控制：涉及点赞数、收藏数、评分等联表更新的操作都用了@Transactional注解，保证数据一致性。点赞重复调用则用唯一索引兜底。
如果数据量增大怎么办：首页查询加索引、分页限制后端每次都只查10条，后续可以引入Redis做缓存，降低数据库压力。

7. 一些过来人的建议

这个项目做完，最大的感悟是：代码量并不是衡量一个课程设计好坏的唯一标准，思路清晰与否、逻辑能否自洽更重要。从选题到最终答辩，最耗费时间的地方往往不在写代码，而在“想清楚业务”——比如评分怎么聚合、排序用什么规则、点赞怎么防重，这些设计层面的取舍才是真正让人成长的部分。

如果要给后来者一个方向参考，可以从这几个点入手：先把MySQL表结构设计好，表结构是业务逻辑的骨架；再把接口文档写清楚，前后端联调才顺；最后才是动手写代码。很多人习惯一上来就写后端接口，写到一半又要回头改表结构，改表结构又牵动前端，返工成本翻倍。

技术选型方面，这个项目用了Spring Boot + MyBatis-Plus + Vue的组合，这只是众多可行方案中的一种。如果换成Spring Cloud、Redis、RabbitMQ甚至微服务，能展示的技术面会更广一些，但也意味着需要投入更多时间和精力去理解那些框架的底层运行机制。做课程设计，不要为了炫技而堆技术栈。把一个简单技术栈做到逻辑自洽、边界清晰，本身就是一项很好的能力证明。

最后分享一个小建议：文档和答辩PPT不要最后几天突击写，平时每做完一个功能，顺手把设计思路和踩坑记录写到项目的README或者笔记里。等到写论文、准备PPT的时候，这些碎片化记录就是第一手素材，省去回忆和重构的时间。做项目的过程本身也是学习和积累的过程，认真记录，收益不在眼前，而在长远。