做私房菜定制上门服务系统这段时间我把整个项目从数据库设计到前后端联调完整跑通了一遍。这套SpringBoot后端加Vue前端配MySQL的方案是一个可以直接拿来改的到家服务类项目骨架核心覆盖了用户下单、厨师接单、定制需求管理、订单流转和后台审核这么一整套闭环。如果你正准备做私房菜预约、上门烹饪、定制家宴这类O2O服务系统又不想从零去趟认证、订单状态机、权限拆分这些常规坑这篇内容值得你花几分钟看完我会把业务模型的拆解思路、关键模块的实现细节、数据库设计理由和本地运行的完整操作都过一遍。1. 系统整体业务拆解与核心需求解析1.1 私房菜上门这门生意的业务闭环私房菜定制上门服务和普通外卖平台有本质区别。外卖是把做好的菜送到用户手里而私房菜上门是厨师带着食材和工具到用户家里现场制作服务的是家庭聚餐、生日宴、私人宴请这类场景。这意味着系统的核心不是“点菜-出餐-配送”这么简单而是一套“提出需求-匹配厨师-上门服务-验收评价”的完整闭环。这套系统在设计时我把业务拆成了四个关键环节用户发起定制需求、系统匹配并展示合适厨师、厨师接单并上门服务、服务完成后的评价沉淀。每一个环节背后都有对应的数据模型和状态流转逻辑缺一个环节整个业务就跑不通。另外私房菜上门还有一个特殊性菜品的“定制”属性很强。用户不是从固定菜单里选菜而是提出自己的要求比如“家宴8人餐、口味偏清淡、预算1500以内、需要厨师自带海鲜食材”然后由厨师根据需求来设计菜单。所以在系统设计上定制需求单的地位和订单本身一样重要甚至更高。1.2 三类角色与四套核心流程这套系统设计了三个角色普通用户、私房菜厨师、平台管理员。三个角色共用一个后端服务通过角色字段和权限拦截器做区分没有拆成三个独立系统。用户侧的核心操作是浏览厨师列表、查看厨师详情和拿手菜、提交定制需求、支付定金或全款、查看订单状态、服务完成后评价。厨师侧的核心操作是维护个人信息和拿手菜品、设置可接单时间段、查看新需求并报价接单、管理自己的服务订单。管理员侧的核心操作是审核厨师的入驻资质、管理用户和厨师的账号状态、处理售后与投诉、查看平台整体的订单数据。四条核心流程分别是定制需求提交流程、厨师接单流程、订单执行与状态流转流程、评价与售后流程。其中接单流程是最容易出问题的这里用了“用户发需求-厨师报名报价-用户确认选择”的撮合模式而不是直接指派模式这样更符合私房菜行业的实际交易习惯。1.3 定制不是点菜需求单的灵活性设计我见过不少做这类系统的人把定制需求做成一个单纯的备注框这是最大的设计失误。私房菜定制里用户的需求往往包含人数、口味偏好、忌口、预算范围、是否需要厨师自带食材、用餐时间、服务地址等多个维度这些信息直接决定厨师能不能接单只看一段自由文本厨师无法快速判断需求是否匹配。这套系统的做法是把需求单做成了“结构化字段加补充说明”的组合人数、预算区间、用餐日期、期望服务时段、口味标签、特殊要求每个都是独立字段前端用表单组件收集后端单独存储。同时保留一个“补充说明”的文本字段用来承载个性化要求和不好结构化的内容。这样的设计有一个直接好处厨师的接单列表里可以直接按人数、预算、时段这些字段做快速筛选和匹配而不是靠肉眼去阅读需求备注。系统内嵌的推荐逻辑也可以基于这些结构化字段做初筛把明显不合适的厨师过滤掉。2. 技术选型逻辑与工程结构2.1 为什么选了SpringBoot加Vue这套组合技术选型这件事很多人容易跟风看到别人用微服务自己也上微服务看到别人用了消息队列也非要加一个。但这类管理系统实际情况是业务规模可控、并发量不大、核心诉求是快速上线和方便二次开发SpringBoot加Vue加MySQL这套组合刚好卡在“够用”和“好用”之间。SpringBoot的优势在于生态成熟、起步快、内置容器一个jar包可以跑起来配合Spring Security或拦截器可以快速实现权限控制。我在这套系统里用的方案是JWT做登录令牌加拦截器校验实现简单前后端分离也友好不需要依赖Session同步。Vue前端用Vue 2加Element UI的组合主要看重它的组件生态和中文文档完善度。管理后台和用户端复用同一套组件库表格、表单、弹窗、分页这些高频组件基本开箱即用。Vue 3加Element Plus也很成熟如果你更熟悉新版整个前端改造工作量也不算大。MySQL是这类业务最稳的存储选择事务支持可靠订单金额、预约状态这些关键数据不允许出现丢失或错乱MySQL的ACID特性保证了这一点。Redis在这套系统里没有作为强依赖只做可选配置因为核心业务不需要高并发缓存登录态用JWT后也不需要Redis存Session。2.2 后端工程结构与模块划分后端工程的包结构遵循了常见的分层方式但没有过度设计。整体按模块分包而不是按技术层分包这样业务边界比较清晰后续改动某一个功能时基本只会在对应的业务包内部操作。包结构大致是这样的config包放配置类包括跨域配置、拦截器注册、自定义异常处理controller层负责接口接收参数和返回统一结构service层处理业务逻辑mapper层做数据库操作entity包放数据库表对应的实体类dto包放接口入参和返回值的对象common包放统一Result类、常量定义、异常类等公共内容。我特意没有引入很重的代码生成器或复杂的分层框架因为这类系统的业务量不大手写实体类和Mapper反而更可控改起来也不会有牵一发动全身的隐患。对于熟悉MyBatis的开发者来说XML里写SQL比JPA的自动拼接SQL更直观排查问题时也更好定位。2.3 前端页面结构与路由规划前端部分按角色拆分了三个页面区域路由上做了权限拦截。用户端包含首页、厨师列表、厨师详情、提交需求、订单列表、订单详情、个人中心这些页面厨师端包含个人主页编辑、接单工作台、订单管理、收入记录等管理后台包含用户管理、厨师审核、订单管理、评价管理、数据概览。前端路由用Vue Router的守卫做登录态校验和角色拦截。在路由元信息meta里标记每个路由允许访问的角色路由跳转前判断当前用户的角色是否在允许列表内不匹配就重定向到登录页。这个方法比在每一个页面里手动判断权限要省事得多也避免了漏判。状态管理用的Vuex主要负责存登录用户信息、登录令牌这类全局数据。页面级的业务数据没有全部放进Vuex而是让各个页面自己去请求接口拿数据这样减少了状态管理的复杂度也避免组件间共享数据时出现状态污染。3. 数据库设计支撑“人、单、菜”的核心表3.1 用户与厨师账号体系的表设计数据库是这套系统的地基我梳理核心表的时候优先保障三块账号体系、厨师信息展示、订单与评价。用户表user的核心字段包括主键id、手机号、密码哈希值、昵称、头像地址、角色字段、状态字段、创建时间。手机号和角色分别做了唯一索引和普通索引手机号是登录账号角色字段区分用户还是厨师。这里要强调一个设计取舍用户和厨师不是两张分开的表而是同一张用户表加角色字段厨师相关的扩展信息单独放一张厨师信息表用用户id关联。厨师信息表chef_profile的核心字段有主键id、用户id、真实姓名、服务城市、服务区域、擅长菜系、从业年限、个人简介、服务价格区间、接单状态。接单状态这个字段很关键厨师可以主动切换“可接单”和“暂停接单”状态前端厨师列表的筛选会直接读这个字段。之所以把用户基本信息和厨师职业信息分开是因为一个人可能既是用户也是厨师也可以先以用户身份注册后来又申请成为厨师。两张表拆分后用户基础数据变更和厨师资料变更互不影响逻辑上更干净。3.2 菜品库与定制需求单表的设计思路菜品相关表我有两张一张是厨师拿手菜表chef_dish一张是定制需求单表custom_requirement。chef_dish表用来展示厨师的代表作品包含id、厨师用户id、菜名、菜品图片、菜品分类、菜品描述、参考价格。菜品表存在的意义在于让用户对厨师的风格和水平有一个直观了解私房菜领域“认人”比“认店”更重要厨师的拿手菜展示就是建立信任的第一步。custom_requirement表是业务设计上的核心点字段包含id、用户id、用餐人数、预算下限、预算上限、期望用餐日期、期望时段、口味标签、特殊要求、是否需要厨师自带食材、服务地址、状态字段、创建时间。状态字段需要用数字标记需求的所处阶段比如1表示待厨师报名、2表示厨师已报名待用户选择、3表示已确认已支付、4表示已完成、5表示已取消。需求单的设计直接决定了匹配效率。结构化字段让厨师端可以快速评估“这个活能不能接”不需要来回沟通确认基本信息。同时我也加了一个状态标记字段表示“是否已被处理”避免多个厨师同时报名后需求单仍显示“待报名”造成的重复报价。3.3 订单与评价表的状态机设计订单表order_info是整个系统的核心交易表字段包含id、订单编号、需求单id、用户id、厨师用户id、订单金额、定金金额、订单状态、支付状态、服务日期、预约地址、备注、创建时间、完成时间。订单状态我设计了五档待支付、待服务、服务中、已完成、已取消对应数字1到5。这套状态机是简化过的没有把退款、售后、申诉拆成太多细碎状态因为业务体量小状态太多反而增加理解成本。但状态的流转顺序是强制控制的后端在更新订单状态时会校验当前状态是否合法不允许跳状态更新。评价表review包含id、订单id、评分、评价内容、评价图片、创建时间。评价和订单绑定而不是和用户或厨师直接绑定这样保证一个订单只能有一条评价也可以准确知道评价对应的是哪一次服务。评价表在厨师详情页会做平均分展示。4. 后端核心功能实现要点4.1 登录认证方案JWT加拦截器的权限控制登录认证我选了JWT方案主要考虑到前后端分离和无状态扩展的需要。用户在登录接口提交手机号和密码后端校验通过后生成一个JWT令牌返回给前端前端存到本地存储里后续每个需要认证的请求都在请求头里带上这个令牌。JWT令牌里我放入了用户id和角色信息。后端写了一个登录拦截器在interceptor里统一解析请求头中的令牌校验签名和有效期然后把从令牌里解析出来的用户信息放入请求上下文方便controller层直接获取当前登录用户。密码存储用的BCrypt哈希不允许明文或简单MD5。BCrypt每次生成的哈希值带随机盐即使两个用户密码相同存储的哈希串也不同可以有效防止彩虹表攻击。这个细节我建议不要省安全类需求一旦上线后补就麻烦得多。4.2 定制预约下单的核心链路定制预约这条链路是这个系统业务流程最长、也最容易出现理解偏差的逻辑。我把完整链路拆给后端实现的时候分成了四步用户提交需求单、厨师报名响应、用户确认厨师、生成订单并支付定金。用户提交需求单的接口接收custom_requirement表对应字段的DTO对象后端做必填项校验后插入数据库状态置为待报名。厨师端工作台能拉到所有待报名状态下且符合自己服务条件的需求单符合条件就发起报名报名动作会写一条记录关联需求单和厨师。用户看到报名厨师列表后选择一位厨师确认此时系统生成订单记录需求单状态同步更新为已确认。生成的订单里包含了需求单关联的结构化信息、厨师信息、服务日期、金额等字段这样订单表自身就是完整的后续查看订单不需要再回查需求单。4.3 订单状态流转与厨师接单逻辑订单状态流转逻辑我写在了service层没有散落在controller里。用户支付定金后订单状态从待支付变为待服务服务当日厨师点击开始服务变为服务中服务完成用户确认后变为已完成。这些状态变更接口都做了权限校验只有订单关联的角色才能操作对应状态。厨师接单逻辑里有一个经验型细节需求单绑定了期望用餐时间但是厨师的档期我用了时间段字符串字段来做简单管理没有做复杂的日历时段表。具体实现是厨师维护一个可接单的日期范围系统在展示需求单时优先展示与厨师可接单日期匹配的需求。考虑到一个需求单可能被多个厨师报名报名表里设计了“是否被用户选择”字段用户选择一位后其他厨师的报名记录状态自动更新为未入选前端会同步显示报名状态变化避免厨师端还在等一个已经被别人接走的需求。这块逻辑不处理好上线后最直接的结果就是用户被厨师打电话问“为什么我报名了却不选我”。5. 前端关键交互与页面实现5.1 用户端从找厨师到提交需求用户进入首页看到的是按城市、评分、服务订单量排序的厨师卡片列表卡片上展示厨师头像、姓名、擅长菜系、服务价格区间和综合评分。点击卡片进入厨师详情页这里会展示厨师的完整介绍、拿手菜图片、历史评价列表。详情页上的“预约服务”按钮会跳转到需求提交页。这个页面是定制环节的前端主战场表单项和服务端字段一一对应包括人数、预算区间、日期、时段、口味标签、特殊要求、地址。口味标签这块前端做成了可多选标签组件选择结果以逗号拼接的字符串提交。提交成功页面会有明确的下一步提示告诉用户需求已发布、等待厨师报名。之后用户可以从个人中心的“我的需求”里查看当前需求有哪些厨师报名报名列表展示了厨师的基础信息和报价用户点击确认后跳转支付。整个流程按照用户的视角分成了清晰的步骤每一步都有对应的后端接口支撑。5.2 厨师端接单与档期管理厨师端的核心工作台是接单面板。这里列出所有符合条件的待报名需求单列表项展示人数、预算、日期、口味标签摘要点击展开能看到完整需求内容和服务地址。厨师可以在列表页直接点报名也可以进详情页看完需求再决定。厨师端还有一个“我的排期”设置页面用来管理可接单状态和维护可服务日期范围。这里的实现很轻本质上就是更新chef_profile表里的两个时间字段但前端用日历组件做成了可视化效果厨师点选日期范围后一次性提交。接单后的订单管理模块厨师可以查看已接订单列表到达服务地点后把订单状态从“待服务”改成“服务中”服务完成后点击“确认完成”。这组操作按钮在移动端适配时我做了底部固定按钮栏方便厨师在实际服务场景下操作毕竟多数厨师上门时拿手机为主。5.3 管理后台审核与数据概览管理后台用Element UI的布局搭建左侧菜单加右侧内容区。菜单按功能分模块包括仪表盘、用户管理、厨师审核、订单管理、评价管理。仪表盘页面用了几个简单的统计卡片展示平台数据包括总用户数、总厨师数、进行中订单数、累计订单金额。数据通过后端一个统计接口返回这里没有引入图表库的需求真实场景中早期查看订单总量和新增趋势就够了。厨师审核是后台的重要功能新申请的厨师状态是待审核管理员可以查看厨师提交的资质信息点击通过或驳回。通过的厨师才会出现在用户端的厨师列表中驳回的需要填写原因并支持厨师端看到驳回理由后重新提交资料。6. 本地部署与可直接运行的实现细节6.1 环境准备与数据库初始化本地跑这套系统需要准备的环境包括JDK 1.8及以上、Node.js、Maven、MySQL 5.7或8.0。JDK版本建议直接用1.8兼容性最稳如果有人用了JDK 11以上需要注意部分依赖的兼容性调整。数据库初始化是我重点说明的部分。项目里带了一份SQL脚本按顺序执行后会自动建库建表并写入一批演示数据。脚本里包含了用户表、厨师表、菜品表、需求单表、订单表、评价表等核心表的建表语句以及测试账号和示例菜品数据。执行SQL脚本前要确认MySQL的编码格式是utf8mb4这个编码能完整支持中文和特殊字符。在命令行执行source命令或在可视化工具里运行脚本都可以但要注意如果提示数据过长或乱码基本可以断定是编码配置的问题。6.2 后端启动与前端运行步骤后端启动前需要修改application.yml里的数据库账号密码为本地MySQL的实际账号密码然后确认数据库连接地址正确。在项目根目录执行maven的打包命令编译生成jar包然后通过java -jar命令运行也可以直接在IDEA里启动SpringBoot启动类。前端启动前需要确认Node版本和npm源。在项目前端目录执行npm install安装依赖然后npm run serve启动开发服务器。Vue项目的默认端口是8080如果和后端接口端口冲突需要在前端配置里修改dev-server的端口。前后端联调时需要保证接口地址配置正确。前端项目里有一个统一的请求封装文件基础URL指向后端接口路径后端启动后监听8080以外的端口或不冲突的端口。前后端分离模式下跨域问题通过后端的统一跨域配置类解决我在后端配置了允许跨域的路径、请求头和方法。6.3 联调中的常见坑位删掉一个我踩过最多的坑跨域配置遗漏导致前端页面能从后端拉到数据但提交表单时请求报跨域错误。排查方法很简单打开浏览器开发者工具看网络请求的响应如果提示CORS相关错误优先检查后端是否配置了允许该前端的来源而不是急着改前端。另一个高频坑是数据库连接池和MySQL版本之间的驱动差异。老项目常见的场景是MySQL 8.0环境用旧驱动连接启动时直接报驱动类错误。解决方法是确认pom文件里的MySQL驱动版本和本地数据库大版本对应。启动时如果遇到端口被占用SpringBoot默认8080端口冲突的概率很高。可以用lsof或资源监视器找到占用进程结束或者在yml文件里修改server.port换一个端口。这类基础问题不影响业务逻辑但版本不同遇到的情况会有差异提前了解能省不少排查时间。7. 常见问题排查与避坑速查表问题现象可能原因解决办法前端能打开页面但接口请求全部失败后端没启动、端口不对、跨域未配置确认后端进程和监听端口检查请求路径前缀是否正确登录报用户名或密码错误演示账号不匹配、密码字段哈希值错误确认SQL脚本是否完整导入检查登录接口入参字段名首页厨师列表为空厨师状态字段未设置为正常、城市筛选不匹配检查chef_profile的接单状态字段和城市数据提交需求时报错必填字段缺失、日期格式不对查看后端日志提示的具体字段前端格式需与后端一致订单无法从待支付变更为待服务状态流转条件不符、用户角色校验失败确认当前操作账号是否为订单关联厨师核对状态机逻辑这个表格覆盖了联调阶段出现概率最高的几类问题。实际操作时遇到报错先看后端控制台日志不要只看前端报错信息因为很多真实原因被前端框架层的提示包装过了。排查问题的通用思路我建议按顺序来先确认接口是否真的到达后端、排除网络和跨域问题再看后端日志代码抛出的异常类型、判断是参数问题还是逻辑问题最后检查数据库数据是否满足接口的预期条件、比如状态值或外键是否匹配。这一套流程走下来大部分联调问题半小时内能定位。8. 后续扩展方向建议8.1 支付与结算模块落地当前系统的订单停留在“生成订单、记录金额”阶段没有接入真实支付。扩展方向建议接入常见支付平台核心流程是下单时生成支付参数、前端拉起收银台、支付回调更新订单状态为已支付。接入支付后资金安全是优先级最高的事。签名验签、回调重试、订单金额一致性校验这些逻辑一定要做严支付回调的接口要设计成幂等的避免同一笔回调重复处理导致状态错乱。8.2 地图定位与上门路径优化私房菜上门服务非常依赖位置信息目前的地址字段是文本形式扩展时可以对接地图SDK用户选地址时在地图上打点存经纬度坐标。厨师接单后台基于坐标可以计算自己到用户家的距离和预计时间。更进一步的话可以增加配送费用根据距离自动计算、推荐顺路订单这类逻辑。这些需求在数据模型层面改动不大主要还是依赖经纬度坐标字段所以建表时保留冗余位置字段是好习惯。8.3 消息通知与实时提醒订单状态变化后用户和厨师需要及时收到提醒。现在的实现里状态变了只在页面显示用户需要手动刷新才能看到。扩展方向是接入短信服务或微信模板消息在状态变更的service方法里同步触发一个异步通知任务。同时可以在前端做WebSocket或轮询选一种方案让厨师工作台实时收到新需求报名提醒。轮询方案适合前期、改动小WebSocket更实时、但增加复杂度。按业务阶段来选择更合理。这套系统跑通之后我最大的感受是业务建模的优先级要永远高于技术细节。定制需求单、接单撮合、订单状态机这三块如果一开始设计乱了后面接支付、加消息通知都得连带改数据表成本会成倍放大。反过来把这几个核心模型定清楚SpringBoot和Vue表层的东西都是换汤不换药。你自己动手搭一套类似系统的时候也建议先从业务流程和数据库入手代码实现反而比想象中快。