SpringBoot+Vue3美食网站管理系统：前后端分离搭建与联调排错

做毕设最耗时间的往往不是写代码，而是环境跑不起来、前后端对不上、数据库导不进去。这次看的这套 SpringBoot + Vue3 美食网站管理系统，属于典型的"前后端分离 + 完整增删改查"路线：后端 SpringBoot 提供 REST 接口，前端 Vue3 负责页面渲染，数据库存菜品、分类、用户、订单这类业务数据，权限用 JWT 或 Session 做登录态。它的价值不在于技术多新，而在于结构完整、能跑通、能改、能写进简历。

先把结论放前面：这套项目适合三类人——正在找毕设题目的学生、想练一遍前后端分离完整链路的初级开发者、需要一套后台管理模板快速改造的业务开发者。它不适合想直接上线商用的场景，因为权限模型、支付对接、图片存储、日志审计这些生产级能力基本都要自己补。下面这篇会从环境准备一路讲到接口联调、批量数据导入、性能观察和踩坑排查，能跑通的部分给命令，不能拍板的部分明确写"以源码为准"。

需要提前说明一点：本文所有端口、版本号、字段名都以"常见默认值 + 通用模板"的方式给出。不同人拿到的源码版本不一样，8080、5173、application.yml 里的库名、表结构可能都被改过。看到命令先对一遍自己的配置文件，再执行，这是省时间的关键。

1. 核心能力速览

这套项目的定位是"内容型后台管理系统"，核心业务围绕美食内容展开。先把能力项摊开看，读者能快速判断这套东西跟自己的需求差多远。

这里要重点强调一下"不需要显卡"这件事。现在很多项目标题挂着 AI 关键词，实际上这套东西跟 GPU 一点关系都没有，它是标准的 Java Web 业务系统，跑在 CPU 上，内存 8G 的笔记本就能撑住。如果你的机器只有 4G 内存，同时开 IDEA、Node 开发服务器和 MySQL，会明显卡顿，建议加内存或者关掉不必要的插件。

另一个容易被标题误导的点是"半小时搭建"。这个时间只在一种情况下成立：JDK、Node、MySQL 都已经装好，Maven 依赖和 npm 包能走本地缓存或高速源，数据库脚本一次导入成功。如果是从零开始装环境，光 MySQL 的安装配置和账号权限就可能花掉一两个小时。所以更实际的心态是：把"半小时"理解成"代码层面的启动时间"，环境准备单独算。

至于"可完美运行"这个说法，我的建议是保持理性预期。开源项目在作者本机能跑，换一台机器大概率会遇到依赖版本、数据库字符集、跨域配置这几类问题。这不是项目质量问题，是环境差异问题。下面每一节都会把这类差异点标出来。

2. 适用场景与使用边界

先说适合谁。第一类是毕设和课程设计，这套项目的结构完整度足够支撑一份中等难度的论文：有前端页面、有后端分层、有数据库设计、有接口文档，答辩时能讲清楚 Controller-Service-Mapper 的调用链和前后端分离的通信方式。第二类是刚学完 Vue3 和 SpringBoot、想找个完整项目练手的开发者，把增删改查从头到尾走一遍，比看十个教学视频管用。第三类是需要快速搭后台模板的开发者，把业务字段换掉，权限和菜单保留，能省掉不少脚手架时间。

再说能解决什么问题。它把"前端页面怎么调后端接口""后端怎么分层""数据库表怎么设计""登录态怎么维持"这四件事串成了一条完整链路。你跑通一次登录、一次列表查询、一次新增、一次删除，基本就把前后端分离的骨架摸清楚了。这个价值比具体的菜品管理业务大得多。

不适合的场景也要说清楚。第一，不适合直接商用上线。生产环境需要的接口限流、参数校验加固、SQL 注入防护、敏感数据脱敏、操作日志审计、异常统一兜底，这套模板通常只做了基础版本。第二，不适合高并发场景。默认的连接池配置、没有缓存层、没有读写分离，几千 QPS 想都别想。第三，不适合替代成熟的内容管理产品，它的定位是学习和二次开发起点。

合规边界必须提。美食网站会涉及菜品图片、店铺照片、用户头像，这些素材的使用需要确认版权或授权，不要直接从外卖平台、点评网站抓图。用户注册信息、手机号、地址属于个人信息，测试时用假数据，不要拿真实用户信息做导入导出。如果项目里带了评论功能，上线前要加内容审核机制，这是平台合规的基本要求。图片上传目录要限制可执行文件类型，避免上传脚本文件造成安全风险。

还有一点：如果这套源码是从第三方渠道拿到的，使用前扫一遍有没有硬编码的数据库密码、第三方密钥、云存储 AK/SK。这类信息泄露在毕设项目里非常常见，提交代码前务必清掉，改成环境变量或配置中心读取。简历项目也一样，仓库公开前先做一次敏感信息检查。

3. 环境准备与前置条件

环境这块按依赖顺序排：JDK → Maven → MySQL → Node → 包管理器 → IDE。顺序乱了容易反复折腾。

3.1 基础软件清单

JDK 版本是最容易踩的坑。SpringBoot 2.x 配 JDK 8 比较稳，SpringBoot 3.x 强制要求 JDK 17 以上。如果你拿到的是 3.x 项目却用 JDK 8 打开，会看到一堆 Unsupported class file major version 或者编译期注解报错。判断方法很简单，打开 pom.xml 看 <parent> 里的 SpringBoot 版本号，再看 <java.version> 或 <maven.compiler.source>。

Node 版本同理。Vue3 + Vite 项目对 Node 版本有硬要求，Node 14 以下跑 Vite 会直接报错。装之前先在命令行确认：

bash复制node -v
npm -v
java -version
mvn -v
mysql --version

五个命令全都有输出，环境才算齐。任何一个报"不是内部或外部命令"，先去配环境变量，别急着往下走。

3.2 数据库准备

MySQL 装好后要做三件事：建库、建用户、导脚本。建库时字符集建议统一用 utf8mb4，美食网站会有菜品描述、用户昵称，emoji 和特殊字符都可能在里头，用 utf8 会插不进去。

sql复制-- 建库示例，库名以项目 SQL 脚本为准
CREATE DATABASE IF NOT EXISTS food_system
  DEFAULT CHARACTER SET utf8mb4
  DEFAULT COLLATE utf8mb4_general_ci;

-- 建专用账号，避免直接用 root 连应用
CREATE USER 'food_user'@'localhost' IDENTIFIED BY 'ChangeMe_2026';
GRANT ALL PRIVILEGES ON food_system.* TO 'food_user'@'localhost';
FLUSH PRIVILEGES;

密码自己换掉，不要用示例里的。生产环境更不该用 root 连应用，这是基本的安全习惯，从毕设阶段就该养成。

导入 SQL 脚本有两种方式。命令行：

bash复制mysql -u food_user -p food_system < ./sql/food_system.sql

或者用 Navicat、DBeaver 这类图形工具，右键库名选"运行 SQL 文件"。导入后执行 SHOW TABLES; 确认表数量对得上，再看几张核心表有没有数据：

sql复制USE food_system;
SHOW TABLES;
SELECT COUNT(*) FROM sys_user;
SELECT COUNT(*) FROM food_info;

表名和字段名一定要以实际脚本为准，我这里用 food_info 只是示意，你的项目里可能叫 dish、cuisine、goods。名字对不上的话，后面 MyBatis 的映射会全部报错。

3.3 后端配置文件检查

打开 src/main/resources/application.yml（也可能是 application.properties），这几项必须改成本机的：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/food_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: food_user
    password: ChangeMe_2026
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 20MB

mybatis-plus:
  mapper-locations: classpath*:/mapper/**/*.xml
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

重点看四个地方。url 里的库名要和刚建的一致；serverTimezone 不写可能报时区错误；max-file-size 决定菜品图片能传多大，默认 1MB 通常不够；map-underscore-to-camel-case 决定了数据库的 create_time 能不能自动映射到 Java 的 createTime，这个开关关了会查出一堆 null。

log-impl 打开是为了在控制台看到真实执行的 SQL，调试阶段非常有用，上线前记得关掉，不然日志量会很大。

4. 后端启动与数据库初始化

配置改完就能启动。两条路：IDE 里跑，或者命令行跑。

4.1 IDE 启动

IntelliJ IDEA 打开项目根目录，等 Maven 索引完成。右下角会有依赖下载进度，第一次可能需要几分钟。如果卡在某个依赖上不动，检查 Maven 的 settings.xml 有没有配国内镜像：

xml复制<mirror>
  <id>aliyun</id>
  <mirrorOf>central</mirrorOf>
  <name>aliyun maven</name>
  <url>https://maven.aliyun.com/repository/public</url>
</mirror>

配好后重新加载 Maven 项目。找到主启动类（通常叫 XxxApplication，带 @SpringBootApplication 注解），右键 Run。控制台出现 Started XxxApplication in x.xxx seconds 就算起来了。如果看到 Tomcat started on port(s): 8080，说明 Web 容器也正常。

4.2 命令行启动

不依赖 IDE 的方式更适合部署验证：

bash复制# 在项目根目录执行，跳过测试加快速度
mvn clean package -DskipTests

# 产物在 target 目录下，名字以实际为准
java -jar target/food-system-0.0.1-SNAPSHOT.jar

打包时如果报"找不到符号"或者编译错误，先执行 mvn clean 再试。有时候是旧产物干扰。JDK 版本不匹配也会在这一步暴露出来。

4.3 启动成功的判断标准

不要只看"启动成功"四个字，要验证接口真的能通。浏览器直接访问一个不需要登录的接口，比如：

bash复制curl -i http://127.0.0.1:8080/api/food/list?pageNum=1&pageSize=10

三种结果对应三种状态。返回 200 加 JSON 数据，说明数据库连通、Mapper 正常。返回 401 或 403，说明接口存在但被鉴权拦截了，这是正常的，去登录拿 Token。返回 404，说明路径不对或者 Controller 没扫描到，检查 @RequestMapping 前缀和启动类的包扫描范围。返回 500，看控制台堆栈，大概率是 SQL 或字段映射问题。

这条排查思路很实用：先用一个接口确认"服务活着"，再确认"数据库通"，最后确认"鉴权生效"。三层分别验证，比一上来就登录页面瞎试效率高得多。

5. 前端启动与前后端联调

后端通了，前端才开始。顺序反了会浪费很多时间在跨域问题上。

5.1 依赖安装

进入前端目录（通常叫 vue、web、frontend、ui 之类），先看 package.json 确认用哪个包管理器。有 pnpm-lock.yaml 就用 pnpm，有 yarn.lock 就用 yarn，只有 package-lock.json 就用 npm。混用会导致依赖树不一致，出现莫名其妙的模块找不到。

bash复制# 进入前端目录后执行
npm install

# 如果公司或学校网络慢，换源后再装
npm config set registry https://registry.npmmirror.com
npm install

装完看 node_modules 目录大小，正常几百 MB。如果只有几十 MB，多半是装了一半中断了，删掉重装。

5.2 开发服务器启动

bash复制npm run dev

Vite 会输出本地访问地址，常见是 http://localhost:5173。用 Webpack 的老项目可能是 8080 或 8081，注意别和后端端口撞了。撞了的话前端会自己换端口，或者直接报端口占用，改 vite.config.js 里的 server.port 就行。

5.3 代理配置与跨域

前后端分离绕不开跨域。开发阶段的标准做法是配 Vite 代理，把 /api 开头的请求转发到后端：

javascript复制// vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  server: {
    port: 5173,
    proxy: {
      '/api': {
        target: 'http://127.0.0.1:8080',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '/api')
      }
    }
  }
})

rewrite 那行要看后端接口有没有统一前缀。后端是 /api/food/list，前端请求也写 /api/food/list，就不需要重写；后端是 /food/list 而前端写 /api/food/list，才需要把 /api 去掉。这块搞错的表现是接口 404，但浏览器 Network 里能看到请求发出去了。

另一种做法是后端加全局跨域配置，开发阶段更省事：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

allowedOrigins("*") 和 allowCredentials(true) 在部分 Spring 版本里不能同时用，会抛异常，所以用 allowedOriginPatterns。这段配置只建议开发环境用，上线要收紧到具体域名。

5.4 登录验证第一关

打开页面，先测登录。默认账号密码一般在 SQL 脚本的 sys_user 表里，或者在 README 里写着。登录成功后看三件事：浏览器 LocalStorage 或 Cookie 里有没有 Token；页面有没有跳到首页；Network 里后续请求的请求头有没有带上 Authorization。

这三件事任何一件不对，后面所有接口都会 401。常见的失败原因是前端 Axios 拦截器里 Token 的 key 名和后端解析的 key 名不一致，比如前端存 token，后端读 Authorization。翻一下 request.js 和后端拦截器，对齐就行。

6. 功能测试与效果验证

环境通了之后，按业务模块逐个验证。不要一上来就点遍所有菜单，按"列表 → 详情 → 新增 → 修改 → 删除"的顺序走，每个模块走一遍，问题定位最清晰。

6.1 列表与分页查询测试

测试目的：验证 MyBatis 映射、分页插件、条件查询是否正常。

操作步骤：进入菜品管理页，不填任何条件点查询，看总数和每页条数。再输入一个关键词搜，看结果是否收敛。最后切到第 2 页、第 3 页，看数据是否变化。

判断成功的标准：总数和数据库 SELECT COUNT(*) 的结果一致；翻页时数据不重复不丢失；条件搜索的字段和后端 Wrapper 里的字段对应。

常见失败原因：分页插件没配（SpringBoot 2.x 用 MyBatis-Plus 需要注册 PaginationInnerInterceptor，漏了会导致分页失效，永远返回全量数据）；map-underscore-to-camel-case 没开导致字段全 null；条件查询的 like 拼错了字段名。

如果分页失效，先看控制台打印的 SQL 有没有 LIMIT。没有就是插件没生效，这是最高频的问题之一。

6.2 新增与图片上传测试

测试目的：验证表单校验、文件上传、事务写入。

操作步骤：点新增，填必填项，上传一张 1MB 以内的 JPG 图片，提交。回到列表确认新记录出现，图片能正常显示。

判断成功的标准：数据库里多了一条记录；上传目录里多了一个文件；列表页图片 URL 能访问。

常见失败原因：上传目录不存在或没有写权限；max-file-size 太小导致大图报 MaxUploadSizeExceededException；图片存的是相对路径但前端拼的域名不对，导致 404；Windows 下路径分隔符写死成 / 在 Linux 上跑不通。

图片这块有个实践建议：不要把图片存成数据库 BLOB，也不要把绝对路径存进库。存相对路径，配一个静态资源映射，迁移环境时只改配置不改数据。

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 将 /upload/** 映射到本地上传目录，路径按实际情况调整
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/");
    }
}

6.3 修改与删除测试

测试目的：验证更新逻辑、主键传递、逻辑删除或物理删除策略。

操作步骤：编辑一条记录，只改一个字段，提交，刷新列表看是否生效。再删除一条，看列表是否消失、数据库是否真删。

判断成功的标准：更新只影响目标行，不误伤其他数据；删除后关联数据（比如菜品分类关联、评论）有正确的处理策略。

常见失败原因：更新时 WHERE 条件漏了主键，导致全表更新，这是灾难级 bug，测试环境一定要先验证；逻辑删除字段配了但查询没加过滤条件，删了还在列表里显示；外键约束导致删除报错。

特别提醒：全表更新这种事在测试库发生一次就够吓人了。新增和修改接口上线前，务必在控制台打开 SQL 日志，肉眼确认 WHERE 子句存在。

6.4 权限与菜单测试

测试目的：验证不同角色的菜单可见性和接口访问控制。

操作步骤：用管理员登录，记下能看到哪些菜单。退出，换一个普通用户登录，对比菜单差异。再用普通用户的 Token 直接调管理员接口，看是否被拒。

判断成功的标准：前端菜单按角色隐藏；后端接口独立校验权限，不能只靠前端隐藏；越权请求返回 403。

常见失败原因：只做了前端菜单过滤，后端没有 @PreAuthorize 或拦截器校验，导致直接调接口就能越权。这是后台系统最常见的安全问题，改起来不难，但必须有。

6.5 数据看板与统计测试

很多美食管理系统首页会放一个统计卡片，比如菜品总数、用户数、今日新增。测试方法是拿数据库里的真实 count 去对，数字对得上才算通过。常见问题是统计 SQL 写死了时间范围，或者用了 GROUP BY 但没处理空值，导致某些分类显示 null。

7. 接口 API 调用与批量数据处理

后端本身就是接口服务，脱离前端也能用。这块对写毕设论文和做二次开发特别有用。

7.1 登录获取 Token

bash复制curl -X POST http://127.0.0.1:8080/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"123456"}'

返回体里通常有 token 字段。把它存到变量里，后面请求都带上：

bash复制TOKEN="粘贴返回的token"
curl -X GET "http://127.0.0.1:8080/api/food/list?pageNum=1&pageSize=10" \
  -H "Authorization: Bearer $TOKEN"

接口路径、字段名、鉴权头格式都要以实际项目为准。有的是 token 头，有的是 Authorization: Bearer，有的是自定义请求头，看拦截器代码最准。

7.2 新增一条业务数据

bash复制curl -X POST http://127.0.0.1:8080/api/food \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "name": "测试菜品",
    "categoryId": 1,
    "price": 28.50,
    "description": "接口新增测试数据",
    "status": 1
  }'

字段必须和后端实体类对齐，多传字段一般会被忽略，少传非空字段会报校验错误。返回体如果是统一封装（code/msg/data），看 code 是不是 200。

7.3 批量导入的实用做法

系统本身不一定带批量导入功能，但毕设演示和压力测试经常需要几十上百条数据。两个思路。

思路一：直接用 SQL 批量插入，最快。

sql复制INSERT INTO food_info (name, category_id, price, description, status, create_time)
VALUES
('批量测试01', 1, 18.00, '批量导入数据', 1, NOW()),
('批量测试02', 1, 22.00, '批量导入数据', 1, NOW()),
('批量测试03', 2, 35.00, '批量导入数据', 1, NOW());

思路二：用 Python 走接口，能顺便验证接口稳定性。

python复制import time
import requests

BASE_URL = "http://127.0.0.1:8080"
TOKEN = "替换成登录拿到的token"

headers = {
    "Content-Type": "application/json",
    "Authorization": f"Bearer {TOKEN}"
}

success, failed = 0, 0
for i in range(50):
    payload = {
        "name": f"压测菜品{i:03d}",
        "categoryId": (i % 3) + 1,
        "price": round(10 + i * 0.5, 2),
        "description": "接口批量写入测试",
        "status": 1
    }
    try:
        resp = requests.post(f"{BASE_URL}/api/food", json=payload,
                             headers=headers, timeout=10)
        if resp.status_code == 200 and resp.json().get("code") == 200:
            success += 1
        else:
            failed += 1
            print("失败:", resp.status_code, resp.text[:200])
    except requests.RequestException as e:
        failed += 1
        print("异常:", e)
    time.sleep(0.05)

print(f"成功 {success} 条，失败 {failed} 条")

这段要注意三个细节。time.sleep(0.05) 是故意的，不加的话本地服务容易被瞬时请求打满，测试结果失真。timeout 必须设，不然某一条卡住整个脚本就挂死了。失败要打印响应体，只打印状态码排查不了问题。

如果要做正式的批量任务，建议加三个东西：任务表记录批次状态、失败重试队列、幂等键防重复写入。简单项目用不上，但简历里写"设计并实现批量导入任务，支持失败重试和进度查询"，含金量比单纯 CRUD 高不少。

7.4 导出功能

导出 Excel 通常用 EasyExcel 或 POI。接口调用方式一般是 GET 直接下载：

bash复制curl -o food_export.xlsx \
  -H "Authorization: Bearer $TOKEN" \
  "http://127.0.0.1:8080/api/food/export"

导出量大的时候要分页查再写，别一次 SELECT * 全捞进内存，几千条没事，几十万条必然 OOM。

8. 资源占用与性能观察

业务系统不看显存，看内存、CPU、数据库连接数和接口响应时间。这几个指标决定了你的项目在答辩演示时会不会卡。

8.1 内存占用怎么观察

后端启动后，用 JDK 自带工具看堆内存：

bash复制jps -l
jstat -gc <pid> 1000 10

jps 列出 Java 进程和 PID，jstat 每秒打印一次 GC 情况。重点看 OU（老年代使用量）是不是持续上涨不回落，持续涨说明有内存泄漏，常见原因是查询没分页、把大结果集塞进静态集合、上传文件流没关。

前端开发服务器和 IDEA 也吃内存。一个典型组合是 IDEA 1.5G 左右、Node 500M 到 1G、MySQL 500M，加起来 3G 以上。8G 内存的机器跑这套东西是够的，但别同时开着浏览器十几个标签页和视频软件。

8.2 接口响应时间怎么测

不用上 JMeter，先用 curl 看耗时：

bash复制curl -o /dev/null -s -w "耗时: %{time_total}s\n" \
  "http://127.0.0.1:8080/api/food/list?pageNum=1&pageSize=10"

正常情况下本地接口应该在几十毫秒级。如果超过 500ms，看三个地方：SQL 有没有走索引、有没有 N+1 查询（列表里每条记录又去查一次关联表）、有没有在循环里调远程服务。

列表查询最常见的性能问题是没加索引。菜品表的 category_id、status、create_time 这几个经常出现在 WHERE 里的字段，加上索引效果立竿见影：

sql复制CREATE INDEX idx_food_category ON food_info(category_id);
CREATE INDEX idx_food_status ON food_info(status);
CREATE INDEX idx_food_create_time ON food_info(create_time);

字段名按实际表结构调整。加之前先用 EXPLAIN 看执行计划，确认 type 是 ALL 才需要加，别盲目堆索引。

8.3 连接池配置

SpringBoot 默认用 HikariCP，配置在 application.yml：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 10
      minimum-idle: 5
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000

毕设项目 maximum-pool-size 给 10 足够了。调太大会把 MySQL 的连接数占满，尤其是本地 MySQL 默认 max_connections 只有 151。如果看到 Too many connections，先降连接池大小，再检查是不是有连接没释放。

8.4 降低资源占用的几个手段

前端生产构建用 npm run build 出静态文件，交给 Nginx 托管，比常驻 Vite 开发服务器省内存。后端打包成 jar 用 -Xmx512m 限制堆大小，小项目 512M 完全够用：

bash复制java -Xms256m -Xmx512m -jar target/food-system-0.0.1-SNAPSHOT.jar

数据库层面，把不用的表清空，别把演示用的几万条测试数据一直留着，COUNT 查询和备份都会变慢。

9. 常见问题与排查方法

这一节按出现频率排，遇到问题从表格里找对应现象，能省掉大量搜索时间。

端口占用这条在 Windows 上特别常见。查出来 PID 后：

bash复制# Windows 查看占用 8080 的进程
netstat -ano | findstr :8080
# 按 PID 结束进程
taskkill /PID <pid> /F

Linux 或 macOS 用 lsof -i:8080 再 kill -9 <pid>。别嫌粗暴，开发阶段这是最快的办法。

还有一个高频问题值得单独说：改了后端代码重启后，前端还是拿旧数据。原因可能是浏览器缓存，也可能是前端把数据存在了 Pinia 或 Vuex 里没刷新。排查方法是 Network 里勾选 Disable cache，或者开无痕窗口。如果无痕窗口正常，就是缓存问题，不是代码问题。

10. 最佳实践与延伸方向

跑通只是第一步。这套项目真正能加分的，是你在它基础上做了什么。

第一条建议：先做减法再做加法。拿到源码不要急着加功能，先把用不到的模块注释掉，保证核心链路干净可跑。一个"能跑通的最小版本"比"功能很多但到处报错"的版本有用得多。做完减法后打个 tag 或者复制一份备份，后面改坏了能退回来。

第二条：目录和配置分离。数据库脚本、上传图片、导出文件、日志，这四类东西各放一个目录，别混在项目源码里。配置项抽到 application-dev.yml 和 application-prod.yml，用 spring.profiles.active 切换。数据库密码用环境变量注入，别明文提交到仓库：

yaml复制spring:
  datasource:
    username: ${DB_USER:food_user}
    password: ${DB_PASSWORD:}

这样本地开发不设环境变量也能跑，线上必须显式注入，安全性和便利性都照顾到了。

第三条：给关键接口加校验和日志。参数校验用 @Valid 加注解，别在 Controller 里写一堆 if。操作日志用 AOP 切面记录谁在什么时候改了什么，这个功能在答辩时很能体现工程意识，实现成本也不高。

第四条：批量任务要有兜底。不管你是导入还是导出，都要做到失败可重试、进度可查询、异常有记录。最简单的实现是一张任务表，字段包括批次号、总数、成功数、失败数、状态、错误信息。这个设计能直接写进论文的系统设计章节。

第五条：前端体验的细节。表格加 loading 状态、删除加二次确认、表单加必填校验提示、接口异常统一 toast 提示。这些改动代码量不大，但演示效果差别很明显。

第六条：合规和安全不能省。菜品图片、店铺照片确认版权来源；用户数据用测试数据；上传目录限制文件类型白名单；接口加基本的频率限制；上线前把 log-impl 关掉、跨域收紧到具体域名、管理后台加 IP 白名单或强密码策略。这些不是"以后再说"的事，是提交前必须过一遍的清单。

往后的扩展方向可以按难度排。入门级是加数据导出、加图表统计、加富文本编辑。中级是引入 Redis 做缓存和登录态、加 Spring Security 做细粒度权限、用 Nginx 部署前后端分离。进阶级是拆成多模块、加消息队列处理异步任务、做 Docker Compose 一键编排。

如果想把这套东西写进简历，建议至少做两件区别于模板的事：一是把某个模块重构成自己设计的分层结构，二是补一套接口文档（Swagger 或 Knife4j），把请求参数、响应示例、错误码写全。面试官问起"你在这个项目里做了什么"，能具体说出"我重构了权限模块，把菜单和接口权限统一到一张表里"比"我跑通了一个开源项目"有说服力得多。

最后提醒一句：拿到源码先备份，改之前先确认能跑，改之后先确认没坏。这个习惯比任何技术细节都值钱。