一个 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全局状态管理保存用户信息、Tokensrc/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.DriverMySQL 5 用 com.mysql.jdbc.Driver而且 MySQL 8 的 URL 里通常要加 serverTimezoneAsia/Shanghai。端口被占用Spring Boot 默认占用 8080如果你的前端工程也占了 8080后端就要换个端口比如 9090。修改 server.port 即可。前端代理配置的 target 地址也要同步修改。前端运行报 node-sass 错误这类老工程经常用 node-sass如果你的 Node 版本太新很容易编译失败。解决办法是改用 sassdart-sass或者把 Node 降到项目要求的版本。SQL 导入报错优先检查版本兼容性比如外键约束、数据表的引擎。如果脚本里有中文字段还要确保导入时使用 UTF-8 编码否则会出现中文乱码。6.2 跨域与登录失效如果你没有配前端的 proxy而是直接在前端代码里写死http://localhost:9090浏览器报跨域错误非常正常。解决办法要么配后端 CORS要么像上文那样在前端配代理。我建议优先用代理方案因为它不涉及后端代码改动更干净。登录失效也是一个高频问题。Token 过期后前端页面操作会连续报 401。解决办法是后端在 Token 过期时返回特定的错误码前端在响应拦截器里识别到对应状态后统一跳转登录页并清除本地存储的用户信息。这里要注意 Token 的过期时间不要设置的太短两个小时或一天是比较常见的做法具体可以按项目要求调整。6.3 代码版本管理与继续扩展如果你要在这个项目基础上做二次开发有几个方向可以试试。接入支付模块现在订单流程到“已完成”就停了可以扩展一个支付环节引入常用的支付网关进行对接。加入消息通知订单状态变更时通过短信或站内信的方式通知用户和厨师。实际上这个在现在系统里可以抽象成一个 Message 表加一个异步发送的流程。引入 Redis 缓存菜品列表是典型的读多写少场景可以把热点数据做缓存减少数据库查询压力。增强后台统计能力目前管理员端关于数据统计的页面内容相对简单你可以从“订单量按月走势”“厨师接单量排行”这类需求出发增加一些聚合统计接口。7. 个人实操总结做这套系统时我最大的体会是一个业务系统的复杂程度不在代码量而在状态管理和权限控制的边界。你可能几百行代码就把 CRUD 写完了但要让系统在真实场景中不崩在脏操作面前不产生错误数据需要大量这样的“防御性设计”。另外一个我至今印象很深的经验数据库的初始化脚本真的不是配角。一套带测试数据的脚本可以让你在二十分钟内看到页面有内容、接口有数据可调调试效率翻倍。反之如果脚本里只有建表语句你还要手动一条条 insert光造数据就能耗掉一个下午。最后再说一个关于代码阅读的小技巧拿到这类完整项目后可以按“登录 → 权限 → 核心业务 → 列表查询 → 状态流转”的顺序去读代码你会发现每条线都能很快打通。顺着一条业务链路读完全部代码之后这个系统的全貌在心里基本就跟明镜一样了。如果你能对照项目文档再动手跑一遍完整流程把每个核心接口用调试工具打一遍这套系统的要点就算彻底掌握了。