企业官网建设流程全解析

1. 这个项目到底是什么：一套能真正跑起来的完整餐饮业务闭环

先说个很多人容易忽略的常识：在 Java Web 方向的课设、毕设和简历项目里，"管理系统"永远比"纯前端展示页"吃香，而餐饮管理系统又是管理系统里综合度最高的那一档。原因不复杂——它同时涉及商品管理、订单流转、库存联动、会员营销、报表统计，几乎把一套业务系统该有的模块全占了。你拿这一个项目去讲清楚 SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0 这套技术栈怎么协作，比单独写十个 CRUD 例子都有说服力。

这套系统的定位不是一个花架子 Demo，而是按真实门店使用场景设计的完整业务闭环。从顾客扫码点餐开始，到后厨接单出餐，再到收银台结算、老板看营业报表，整条链路是通的。项目里还包含管理员端和门店操作端两个视角——管理员管菜品分类、上下架、员工账号；门店端处理桌台状态、订单接单、会员储值。换句话说，它不是"看起来功能很多"，而是"每个功能点都有实际业务含义"。

我在本地把它完整跑通过一遍，前后端加数据库加起来大概半小时能启动完。前提是你把环境装好，尤其是 MySQL8.0 和 Node 环境这两块最容易出幺蛾子。这篇博文我不打算只贴代码，而是从技术选型、目录结构、核心表设计、关键接口实现、前后端联调、部署运行这几个维度，把整个项目的设计思路和避坑点全部拆开讲清楚。适合的人群很明确：做 Java Web 课设/毕设的学生、准备把管理系统写进简历的初级开发者、以及想快速落地一套 Web 全栈业务系统的朋友。

2. 为什么是这套组合：SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0 的选型逻辑

2.1 SpringBoot2 比 SpringBoot3 更适合拿来做项目

现在不少人一上来就追 SpringBoot3，但实际落地上，SpringBoot2.7.x 仍然是目前课设、毕设和中小型公司存量项目里的绝对主流。原因有三个：第一，SpringBoot2 的用户基数大，你遇到任何报错几乎都能搜到现成的解决方案；第二，很多第三方框架（生成的验证码组件、某些文件上传工具）对 SpringBoot3 的 Jakarta 命名空间适配还不完整，Boot2 的 javax 体系下兼容性最好；第三，对学习而言，SpringBoot2 和 3 的自动配置原理、starter 机制完全一脉相承，学通 2 再切 3 的成本很低。

提示：本项目用 2.7.x 版本，Java 环境用 JDK8 或 JDK11 都行，千万别上 JDK17 跑 Boot2.7，虽然也能跑但某些老依赖会报模块访问异常，没必要折腾。

2.2 MyBatis-Plus：比 JPA 更好上手，比原生 MyBatis 省一半代码

关于 Spring Data JPA 和 MyBatis-Plus 的区别，我自己的体会是：JPA 适合领域模型驱动、表结构不那么固定的项目，但它的隐式 SQL 对新手很不友好，一个方法名写错你根本不知道它在查什么；MyBatis-Plus 则完全站在"业务增删改查"的角度，单表操作连 SQL 都不用写，Wrapper 条件构造器写起来像拼积木。

选 MyBatis-Plus 还有一个非常现实的原因：它自带的分页插件、代码生成器、逻辑删除、自动填充，每一样都是做管理系统时"刚需中的刚需"。比如分页，一个订单列表、菜品列表全都需要分页，手写 limit 还得自己包 PageResult，MP 直接返回 Page 对象，前端拿 current、size、total 三件套就走完了。再比如逻辑删除，菜品"下架"肯定不能物理删，加一个 @TableLogic 注解就解决。

2.3 Vue3：从 Options API 到 Composition API 的跨代优势

前端选 Vue3 不只是因为"新"，而是它和这套项目的契合度确实高。Vue3 的 Composition API 让代码复用变得特别顺——团队里公共的接口请求逻辑、登录态检查逻辑、购物车状态管理，全部可以用自定义 Hook 提取出来。而且 Element Plus 组件库现在已经非常成熟，做后台管理系统几乎零成本搭界面。用 Vite 做构建工具后，冷启动秒开，开发体验比 Webpack 时代的 Vue2 强一个量级。

2.4 MySQL8.0 与"不用 Oracle 也不用 SQL Server"的考虑

管理系统选数据库，MySQL8.0 基本是标准答案。它对窗口函数、公用表表达式（WITH AS）的支持已经很全，做营业报表、排行统计比 5.7 顺滑很多。再加上 MySQL8.0 默认字符集是 utf8mb4，直接支持 emoji 和生僻字，菜品名称里有个"𠮷"字也不会乱码。如果你用 5.7，还得手动改配置文件指定字符集，很多新手在数据库初始化那一步就倒下了。8.0 安装完之后默认就是 utf8mb4，少操一份心。

3. 先按标准目录搭骨架：Java Web 项目的目录结构决定你的开发效率

这套项目拿到的第一件事，不是急着写业务，而是把前后端两个工程的目录结构看清楚、理顺了。目录结构这事儿看着基础，但很多人项目跑不起来，根源就是文件放错了地方。

3.1 后端标准分包：controller / service / mapper / entity / common

后端 Maven 工程采用的是标准的分层架构，com.example.restaurant 作为根包，下面按职责拆分为五个核心包：

• controller：只负责接收请求、参数校验、调用 service，不写任何业务逻辑。比如 OrderController 里只有下单、查单、改状态这几个端点。
• service：业务逻辑层，接口加实现类分离。订单超时处理、库存联动扣减这些逻辑都放在这里。
• mapper：MyBatis-Plus 的 Mapper 接口层，继承 BaseMapper 后单表 CRUD 全免费。多表关联的统计查询，写自定义 XML 或注解 SQL。
• entity：数据库表对应的实体类，字段和表列一一对应，用 @TableName 和 @TableId 注解标注映射关系。
• common：放通用返回结果（Result ）、异常处理器、工具类、常量类。

这种结构的好处是非常容易定位问题——前端报错，你能迅速判断是 controller 层参数问题还是 service 层业务问题，而不是在一个几百行的类里从头翻到尾。

3.2 前端目录结构：src 下的模块化设计

前端工程 Vue3 + Vite 的标准结构是：

src/ api/ // 按业务模块拆分的接口请求文件 assets/ // 静态资源 components/ // 通用组件 layout/ // 后台布局框架（侧边栏+顶栏+主内容区） router/ // 路由配置 store/ // Pinia 状态管理 utils/ // 请求封装、工具函数 views/ // 页面视图，按模块建子目录

需要注意的一个点：api 目录要按后端 controller 的模块一一对应，比如 菜品管理 对应 dish.js，订单管理对应 order.js，这样一个后端接口改动时，你只需要去对应文件里改，维护成本低很多。很多项目到后期改需求改到崩溃，就是因为接口请求散落在各个页面组件里。

3.3 配置文件分离：application.yml 里的三个关键环境

后端工程里有 application.yml 作为主配置文件，再配合 application-dev.yml（开发环境）和 application-prod.yml（生产环境），通过 spring.profiles.active 来切换。数据库连接信息、Redis 地址、JWT 密钥这类敏感配置都放在不同环境里，而不是写死在一个文件中。配置里最容易被忽略的就是 MyBatis-Plus 的逻辑删除配置：

mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这个配置配合实体类上的 @TableLogic 注解，所有删除操作自动变成 UPDATE，有效避免误删数据。检查一个"含文档项目"是否靠谱，我一般先看它有没有配逻辑删除，没配的说明开发者根本没有实际运营思维。

4. 数据库设计：订单、菜品、库存这三张表是怎么连起来的

餐饮管理系统看着模块多，实际上数据库的核心就是几张关键表：菜品表、分类表、桌台表、订单表、订单明细表、会员表、库存表。它们之间的关系捋顺了，整个系统就撑起来了。

4.1 菜品信息和分类：SPU 与 SKU 的简化处理

菜品分类表比较简单，就是 id、name、sort 三件套。菜品表则用到了简约版的 SPU/SKU 思想——菜品基本信息（名称、主图、描述、销量）是一层，菜品规格（大份/小份、加辣/不辣）放在 sku 表。订单明细里存的是 sku_id 而不是 dish_id，这样不同规格的价格和口味才能区分开。

项目思路延伸：如果想锦上添花，可以给菜品加"推荐指数"字段，前端首页按指数排序展示。这个小功能涉及一个 update 操作加一个列表查询，成本极低，但对做展示很有帮助。

4.2 订单主表和明细表：为什么必须拆两张表

订单表（orders）和订单明细表（order_detail）是典型的主从表结构。订单主表保存整单的维度信息：订单号、桌台号、总金额、状态、顾客信息、下单时间；明细表保存每一道菜品的数量、单价、小计。

这里有个容易犯的错误：直接在主表里用一个逗号分隔的字符串存菜品列表。这种设计查单的时候确实方便，但后厨要按菜品合并出餐、老板要统计每种菜的销量时，SQL 根本写不出来。拆成明细表后，一个 GROUP BY 就能算出任何菜品在任意时间段的销量，这才是管理系统的"管理"价值所在。

金额字段我强烈建议用 decimal(10, 2)，不要用 float 或 double。数据库里的 float 做加法会产生精度误差，餐饮账单这种涉及钱的地方，一分钱都不能差。

4.3 库存联动：从"扣减"到"回滚"的完整链路

库存表的核心字段是：原料 id、名称、当前库存、预警阈值、单位。它和菜品的关系是通过 recipe（配方）表关联的——一道菜品需要哪些原料、各需要多少份。下单时，系统查出菜品的配方，逐项扣减库存；取消订单时，回补库存。

这个联动逻辑如果放在前端做，那延期和超卖就避免不了。正确的做法是在 service 层用事务包裹——扣库存和创建订单放在同一个 @Transactional 方法里，任何一步失败整体回滚。这个事务处理是整套系统里最值得跟面试官讲的技术点之一，比"我会增删改查"有含金量得多。

4.4 时间字段设计：create_time 与 update_time 的自动填充

两张核心表都包含 create_time 和 update_time 字段。如果你每个插入和更新操作都手动 set 时间，不仅代码冗余，还容易漏。更专业的做法是用 MyBatis-Plus 的 MetaObjectHandler 实现自动填充：

@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }

并在实体类字段上加 @TableField(fill = FieldFill.INSERT) 和 @TableField(fill = FieldFill.INSERT_UPDATE)。这样订单创建、菜品修改时时间自动写入，全项目统一。

5. 后端核心功能拆解：登录认证、订单状态机、统计报表的实现套路

5.1 基于 JWT 的登录认证：拦截器 + 注解 + 异常处理

系统采用无状态登录方案，登录接口校验用户名和密码后返回一个 JWT token，前端存储并在后续请求头携带。后端的实现分三步：

1. 登录接口用 BCrypt 校验密码，生成 token（包含用户 id、角色、过期时间）。
2. 注册一个拦截器，拦截所有需要认证的请求路径（/api/** 但排除 /api/login）。
3. 在拦截器中解析 token，失败则直接抛异常，由全局异常处理器返回 401 状态码。

管理员和门店操作员的角色区分，可以在 token 里放一个 role 字段，后端在特定的管理端接口上用注解校验角色。这里有个细节：JWT 的密钥不能写死在代码里，要放在 application.yml 里，因为项目文档里其他开发者拿到源码后，如果密钥泄漏，他们可以任意伪造 token。

5.2 订单状态机：待付款、已付款、制作中、待取餐、已完成、已取消

餐饮订单状态流转是有严格顺序的，不能从"待付款"直接跳到"已完成"。我的实现方式是在 service 层定义一组状态变更方法，每个方法内部校验当前状态是否合法：

public void pay(Long orderId) { Orders order = getById(orderId); if (!Status.WAIT_PAY.equals(order.getStatus())) { throw new BusinessException("当前订单状态不能支付"); } // 扣减库存、更新状态 }

这种做法的好处是状态流转逻辑集中在一个类里，不会出现"前端调了个接口就胡乱改状态"的情况。状态字段建议用 int 而非字符串，因为 int 比较效率更高，而且前端只需要几个常量就能映射。

5.3 统计报表：MyBatis-Plus 自定义 SQL 完成营业额分析

报表模块是管理系统的加分项，包括今日营收、订单数、客单价、畅销菜品 TOP10。这些统计查询用 Wrapper 不方便，我直接在 Mapper 里写了一个自定义 SQL：

<select id="selectDailyReport" resultType="com.restaurant.dto.ReportDTO"> SELECT DATE(create_time) AS reportDate, COUNT(*) AS orderCount, SUM(total_amount) AS totalAmount FROM orders WHERE create_time BETWEEN #{start} AND #{end} GROUP BY DATE(create_time) ORDER BY reportDate </select>

核心就是 GROUP BY 加聚合函数。报表查询的数据量通常不大，不需要过度设计，但索引一定要建好，否则数据量上来后统计查询会慢。orders 表的 create_time 字段必须建索引，这是这个模块性能的关键。

6. 前端实战细节：创建 Vue3 项目、请求封装、权限控制到打包

6.1 Vite 创建项目与 Element Plus 引入

创建项目环境时，我建议直接使用 npm create vite，而不是用 vue-cli。Vite 创建完的项目结构干净，启动速度快，配置相对直观。命令如下：

npm create vite@latest restaurant-web -- --template vue cd restaurant-web npm install npm install element-plus @element-plus/icons-vue pinia vue-router axios

Element Plus 可以全量引入也可以按需引入。个人建议做管理系统时全量引入，虽然体积稍大，但省心。按需引入一旦漏配样式，排查起来很费时间，违背了"先跑通再优化"的原则。

6.2 axios 封装与请求拦截器：统一处理 401 和业务错误

所有接口请求必须走统一的 axios 实例，而不是每个页面单独创建。封装的核心逻辑有三块：

• 请求拦截器：从 localStorage 取 token，加到请求头的 Authorization 字段。
• 响应拦截器：判断 HTTP 状态码和业务状态码。HTTP 401 时清理 token 并跳转登录页；业务状态码非 200 时，用 Element Plus 的 ElMessage 弹出错误提示。
• 统一 baseURL：开发环境用/api，通过 Vite 代理转发到后端的http://localhost:8080，避免跨域问题；生产环境可以通过环境变量切换真实地址。

6.3 路由守卫：未登录跳转登录页与页面级权限

Vue Router 的路由守卫是必须写的。一套管理系统如果没有登录拦截，用户直接访问 /order/list 也能看到数据，那 JWT 认证就是摆设。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })

这个守卫还能顺便处理"已登录但访问登录页"的情况——如果已登录还要去 /login，直接重定向到首页。细节虽小，但体验差异很明显。

6.4 联调阶段最容易踩的坑：代理配置与端口冲突

前后端联调时最常见的报错就是跨域和被拦截。跨域的解决方案是在 vite.config.js 里配置 proxy：

server: { host: '0.0.0.0', port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这里有个容易忽视的细节：如果后端接口路径本身带 /api 前缀，前端请求就用 /api/xxx 直接代理；如果后端不带，则需要用 rewrite 做路径重写。不少人在这一步反复配不通，根本原因是前后端路径设计没对齐。

端口冲突也常见——默认 Vite 是 5173，如果你电脑上 5173 被占了，Vite 会自动换端口，但 element 页面里的跳转地址写死的还是老端口，就会莫名访问不了。我的习惯是显式指定 host 和 port，避免自动切换造成环境不一致。

7. MySQL8.0 的安装与连接配置：从头避坑到稳定跑通

7.1 Windows 下安装：用安装包还是解压版

MySQL8.0 在 Windows 下建议直接用官方安装包（MySQL Installer），它会帮你自动配置服务、环境变量和初始密码重置流程。如果你要用免安装的 zip 解压版（很多人提 Navicat 免安装版，但 MySQL 本身我建议装原版），步骤会麻烦一些：

1. 解压后，在根目录新建 my.ini 配置文件。
2. 以管理员身份运行 cmd，进入 bin 目录。
3. mysqld --initialize-insecure 初始化目录，生成一个无密码的 root 用户。
4. mysqld -install 注册 Windows 服务。
5. net start mysql 启动服务。

第 3 步用 --initialize-insecure 还是建议的，免去第一次登录时去找随机密码的环节。但生产环境一定不能留空密码，初始化后要立刻改。

7.2 连接报 2059 错误的根因与解决

用 Navicat 连接 MySQL8.0 时经常会碰到 2059 错误，原因是 MySQL8.0 默认的认证插件是 caching_sha2_password，而旧版客户端只支持 mysql_native_password。网上很多教程让你改加密规则，但更稳妥的做法是升级 Navicat 版本，新版完全兼容。如果你不想升级数据库侧也可执行：

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

但注意，这种方式在 MySQL 8.4 里已经被标记为废弃。从长期角度看，跟上工具版本才是正解。

7.3 时区和编码设置：今天 22:00 的订单别变成昨天

mysql8.0 连接 URL 必须在后面带时区参数，否则控制台会直接报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized这个经典的乱码时区错误。正确连接串是：

jdbc:mysql://localhost:3306/restaurant?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

参数含义逐一说清楚：

• useUnicode & characterEncoding：保证中文存储不乱码。
• serverTimezone：指定时区。
• useSSL=false：本地开发没必要用 SSL，减少握手时间。
• allowPublicKeyRetrieval=true：连接 caching_sha2_password 认证时必须要加，否则某些驱动会报公钥检索失败。

7.4 本地库建好后，项目初始化 SQL 脚本怎么导入

项目文档里一般会附带 restaurant.sql 脚本。导入前先新建数据库，再导入脚本：

CREATE DATABASE restaurant DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后使用命令mysql -u root -p restaurant < restaurant.sql导入（Windows 下在 bin 目录里操作），或者在 Navicat 里右键数据库运行 SQL 文件。建议用命令行方式导入，速度更快也更稳定。

8. 从零到一跑通全流程：启动顺序、验证方法和我遇到的坑

8.1 启动顺序：先 MySQL，再后端，最后前端

整个系统跑起来的顺序是个关键经验。先启动 MySQL 服务（任务管理器确认 mysqld 在运行），再启动后端 SpringBoot 应用（它会自动连接数据库），最后启动前端 Vite 服务。前端启动没问题不代表后端 OK，后端控制台出现Started RestaurantApplication字样才算真正成功。

后端启动后，可以用接口文档工具测试登录接口，拿到 token 后再测菜品列表接口。这样能快速定位问题是出在认证还是数据查询。

8.2 我在复现过程中的三个记忆深刻的报错

第一个是Invalid bound statement (not found)。这个报错的前因是 Mapper 接口和 XML 文件没放到同一个包路径下。如果你把 XML 放在 resources/mapper 目录，就必须在 application.yml 里配置 mapper-locations：

mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml

配置完重启，问题解决。很多新手在这一步会卡很久，因为报错信息并不直说"XML 没找到"，而是抛一个 Statement not found 的异常。

第二个是表名或字段名与 MySQL 关键字冲突。订单表如果命名为 order，在 MySQL 里会直接报语法错误，因为 order 是排序关键字。项目里用的表名是 orders，规避了这个问题。同理，字段名不要用 desc、rank、condition 这类词，大概率是保留字。

第三个是Vue3 项目在部分浏览器里异常退出的怪问题。有人反馈说页面在 Edge 浏览器下偶尔会出现右上按钮无响应，最后排查是浏览器插件冲突。这类问题和项目本身关系不大，但也要知道——当本地跑得好好的、换个环境就出怪事时，先怀疑环境而不是代码。

8.3 赶时间的朋友可以直接复制这套部署检查单

每次部署前按下面的清单过一遍，能省掉大半的报错时间：

• MySQL 服务已启动，且端口 3306 没被占用（用netstat -ano | findstr 3306查）。
• 后端数据库账号密码与 application-dev.yml 一致。
• 本机 JDK 版本与 pom.xml 中 java.version 匹配。
• 前端依赖已安装（node_modules 存在），且代理 target 端口为后端实际端口。
• 所有路径中的端口号没有写死成过期的值。

测试时先用管理员账号登录后台，创建一条菜品分类，再添加几个菜品，然后模拟用户下单一整单，看订单状态流转和库存扣减是否正常。这套验证流程走完，系统基本就是可跑的。

个人经验上，最容易被忽略的反而是软件版本之间细微的兼容问题。比如 JDK 版本过高导致 Lombok 失效、Node 版本过低导致 Vite 装不上、MySQL8.0 的驱动版本过旧导致认证报错。如果跑项目时遇到"看似配置都对但就是不行"的状态，第一反应先去确认工具链版本，这比反复检查代码有效得多。