一个 SpringBoot + Vue 的私房菜定制上门服务系统，光看标题可能觉得就是一个普通的管理系统，但真正动手做过的人会知道，这类“定制 + 上门 + 多角色”的业务模型，远比表面看起来复杂。它不是简单的 CRUD 堆砌，订单状态的流转、厨师和用户的交互边界、定制需求的表达方式，每一处都在考验你对真实业务的理解。这篇文章我会把这个系统从设计到落地的完整思路拆开讲，包括数据库怎么建、接口怎么定、Vue 前端怎么组织权限和页面，以及我在实际开发过程中踩过的一些坑。
先说清楚这套系统到底做了什么。整个平台面向三类核心角色：普通用户、私房菜厨师（服务方）、平台管理员。用户可以在平台上浏览私房菜菜单，按照自己的口味偏好提交定制需求，选择期望的上门服务时间段和地址；厨师接收订单后可以报价或直接确认，按约定时间上门制作；管理员则负责审核菜品信息、管理用户和厨师的状态、处理异常订单和基础数据维护。业务流程看起来不复杂，但真正落到代码里，你要处理的就远不止是增删改查了。
这套完整方案里包含三样核心资产：后端 Java 源码、前端 Vue 工程、MySQL 的 SQL 初始化脚本，以及一份接口文档。对于正在做毕业设计、或者想快速上手一个真实业务系统的开发者来说，它的价值在于，能让你在一套完整、自洽的代码基础上，去理解一个多角色业务系统的工程结构是怎么组织的，而不是从零开始东拼西凑。
1. 系统整体设计与需求拆解
先别急着打开 IDE 看代码，把业务模型想明白，后面的开发会顺利得多。我做这套系统时，首先做的一件事不是建表，而是把整个平台的核心流程画了一遍，搞清楚每个动作由谁发起、要经过哪些环节、会产生什么数据。这个思考过程，决定了后面所有接口的设计方向。
1.1 核心用户角色与权限边界
这个系统里有三种角色，每种角色眼中的“系统”完全不一样，所以数据权限一定要在开发之前就理清楚：
- 普通用户（C 端）：浏览菜品、提交定制需求、查看订单状态、确认评价。用户只能操作自己的数据。
- 私房菜厨师（B 端）：维护自己的菜品、查看分配给自己的订单、更新订单状态（接单、完成），以及管理自己的服务档期。厨师同样只能看到与自己相关的数据。
- 平台管理员（后台端）：负责内容审核，比如下架不合规的菜品、处理用户纠纷、管理角色状态（禁用/启用账号），能看到全平台的数据统计。
这个权限边界直接决定了你在数据库表设计时要预留什么样的角色字段，也决定了在 Vue 前端要做什么样的路由守卫和动态菜单。
1.2 业务状态机：订单是系统的灵魂
整个系统里最核心的业务实体就是订单。围绕订单，会经历“用户提交定制需求 → 厨师确认接单 → 上门服务 → 服务完成 → 用户评价”这几个状态。我在设计订单状态字段的时候，直接用了整数枚举，而不是字符串。这样前端拿到数字字典去映射文本状态，后端判断状态流转时也方便，不会因为大小写、空格导致判断出错。
订单状态我用的是：
- 0：待接单（用户已提交，等待厨师确认）
- 1：已接单（厨师已确认，准备上门）
- 2：服务中（厨师已到达或已开始制作）
- 3：已完成（服务结束）
- 4：已取消（用户或者管理员取消）
这里有一个很关键的细节：状态只能向后流转，不允许跳转，比如“待接单”不能直接变“已完成”。我在后端接口里做了状态校验，每次更新订单状态的时候都必须传入当前状态值，只有当数据库里的状态与传入的当前状态一致时，才允许更新到下一个状态。这个做法能挡住绝大部分脏数据操作。
1.3 功能模块拆分
从功能结构上看，整个系统可以拆成八个模块：
- 用户模块：注册登录、个人信息维护、地址管理
- 厨师模块：注册入驻、资质信息维护、服务时段设置
- 菜品模块：菜品的分类、列表、详情、上下架管理
- 定制需求模块：用户发起定制，填写口味偏好、忌口、预期价位、期望服务时间
- 订单模块：订单创建、状态流转、订单详情、订单列表
- 评价模块：服务完成后的评分与评论
- 公告模块：平台动态、通知信息的管理
- 管理后台：用户管理、厨师审核、菜品审核、订单监督、数据统计
每个模块再继续拆解出具体的页面和接口。比如菜品模块，对于厨师端来说就是“我的菜单”，需要支持新增菜品、设置价格、上传图片、调整库存或可接单量；对于用户端来说就是“逛菜单”，需要分类筛选、关键词搜索、查看详情。同一个模块，在不同角色眼里的功能需求是完全不同的，这个在需求设计阶段就要区分清楚。
2. 数据库设计与 SQL 脚本细节
数据库是整个系统的地基。视图和接口可以随时调整，但表结构一旦定型，后面改动成本就很高了。我在这套系统里一共设计了十几张核心表，初始化 SQL 脚本里也包含了基础数据和测试数据。下面挑几个重点表来说说设计思路。
2.1 数据表全景与设计思路
一张订单主表，一套用户体系表，再加内容管理相关的菜品和分类表，这就是系统数据库的骨架。具体来说，核心的表有以下这些：
- sys_user：用户表，含用户名、密码（加密存储）、角色类型（用户/厨师/管理员）、手机号、状态
- chef_info：厨师信息表，与 sys_user 一对一关联，存储厨师的简介、服务区域、擅长菜系、资质图片地址
- dish_category：菜品分类表
- dish：菜品表，含菜品名称、描述、图片、价格、分类ID、所属厨师ID、状态（上架/下架）
- custom_requirement：定制需求表，记录用户的口味偏好、忌口说明、期望价格区间、期望时间段
- service_address：用户收货/服务地址表
- orders：订单主表，含订单编号、下单用户ID、厨师ID、菜品ID、定制需求ID、服务地址、状态、金额、下单时间
- order_status_log：订单状态变更日志表
- review：评价表，关联订单和用户，记录评分和评论内容
2.2 订单表的设计误区与优化
很多初学者在设计订单表时，倾向于把用户填写的所有信息一股脑塞进一张表里，包括服务地址、定制需求、菜品内容全部冗余进去。但在我这套系统里，订单表不存冗余的地址文本，而是存 service_address_id，定制需求也只用 custom_requirement_id 去关联。
为什么这么做？因为地址和定制需求是独立变化的业务数据。用户在 A 地址下单，不代表下次还要用 A 地址；订单生成后，需求内容应该保持不可变，如果后续用户改了定制需求，订单里关联的记录却变了，这会引出业务纠纷。所以下单时需求信息是复制快照进 custom_requirement 表，而不是让订单表直接引用用户实时数据。这个设计在真实业务里非常重要。
另外要注意的一个细节是，金额字段我用的是 DECIMAL(10,2)，而不是 FLOAT 或者 DOUBLE。浮点数在金额计算时会有精度丢失的问题，比如 0.1 + 0.2 等于 0.30000000000000004。数据库里存金额别用浮点，Java 代码里也别用 double 去计算金额，要用 BigDecimal。这个坑我在项目初期就碰上过，算总价的时候出现了几位小数的误差，排查了半天才发现是数据类型的问题。
2.3 SQL 脚本中的初始化数据策略
拿到这套系统的 SQL 脚本时，你可能会注意到脚本里不仅有建表语句，还插入了一批初始数据。这些数据主要分三类：
- 基础字典类：比如菜品分类、订单状态的说明数据
- 演示账号类：一个用户账号、一个厨师账号、一个管理员账号，方便你直接登录系统看效果
- 示例业务类：几条菜品数据、几条定制需求记录，让页面不至于空空如也
在写你自己的初始化脚本时，有两点建议值得参考。第一，所有的密码字段存的是 BCrypt 加密后的字符串，千万不要用明文存密码，后续如果要接 Spring Security 做登录认证，你会省掉很多麻烦。第二，测试数据的 ID 要尽量固定，不要用数据库自增去碰运气，固定 ID 方便你在 Python 脚本或 HTTP 工具里做接口测试，也方便调试数据关联。
一个关于 SQL 导入的提醒：执行脚本时要把 sql_mode 里的 ONLY_FULL_GROUP_BY 考虑进去。不同的 MySQL 版本默认的 sql_mode 不同，如果脚本里用了 GROUP BY 查询，在低版本 MySQL 上可能正常，换了高版本就容易报错。我第一次导入供应商给的脚本时，就碰到了 ONLY_FULL_GROUP_BY 报错，最后是在数据库配置里临时修改了这个模式才跑通。
3. 后端 SpringBoot 核心实现
后端这一层用的是 SpringBoot，整体结构遵循了常见的分层架构：Controller 层负责接收请求，Service 层处理业务逻辑，Mapper 层（DAO）对接数据库。如果你的工程里引入了 MyBatis 或 MyBatis-Plus，那么 Mapper 层还能省掉不少手写 SQL 的工作量。
3.1 工程结构与包组织
我建议你在拿到源码后，先花十分钟把包结构理一遍，不要急着启动。标准的包组织是这样的：
- controller：存放 REST API 入口
- service：业务逻辑接口和实现
- mapper：数据访问接口，配合 XML 或注解使用
- entity（或者在用 MyBatis-Plus 时叫 po/domain）：数据库实体类
- dto：前端请求参数的封装对象
- vo：返回给前端的视图对象
- config：配置类（跨域、拦截器、全局异常处理等）
- common：统一返回结果、常量、工具类
这里给你一个建议，返回给前端的数据，最好不要直接返回数据库实体对象。比如表格分页查询时，用户表里有密码字段，如果你直接把实体对象返回回去，密码就直接暴露在响应体里了。正确做法是定义一个 UserVO，只保留前端需要的字段。这个小细节，是代码规范里经常提到但在实际项目里很容易忽略的点。
3.2 统一响应结构设计
前后端联调时最怕什么？怕前端拿到一堆格式不统一的数据，一会是成功返回的是对象，一会失败返回的又是字符串。所以我在设计接口文档时就定了统一响应结构：
{ "code": 200, "message": "操作成功", "data": { } }后端用一个泛型类 Result 包装所有接口的返回值。code 为 200 表示成功，其他数字表示各类业务错误码。这样做有两点好处，一是前端 axios 拦截器可以统一处理 code，不需要每个接口单独判断返回值结构；二是全局异常处理器可以把 RuntimeException 转换成统一格式，前端只需要关心 code 就行。
我自己习惯的做法是，在 controller 层直接返回 Result 包装好的对象，Service 层只返回业务数据。Controller 层像是“翻译官”，把业务结果包装成前端约定的格式。这样分工，Service 层做单元测试时也更干净，不用构造一大堆响应包装对象。
3.3 登录鉴权与密码处理
系统涉及不同角色，所以在登录鉴权上不能只靠 Session 硬写。这套系统采用的是基于 JWT 的 Token 鉴权方案。用户在登录接口提交用户名和密码，后端校验通过后生成一个包含用户 ID、角色信息的 Token 字符串返回给前端。前端后续每次请求都在请求头里带上Authorization: Bearer <token>，后端用拦截器或过滤器来解析验证 Token。
具体到拦截器，我用的是 Spring Boot 的 HandlerInterceptor 加 WebMvcConfigurer 注册的方式。在 preHandle 方法里做 Token 解析，如果 Token 无效直接返回 401 状态码。这里需要特别注意放行规则，登录接口、注册接口、图片资源等不需要鉴权，其他接口建议统一拦截，然后在拦截器里根据角色代码判断权限。
密码这块强烈建议采用 BCrypt 加密。Spring Security 自带的 BCryptPasswordEncoder 可以直接拿来用。它的特点是同一密码每次生成的哈希值都不同，因为内部带了随机盐，这样就算两个用户密码相同，数据库中存的哈希也完全不一样。这样做能有效防止彩虹表攻击。
3.4 订单接口的状态校验逻辑
订单接口是我在整个后端实现里写得最小心的地方。以“厨师接单”为例，接口接收的参数是一个订单 ID。Service 层里的逻辑顺序是这样的：
- 根据订单 ID 查询订单记录，如果记录不存在，直接抛异常
- 校验订单当前状态是否为待接单（status = 0），如果不是，说明订单已经被处理过，抛出状态冲突异常
- 校验当前登录的厨师是否为该订单关联的厨师
- 执行更新操作，把状态改为已接单
- 写入订单状态变更日志
public void acceptOrder(Long orderId, Long chefId) { Orders order = orderMapper.selectById(orderId); if (order == null) { throw new BusinessException("订单不存在"); } if (order.getStatus() != 0) { throw new BusinessException("当前订单状态不可接单"); } if (!order.getChefId().equals(chefId)) { throw new BusinessException("无权操作该订单"); } order.setStatus(1); orderMapper.updateById(order); orderStatusLogMapper.insert(new OrderStatusLog(orderId, 0, 1, "厨师接单")); }这段代码看着简单，但两个校验缺一不可。状态校验防止重复接单，归属校验防止越权操作。第二个校验非常容易被忽略，不少系统就是吃了这个亏，用户只要能构造出订单 ID 就能操作别人的订单。在做这类多角色业务系统时，每写一个接口都要问自己一句：当前登录的用户能不能操作这条数据？
3.5 多条件查询的参数处理
菜品和订单的列表页都有筛选功能，比如按菜品分类筛选、按价格区间筛选、按订单状态筛选。这个在接口层直接用多个可选参数接收就行。如果你用 MyBatis-Plus，可以直接用 LambdaQueryWrapper 动态拼接条件。
但要注意一个细节，前端传参时可能传过来空字符串。比如分类 ID 为 "" 时不传，参数是可选。这时要在后端做一次空判断，空字符串和 null 都要拦掉，不然查询条件里拼出一个category_id = ''，数据库里匹配不到任何数据。还有一个和排序相关的坑，用字符串拼接排序字段时要防止 SQL 注入，最好是白名单方式限定允许排序的字段列表，而不是把前端传来的字段名直接原样拼接。
4. Vue 前端实现与前后端对接
前端这部分用的是 Vue，工程结构是你非常熟悉的 Vue CLI 或 Vite 初始化出来的单页应用。虽然技术上不复杂，但要把角色权限和页面组织得清楚，同样需要前期规划。我在做前端时重点解决了三个问题：路由权限控制、Axios 请求封装、以及复用性较好的列表页组件写法。
4.1 前端工程结构与权限路由
前端工程分成了几个主要的目录：
- src/api：所有接口请求方法的封装，按模块拆分文件
- src/router：路由配置
- src/store（或 Vuex/Pinia）：全局状态管理，保存用户信息、Token
- src/views：页面组件，按角色模块分子目录
- src/components：通用组件
- src/utils：请求封装、工具函数
权限控制的核心思路是：登录成功后，后端返回用户角色（role），前端把角色信息存到全局状态里。在路由配置里给需要权限的页面路由添加 meta 字段，例如 meta.roles 标明哪些角色可以访问。然后在全局路由守卫（beforeEach）里做判断，如果用户未登录则跳转到登录页，如果已登录但访问了没有权限的页面，则重定向到首页或 403 页面。
router.beforeEach((to, from, next) => { const token = store.state.token; if (!token && to.path !== '/login') { next('/login'); } else if (token && to.meta.roles && !to.meta.roles.includes(store.state.role)) { next('/403'); } else { next(); } });需要注意一个细节，如果用动态路由的方式，你还要考虑刷新页面后路由可能丢失的情况。因为动态路由是在登录后根据角色往 router 里 addRoute 的，刷新页面后内存里的路由表会重置，需要在用户信息加载完毕后重新挂载路由。我习惯用一个公共的菜单生成函数，每次刷新时根据角色重新构建动态路由。
4.2 Axios 请求封装与拦截器
前端所有请求我都封装在一个 request.js 模块里。Axios 实例统一设置了 baseURL，这样在开发环境可以直接代理到后端地址，生产环境可以换成真实接口地址。拦截器的职责有两条：
- 请求拦截器：从 store 里取 Token，添加到请求头
- 响应拦截器：判断后端的 code 字段，如果 code 不等于 200，弹出错误提示，并直接 return Promise.reject，让页面不再往下执行；如果遇到 401，就清除本地登录态并跳转到登录页
service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { Message.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res; }, error => { if (error.response && error.response.status === 401) { store.dispatch('logout'); router.push('/login'); } return Promise.reject(error); } );有个我在联调阶段经常遇到的问题：跨域。前端跑在 8080 端口，后端跑在 9090 端口，浏览器会因为同源策略拒绝请求。解决办法有两种，一种是在后端配置 CORS，另一种更适合开发阶段，就是在 Vue 的 vue.config.js 里配置 devServer 的 proxy，把所有 /api 开头的请求都代理到后端的 9090 端口。用 proxy 的好处是浏览器看到的是同源请求，基本不会出现跨域报错。
devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true } } }4.3 列表页与表单页的组件化写法
系统里列表页很多，菜品列表、订单列表、用户列表、评价列表，它们的交互模式几乎一致：顶部是搜索条件，中间是表格，底部是分页。把这些共通的部分抽成一个通用列表组件，能大幅减少重复代码。
我的做法是，页面负责定义搜索字段和表格列配置，通用组件负责渲染和触发查询事件。父组件通过 props 向子组件传配置，子组件通过 $emit 事件向父组件报告“查询”“翻页”等操作。这样每个具体页面的代码量能砍掉一半左右。如果你用的是 Vue 3 组合式 API，也可以用 v-model 的机制把搜索条件绑定到一个响应式对象上。
同时要注意，表格里的状态字段在前端要做字典映射。后端返回的是数字状态值，前端定义一个字典对象，比如：
const orderStatusMap = { 0: '待接单', 1: '已接单', 2: '服务中', 3: '已完成', 4: '已取消' };然后用一个管道函数把这组映射关系用在模板里展示。这种方式比让后端直接返回中文状态更合理，因为后端加状态值时，前端改一套映射就行，不需要改接口和数据库。
5. 接口文档的价值与正确打开方式
如果你拿到的这套项目里附带了一份接口文档，那它对理解代码的帮助，甚至会超过源代码本身。接口文档本质上是前后端之间的“契约”，它规定了请求路径、请求方法、请求参数、响应格式、鉴权要求。在实际开发联调时，这份文档能省掉大量“你传的参数是什么”“你返回的是什么结构”的沟通成本。
5.1 文档应该包含哪些关键信息
一份合格的接口文档，每个接口至少要包含以下信息：
- 接口地址：比如 POST /api/order/accept
- 请求参数：参数名、类型、是否必填、参数说明
- 响应示例：成功的 JSON 示例和常见失败的 JSON 示例
- 鉴权要求：哪些接口需要带 Token
- 业务说明：状态流转的前提、特殊校验规则
刚接手这个项目时，我第一个常查的接口就是“用户登录”和“查询订单列表”。通过文档我能反推出前端的页面具体调用了什么数据，并能验证后端代码逻辑是否符合契约。如果在跑项目时发现某个页面空白或者数据加载失败，我会优先查浏览器 Network 面板里的请求和文档里的响应结构是否一致。
5.2 接口文档与代码的对应关系
看文档还有一种用法，就是反过来找代码。比如说，文档里写“查询我的菜品列表”的接口是 GET /api/chef/dish/list，那么你就可以直接去后端工程里搜索这个路径，找到对应的 Controller 类和方法，顺藤摸瓜把整个业务链路的代码都看一遍。这种方法比在 IDE 里乱点不知道快多少。
当你理解了这套流程之后，还可以给文档添加一些注解和标注。比如某个接口删单状态后，文档里标注了“仅当订单状态为待接单时可取消”，那你在后端代码里就会下意识去找这段状态校验，发现没有实现时，你会明白这是功能缺失，需要补齐，而不是一句“代码就是这样的”糊弄过去。
5.3 用接口调试工具自测
接管项目后，我建议用接口调试工具把这套系统的核心接口全部自测一遍，别等前端跑起来再发现后端是坏的。工具选常见的调试工具或 IDE 内置的 HTTP Client 都行。测试的重点是业务流程：注册新用户、用用户身份登录、创建一个定制需求、查看菜品列表、切换厨师账号登录、接受订单、模拟完成订单，最后用用户身份提交评价。这一条龙测完，系统的主干功能基本就有保障了。
有一个问题很容易在这个阶段暴露：后端接口的鉴权要求。比如你用管理员账号去调用户下单的接口，后端可能并不校验角色，结果是管理员也能替用户下单。这类接口权限漏洞，只有你一个个接口手动测的时候才会发现。发现了就及时补上角色校验，这会显著提升系统的健壮性。
6. 常见问题排查与部署要点
在跑通这套系统的过程中，你会碰到几个典型问题。我把它们整理一下，按出现频率来排查。
6.1 启动与编译问题速查
后端启动失败、前端页面空白，究其原因大多是环境问题。下面把这些典型的坑列出来：
- 后端启动失败，报数据库连接错误：先检查 application.yml 里的数据源配置，主机、端口、用户名、密码是不是和你的 MySQL 环境一致。注意 MySQL 8 和 MySQL 5 的驱动类名不同：MySQL 8 用 com.mysql.cj.jdbc.Driver，MySQL 5 用 com.mysql.jdbc.Driver，而且 MySQL 8 的 URL 里通常要加 serverTimezone=Asia/Shanghai。
- 端口被占用：Spring Boot 默认占用 8080，如果你的前端工程也占了 8080，后端就要换个端口，比如 9090。修改 server.port 即可。前端代理配置的 target 地址也要同步修改。
- 前端运行报 node-sass 错误：这类老工程经常用 node-sass，如果你的 Node 版本太新很容易编译失败。解决办法是改用 sass（dart-sass），或者把 Node 降到项目要求的版本。
- SQL 导入报错：优先检查版本兼容性，比如外键约束、数据表的引擎。如果脚本里有中文字段，还要确保导入时使用 UTF-8 编码，否则会出现中文乱码。
6.2 跨域与登录失效
如果你没有配前端的 proxy，而是直接在前端代码里写死http://localhost:9090，浏览器报跨域错误非常正常。解决办法要么配后端 CORS，要么像上文那样在前端配代理。我建议优先用代理方案，因为它不涉及后端代码改动，更干净。
登录失效也是一个高频问题。Token 过期后，前端页面操作会连续报 401。解决办法是后端在 Token 过期时返回特定的错误码，前端在响应拦截器里识别到对应状态后，统一跳转登录页，并清除本地存储的用户信息。这里要注意 Token 的过期时间不要设置的太短，两个小时或一天是比较常见的做法，具体可以按项目要求调整。
6.3 代码版本管理与继续扩展
如果你要在这个项目基础上做二次开发，有几个方向可以试试。
- 接入支付模块：现在订单流程到“已完成”就停了，可以扩展一个支付环节，引入常用的支付网关进行对接。
- 加入消息通知：订单状态变更时，通过短信或站内信的方式通知用户和厨师。实际上这个在现在系统里可以抽象成一个 Message 表加一个异步发送的流程。
- 引入 Redis 缓存：菜品列表是典型的读多写少场景，可以把热点数据做缓存，减少数据库查询压力。
- 增强后台统计能力：目前管理员端关于数据统计的页面内容相对简单，你可以从“订单量按月走势”“厨师接单量排行”这类需求出发，增加一些聚合统计接口。
7. 个人实操总结
做这套系统时，我最大的体会是：一个业务系统的复杂程度，不在代码量，而在状态管理和权限控制的边界。你可能几百行代码就把 CRUD 写完了，但要让系统在真实场景中不崩，在脏操作面前不产生错误数据，需要大量这样的“防御性设计”。
另外一个我至今印象很深的经验，数据库的初始化脚本真的不是配角。一套带测试数据的脚本，可以让你在二十分钟内看到页面有内容、接口有数据可调，调试效率翻倍。反之，如果脚本里只有建表语句，你还要手动一条条 insert，光造数据就能耗掉一个下午。
最后再说一个关于代码阅读的小技巧：拿到这类完整项目后，可以按“登录 → 权限 → 核心业务 → 列表查询 → 状态流转”的顺序去读代码，你会发现每条线都能很快打通。顺着一条业务链路读完全部代码之后，这个系统的全貌在心里基本就跟明镜一样了。如果你能对照项目文档再动手跑一遍完整流程，把每个核心接口用调试工具打一遍，这套系统的要点就算彻底掌握了。
