SpringBoot2+Vue3校园美食分享平台开发实战：从技术选型到部署-开发者社区

1. 校园美食场景下的需求拆解：这个平台到底要做什么

先说下我为什么会对这个项目感兴趣。校园周边的美食生态和普通外卖平台、点评软件完全是两回事——学生群体高度集中，口碑传播极快，一份食堂二楼的麻辣香锅好不好吃，三天内就能传遍整个年级群。但市面上的大众点评、小红书对校园场景覆盖非常粗糙，很多藏在巷子里的宝藏小店评分不高、信息陈旧，学生想找"附近适合聚餐的烧烤店"或者"便宜大碗的盖浇饭"，根本搜不到有效结果。这就是校园周边美食探索及分享平台存在的核心价值：用学生自己的真实分享，去覆盖那些大平台看不上的小型餐饮生态。

从产品功能角度看，这个平台的核心需求可以拆成四个板块：

美食探索：基于校园地理位置，展示周边店铺信息，支持分类筛选（快餐、火锅、奶茶、甜品等）、关键词搜索、按距离或评分排序。
分享交流：用户发布探店帖子，包含图文、评分、人均消费、地址定位，其他用户可以评论、点赞、收藏。
个人中心：维护自己发布的帖子、收藏列表、点赞记录，以及基本的个人资料。
管理后台：对店铺信息、帖子内容进行审核和管理，处理违规内容，维护分类字典。

这类项目在学生群体中的传播逻辑很有意思——它不像电商平台靠算法推荐，而是靠圈层信任。所以设计的时候，帖子的社交属性要强，店铺信息要精准，操作路径要短。一个学生看到同学分享的帖子，点进去看到店铺位置和人均价格，觉得不错，顺手收藏，这就是一个完整闭环。

如果你是准备做毕业设计或者课程项目，这套需求规模也刚刚好：既有常规的CRUD，又有社交互动、文件上传、检索排序这类可以展开讲技术点的模块，工作量可控，但又不至于太单薄。

2. 技术选型背后的取舍：为什么是SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0这套组合

很多人在选技术栈的时候容易陷入一个误区——什么新用什么，或者别人用什么我就用什么。但实际上，校园美食分享平台这种体量的项目，技术选型最重要的标准是"正好够用且生态成熟"。这套组合能成为主流，不是偶然的。

2.1 SpringBoot2：稳定压倒一切

可能有人会问，现在SpringBoot3都出来这么久了，为什么还要用SpringBoot2？我的看法是，SpringBoot2.7.x是目前生产环境里存量最大、踩坑资料最全的版本。SpringBoot3强制要求JDK17，而很多学校机房、云服务器、老旧教程都还是JDK8的环境。如果你做的是毕业设计，导师机器上可能装的就是JDK8，用SpringBoot2能省掉一堆环境兼容性的麻烦。

从功能上来说，SpringBoot2自带的内嵌Tomcat、自动配置、Starter机制，对这个项目完全够用。唯一需要注意的是，选择SpringBoot2.7.x这个末代版本，这样既能兼容JDK8，又能享受到接近SpringBoot3的一些API改进。

2.2 Vue3：组合式API带来的开发体验提升

Vue3相比Vue2最核心的变化是组合式API（Composition API）。做美食分享平台这种中后台+用户端混合的项目，组合式API最大的优势是逻辑聚合。比如一个"发布帖子"页面，涉及到表单校验、图片上传、定位获取三个逻辑，用Vue2的Options API，这三个逻辑的相关代码会散落在data、methods、watch里；而用Vue3的setup语法，可以把它们组织成三个独立的函数模块，代码可读性和维护性直接提升一个档次。

再加上Vite带来的秒级热更新，开发体验确实比Vue2时期舒服太多。Vue3配合Element Plus组件库，后台管理的表格、表单、弹窗这些组件基本开箱即用。

2.3 MyBatis-Plus：单表CRUD的减法

这个项目如果纯用MyBatis，你会发现代码量最大的部分不是业务逻辑，而是重复的增删改查SQL。MyBatis-Plus解决的就是这个问题——单表操作不需要写SQL，继承一个BaseMapper接口就自带insert、deleteById、selectPage等常用方法。

当然，MyBatis-Plus不是万能的，多表关联查询、复杂子查询还是得老老实实写XML。但它能把整个项目里大概70%的重复SQL省掉，让代码量直接减半。配合它的分页插件，列表页的分页查询一行代码就能搞定，不用再手写LIMIT和COUNT。

2.4 MySQL8.0：被低估的升级点

很多人从5.7迁移到8.0没有感觉，但实际上MySQL8.0在这类项目里有几个实打实的优势：

默认字符集utf8mb4：Emoji表情可以直接存储。美食分享的评论里，学生最爱用表情，5.7时代经常遇到表情存不进去的报错，8.0默认就支持。
窗口函数：比如想计算"每个分类下评分最高的店铺"，用窗口函数一条SQL就解决，5.7要写复杂的子查询。
性能优化：8.0的优化器比5.7更智能，索引条件下推、哈希连接这些特性在处理多表关联时表现更好。

2.5 那些"没选"的技术，为什么没选

这套技术栈的合理性，还要看主动放弃的技术。比如不引入Redis：这个项目的数据量级，MySQL加适当索引完全能扛住。引入Redis意味着要处理缓存一致性、缓存穿透、序列化配置一堆问题，对项目核心价值没有增量贡献。比如不做前后端分离以外的高级架构：不搞微服务、不搞消息队列，一个单体应用SpringBoot足够。有些同学为了简历好看硬上微服务，结果部署的时候光服务注册发现就折腾一周，本末倒置。

利用好这套技术组合，需要重点关注的是技术栈之间的协调配合。比如前端Vite代理解决跨域、后端统一响应结构、数据库连接池配置、分页插件配置，这些"胶水代码"往往才是项目能否顺利跑起来的关键。

3. 数据模型设计的几个关键决策：从ER图到核心表结构

美食分享平台的数据模型，核心是用户—店铺—帖子这三类实体之间的关系。这个设计质量直接决定了后面所有功能的开发效率。

3.1 核心表结构设计思路

按照典型的校园美食平台，数据表基本围绕以下几个主题展开（以下表名为常见实践命名，实际项目可自行调整）：

sys_user（用户表）：id、username、password、nickname、avatar、role（区分普通用户/管理员）、status、create_time。密码字段存的是BCrypt加密后的密文，不是明文。
shop（店铺表）：id、shop_name、category_id（所属分类）、address、latitude、longitude、avg_price（人均消费）、shop_desc、score（综合评分）、open_status、create_time。地理位置字段一定要存经纬度，后面做距离排序时必须用。
post（帖子表）：id、user_id（发帖人）、shop_id（关联店铺）、title、content、images（图片URL列表，用逗号分隔或JSON格式）、rating（评分）、create_time、status（待审核/已发布/已下架）。
post_comment（评论表）：id、post_id、user_id、content、create_time。
post_like（点赞表）：id、post_id、user_id、create_time。设计上要加唯一约束（post_id + user_id），防止重复点赞。
favorite（收藏表）：id、user_id、post_id/shop_id、create_time。收藏维度可以是收藏帖子，也可以是收藏店铺，看你的业务定义。
shop_category（店铺分类表）：id、category_name、sort_order。

3.2 为什么店铺和帖子要分表

设计上有两个选择：一是把店铺信息直接嵌入到帖子里，另一种是独立的店铺表。我的建议是独立店铺表，原因有三个：

一个店铺可以被多个帖子关联。同一个食堂窗口，今天有人发"踩雷贴"，明天有人发"推荐贴"，如果店铺信息嵌在帖子里，数据就冗余了。
店铺有独立的状态和属性。比如"暂停营业""已搬迁"，这些状态应该维护在店铺维度，而不是跟着帖子走。
后续扩展方便。如果以后想加"店铺收藏""店铺打卡"这些功能，独立表可以直接支持。

当然，独立的店铺表也有代价——发帖时要先选择或创建店铺，流程上多一步。我的做法是在前端做一个店铺搜索联想：输入店名，如果在数据库里找到了就直接关联；找不到就弹出一个快速创建店铺的对话框，填完基础信息后自动关联。

3.3 索引设计：别等数据量大了再后悔

这个项目数据量不会太大，但索引设计还是不能马虎。几个关键索引：

posts.shop_id + create_time：查询某个店铺下的所有帖子，按时间倒序。这是帖子详情页最频繁的查询。
posts.user_id + create_time：查看某个用户发布过的帖子，在个人中心展示。
comments.post_id：根据帖子查评论列表。
favorites.user_id：查询某个用户的收藏列表。

MySQL8.0支持降序索引，如果你经常按时间倒序查询，建索引的时候可以写成KEY idx_shop_time (shop_id, create_time DESC)，8.0会真正利用降序索引，不需要额外排序过程。

3.4 评分字段怎么存更合理

店铺的评分（score）有两种设计方式：一是在shop表里直接维护一个总评字段，发帖时更新平均值；二是每次动态计算。

直接在shop表里存一个score字段，发帖时带上评分，然后更新店铺表里score的加权平均值，这是一种做法。好处是查询列表页时直接秒出，不用聚合计算。坏处是每次发帖要额外更新店铺表，还要考虑并发问题。

我的建议是折中：店铺表存一个冗余的score和rating_count字段，每发一个新帖就重新计算：new_score = (old_score * rating_count + current_rating) / (rating_count + 1)。这样列表查询快，准确性也够。

4. 后端核心板块的落地：从登录鉴权到美食帖子的完整链路

后端的实现，我挑几个最有代表性的模块来讲讲具体的实现逻辑和其中的坑。

4.1 用户登录与JWT鉴权

现在的主流方案是JWT（JSON Web Token）。登录成功后，后端生成一个token返回给前端，前端存在localStorage里，之后每次请求都在Header里带上Authorization: Bearer token。

后端用一个拦截器（HandlerInterceptor）统一校验token：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册等不需要鉴权的接口 String uri = request.getRequestURI(); if (uri.contains("/auth/login") || uri.contains("/auth/register")) { return true; } // 从Header获取token String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); try { // 解析token，获取用户ID，存入request attribute Long userId = JwtUtil.parseToken(token); request.setAttribute("userId", userId); return true; } catch (Exception e) { // token过期或非法 } } response.setStatus(401); return false; } }

JWT的密钥要放到配置文件里，不要硬编码在代码中。token过期时间建议设24小时，配合前端路由守卫，过期后自动跳回登录页重新登录。

4.2 帖子发布流程：从提交到上架的完整链路

发布一个美食帖子，前端提交过来的数据包括：标题、正文内容、图片列表、评分、关联的店铺ID。后端处理流程：

参数校验：标题不能为空，正文长度在10~5000字之间，图片不超过9张，评分在1~5之间。
内容安全审查：检查帖子内容是否包含违规关键词。校园平台可以直接用AC自动机算法做一个敏感词过滤器，几行代码就能实现，比调用第三方接口更可控。
图片处理：前端上传的图片已经传到了文件服务器（或本地磁盘），后端只需拿到URL列表，拼成JSON字符串存入posts.images字段。
状态设置：新发布的帖子status默认是0（待审核），管理员审核通过后才变为1（已发布）。如果你不想做审核流程，也可以直接发布，但一般建议至少有个简单的敏感词拦截。
更新店铺评分：按前面说的加权平均公式更新店铺表的score字段。

这里面有一个很容易被忽略的细节：帖子发布过程涉及到写多张表（插入帖子、更新店铺评分）。如果不用事务，中途一旦出错就会出现数据不一致——帖子插入成功但评分没更新。所以必须在Service方法上加@Transactional注解，确保原子性。

4.3 美食探索的检索逻辑：分类、关键词、排序

列表页是整个平台流量最大的入口，查询逻辑要兼顾灵活性和性能。用MyBatis-Plus的LambdaQueryWrapper或者XML自定义SQL都行，核心的查询条件：

分类筛选：让用户选择分类ID，SQL条件就是WHERE shop.category_id = ?。
关键词搜索：搜索店铺名称和帖子标题，用LIKE CONCAT('%', #{keyword}, '%')。注意，不要用LIKE '%${keyword}%'直接拼接，会有SQL注入风险。
排序规则：支持综合排序、评分最高、距离最近、最新发布。

距离排序需要用到经纬度计算。MySQL8.0支持空间数据类型，也支持经纬度距离计算函数：

SELECT *, ST_Distance_Sphere(POINT(#{lng}, #{lat}), POINT(longitude, latitude)) AS distance FROM shop ORDER BY distance ASC

ST_Distance_Sphere返回的是米为单位的距离，如果店铺数据量在几千级别，这个计算的开销完全可以接受。只有达到十万级以上才需要考虑Geohash或者空间索引优化。

4.4 点赞与收藏：防重复是重点

点赞和收藏这两个功能看起来简单，但实际开发中很容易踩坑。核心问题是重复操作。

前端用户手一抖点了两次点赞按钮，或者用户先点赞再取消再点赞，如果后端不做幂等处理，赞数就乱了。我用的方案是：在点赞表(post_like)上建立UNIQUE KEY uk_post_user (post_id, user_id)，数据库层面的唯一约束，然后用"先查再插"的逻辑：

@Transactional public Result toggleLike(Long postId, Long userId) { // 查询是否已点赞 LambdaQueryWrapper<PostLike> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(PostLike::getPostId, postId).eq(PostLike::getUserId, userId); PostLike like = postLikeMapper.selectOne(wrapper); if (like == null) { // 未点赞，执行点赞 PostLike newLike = new PostLike(); newLike.setPostId(postId); newLike.setUserId(userId); postLikeMapper.insert(newLike); // 帖子点赞数+1 postMapper.increaseLikeCount(postId); return Result.success(true); } else { // 已点赞，执行取消 postLikeMapper.deleteById(like.getId()); postMapper.decreaseLikeCount(postId); return Result.success(false); } }

这里把插入操作包在事务里，如果并发请求同时插入，唯一约束可以直接兜底抛异常，不会产生脏数据。

5. 前端Vue3部分的组织方式：从页面划分到状态管理

Vue3前端部分的代码组织，直接关系到开发效率和后续维护的难易度。

5.1 页面结构设计

按照功能模块，前端页面可以划分为：

首页（Home）：顶部是搜索栏和分类导航，下方是美食帖子信息流。推荐用瀑布流布局展示卡片式帖子，每个卡片展示封面图、标题、评分、人均价格、距离信息。
店铺列表页（ShopList）：以列表形式展示所有店铺，支持分类筛选和排序切换。
店铺详情页（ShopDetail）：展示店铺基本信息、地图位置、关联的所有帖子。
帖子详情页（PostDetail）：展示帖子的完整图文内容、发帖人信息、评论区。
发布页（PostCreate）：表单+图片上传+店铺选择，是操作最复杂的一个页面。
个人中心（Profile）：展示我的资料、我发布的帖子、我的收藏、我的点赞。
后台管理（Admin）：用Element Plus搭建的管理界面，包括用户管理、帖子审核、店铺管理、分类管理。

前端路由用Vue Router，需要做权限控制：后台管理相关路由需要登录且角色为管理员。

5.2 用Pinia做状态管理

Vue3配套的状态管理库是Pinia，相比Vuex更简洁。这个项目里需要全局共享的状态不多，主要就是当前登录用户信息：

// stores/user.js import { defineStore } from 'pinia' export const useUserStore = defineStore('user', { state: () => ({ token: localStorage.getItem('token') || '', userInfo: JSON.parse(localStorage.getItem('userInfo') || '{}') }), actions: { setLoginInfo(token, userInfo) { this.token = token this.userInfo = userInfo localStorage.setItem('token', token) localStorage.setItem('userInfo', JSON.stringify(userInfo)) }, logout() { this.token = '' this.userInfo = {} localStorage.removeItem('token') localStorage.removeItem('userInfo') } } })

LocalStorage和Pinia双写的原因：Pinia是内存态，刷新页面就丢了；LocalStorage是持久层。刷新时从LocalStorage恢复，运行中直接读Pinia，这样保证速度和持久性兼得。

5.3 Axios封装的关键细节

Axios封装的好坏，直接影响开发体验。我习惯把请求拦截器、响应拦截器、统一的BaseURL、错误处理都放在一个request.js文件里：

// utils/request.js import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', // 结合Vite代理配置 timeout: 10000 }) // 请求拦截器：自动携带token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { ElMessage.error('登录已过期，请重新登录') // 清除登录信息，跳转登录页 localStorage.clear() router.push('/login') } else { ElMessage.error(error.message || '网络错误') } return Promise.reject(error) } )

注意baseURL: '/api'，这是Vite代理的入口，解决前后端联调时的跨域问题。在vite.config.js里这样配置：

export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', // 后端地址 changeOrigin: true, rewrite: path => path.replace(/^\/api/, '') } } } })

这样前端代码里请求/api/shop/list，Vite开发服务器会把请求转发到http://localhost:8080/shop/list，浏览器端看是同源请求，不会跨域。

5.4 图片上传组件的实现

图片上传是发布帖子里最复杂的交互。我的做法是用Element Plus的Upload组件，配合自定义上传逻辑：

<el-upload action="/api/upload" name="file" :headers="uploadHeaders" list-type="picture-card" :limit="9" :on-success="handleUploadSuccess" :on-remove="handleRemove" > <el-icon><Plus /></el-icon> </el-upload>

后端提供一个统一的文件上传接口，接收MultipartFile，保存到服务器指定目录（或OSS），返回文件的访问URL。上传接口要注意文件类型校验和大小限制，图片建议限制在5MB以内，防止用户上传超大文件打满磁盘。在后端配置文件里：

spring: servlet: multipart: max-file-size: 5MB max-request-size: 50MB

6. 本地环境搭建与部署过程中踩过的真实坑

环境搭建和部署是另一个大坑点，尤其是MySQL8.0和Vue3的组合。我把项目中可能踩到的常见问题集中整理一下。

6.1 MySQL8.0的驱动和时区问题

用MySQL8.0，数据库驱动要换成com.mysql.cj.jdbc.Driver：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_food?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 你的密码

这里有两个非常容易踩的坑：

serverTimezone=Asia/Shanghai必须加。MySQL8.0默认时区和中国差8个小时，不加这个参数，你存入数据库的时间会比实际时间少8小时。
allowPublicKeyRetrieval=true必须加。MySQL8.0默认使用caching_sha2_password认证插件，某些JDBC驱动版本在第一次连接时需要通过公钥交换密钥，不加这个参数会报Public Key Retrieval is not allowed错误。

6.2 Navicat连接MySQL8.0失败

如果你用Navicat连接MySQL8.0，很可能会遇到Client does not support authentication protocol requested by server这个错误。原因是MySQL8.0默认的caching_sha2_password认证插件太新，老版本的Navicat不支持。

解决办法有两种：

升级Navicat到16以上的版本，全面支持MySQL8.0。
修改用户认证插件为mysql_native_password：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码'; FLUSH PRIVILEGES;

第二种方法可以让老版本Navicat直接连上，但如果你的项目也碰到这个兼容问题，确保JDBC连接和Navicat的一致性。

6.3 MyBatis-Plus分页插件不生效

很多人配好了MyBatis-Plus，但发现selectPage返回的数据total总是0，或者分页的LIMIT没生效。原因是没配置分页插件拦截器。MyBatis-Plus的3.x版本需要显式添加配置类：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

没有这个拦截器，selectPage出来的total就是0，LIMIT不会真正拼进SQL。

6.4 Vue3项目部署到Nginx后页面刷新404

本地开发一切正常，打包部署到Nginx后，访问首页没问题，但是一旦点击路由跳转后刷新页面，就报404。这是前端路由的history模式导致的——Nginx没有配置try_files去fallback到index.html。

在Nginx的server配置里加上：

location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; }

这样刷新的时候，Nginx发现找不到对应的静态文件，就会转回index.html，交给Vue Router自己去匹配路由。

6.5 文件上传后访问不到图片

如果你把上传的图片保存到了本地磁盘，比如/www/upload/目录，但前端访问http://yourdomain.com/upload/xxx.jpg时报404，原因一般是Nginx没有把/upload路径映射到磁盘目录。需要在Nginx配置里加一个静态资源映射：

location /upload/ { alias /www/upload/; }

或者更简单的方案，把图片也放到SpringBoot的static目录下，由后端统一托管。但要注意，SpringBoot默认静态资源路径是classpath:/static/，你上传的文件是运行时写入的，不会进classpath。要在配置里修改静态资源映射到外部目录：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath); } }

6.6 JWT登录拦截后前端CORS报错

前后端分离部署的时候，如果后端做了JWT拦截器，前端请求被拦截器拦截后返回401，但前端控制台报的是CORS错误而不是401，说明CORS配置和拦截器配置的顺序有问题。

Spring Security的CORS处理是在拦截器之前的（如果是Spring Security），而我们这里的JWT是HandlerInterceptor，它默认先于WebMvc的CORS配置执行。所以拦截器里直接返回401响应时，响应头里没有Access-Control-Allow-Origin，就会被浏览器判定为跨域错误。

解决办法是在拦截器的不予放行分支里，手动加上跨域头，或者更好的方式是注册一个FilterRegistrationBean，用OncePerRequestFilter来处理JWT验证，确保执行顺序在CORS之后。

7. 复盘与扩展建议：如果我再从零做一遍这个系统

项目做完回头看，有几个决策层面的思考想分享。

7.1 哪些设计是对的

店铺独立表的设计非常正确。一开始如果图省事，把店铺信息直接嵌进帖子，后续做店铺列表页、店铺搜索、店铺关联帖子这些功能的时候会非常痛苦。JWT + 拦截器做鉴权比Session方案更适合前后端分离架构，不用考虑Session跨域共享的问题。MyBatis-Plus只用于单表CRUD，复杂查询写XML这个边界划得也很清晰，没有因为图省事把所有SQL都交给MyBatis-Plus自动生成。

7.2 哪些地方值得优化

引入Redis做缓存：如果帖子列表页是最大流量入口，每次打开首页都要查一次数据库聚合多张表，压力还是不小的。可以把首页的帖子列表缓存到Redis，设置5分钟过期，过期后自动回源数据库。这也算是给简历上加一个缓存优化的亮点。
增加Elasticsearch搜索：如果后续店铺和帖子数量达到几万条，MySQL的LIKE模糊查询性能会明显下降。到那时候可以引入Elasticsearch做全文搜索，但起步阶段没必要。
增加推荐逻辑：校园美食平台很适合做简单的协同过滤推荐——看你室友点了什么、同一个宿舍楼的同学收藏了什么，推荐同类型的店铺。不需要用多复杂的算法，基于标签的推荐就能有不错的效果。
移动端适配：这个项目的用户场景天然是校园内移动端访问。如果Vue3做的PC端为主，后续可以再加一个移动端布局，或者直接套一层H5响应式。

7.3 从"能跑"到"能展示"的包装建议

如果这是你的毕业设计或简历项目，有几个地方值得多花一点功夫：

项目文档写清楚ER图，把表关系、设计决策、技术选型理由写明白。面试官最常问的第一个问题就是"为什么要这样设计数据库"。
准备一段真实的性能优化经历，比如"首页接口优化从800ms降到200ms，主要做了SQL索引优化和前端懒加载"，这种经验比堆砌一堆名词更有说服力。
多做几个边界场景的演示，比如"用户重复点赞""发布帖子时上传超大图片""并发收藏同一家店铺"，这些场景能体现你对工程质量有意识。

这个项目我个人的实际体会是：技术栈本身并没有太高门槛，真正拉开差距的是你在设计每一个功能时有没有想过"为什么这么做"和"如果不这么做会怎样"。把这个逻辑想清楚了，写出来的代码自然就站得住脚。最后分享一个小经验：项目的README文档一定要写全启动步骤（数据库初始化脚本、前后端启动命令、默认账号密码），不要觉得这是小事——如果你要做毕业设计，导师第一件事就是让他能顺利跑起来；如果以后这个项目要放进简历，面试官很可能也会照着README去启动你的项目。跑不起来，功能再全也是白搭。

SpringBoot2+Vue3校园美食分享平台开发实战：从技术选型到部署