做私房菜定制上门这套系统前后端分离是我第二个版本才落地的方案第一个版本用的还是传统的服务端模板渲染改版时折腾了不少但改完回头看非常值得。SpringBoot Vue MyBatis MySQL这四个词基本是目前中小型Web项目里最常见的组合之一也是面试官和答辩老师最熟悉的一套拿它做项目起码不用担心被问到底层细节时无话可说。这套系统覆盖的角色和业务链路比较完整顾客端、厨师端、平台管理端都做了从菜品定制、选厨师、预约上门时间到下单支付、评价售后是一条完整闭环。这套项目适合谁课程设计、毕业设计、以及想完整跑通前后端分离流程的开发者都适用。如果你刚学完SSM和Vue基础想找一个综合性强一点、真实业务场景明确的项目练手这个也合适——它不是玩具项目订单状态流转、角色权限控制、预约排期冲突这些真实业务点都有跑通一遍之后你对整个Java Web开发的认知会清晰很多。1. 技术选型为什么这套组合最稳1.1 前后端分离不是炫技是效率妥协很多同学纠结要不要做前后端分离觉得多了一层接口调用复杂度更高。我的观点恰恰相反做完整源码项目前后端分离比模板渲染省事得多。模板渲染虽然写代码时少一步API调用但前后端逻辑混在一起前端一改样式后端模板就得跟着动后端一改数据传递前端页面也遭殃。两个人在一个项目里协作几乎是互相添乱。前后端分离之后前端只管Vue页面和调用API后端只管接口和业务逻辑两边可以并行推进。调试阶段更舒服前端可以用Mock数据先跑页面后端用Postman测接口返回互不阻塞。对毕设和课设来说分开还有一个额外的好处——答辩时可以演示的内容变多了分别展示后端接口返回、前端页面渲染、数据库落库情况展示的信息量直接翻倍。技术深度上也好讲跨域处理、JWT鉴权、接口规范这些话题都能展开聊几句比干巴巴一句用了SpringBoot和Vue要扎实得多。1.2 SpringBoot MyBatis常规但可靠SpringBoot选它核心原因是配置量少不需要像SSM时代那样堆一大堆XML配置文件。而且Spring生态的普及度摆在那里不管你把这个项目交给谁接手别人都不会觉得陌生。MyBatis之所以和SpringBoot配合得稳定是因为它的半ORM特性对SQL控制力很强这套系统里涉及不少多表联查和条件统计手写SQL可以精确控制每一行语句的行为调试时也方便直接复制SQL到数据库工具里跑不像JPA那样遇到复杂查询还要折腾规范。MySQL作为数据库免费、轻量、文档丰富Navicat和命令行都能操作部署成本几乎为零。整套系统只需要一个数据库实例和一份SQL脚本就能跑起来不会在环境准备阶段卡住人。这类项目最重要的就是开箱能跑一旦环境上出问题很多新手直接就放弃了。1.3 Vue Element UI生态成熟度优先前端选择Vue是因为它的学习曲线相对平缓组件化和数据响应式的理念对新手门槛不高。这里用的方案是Vue 2 Element UI不是为了守旧而是我实测下来最省心的一套组合。Element UI的表单、日期选择、表格分页、弹窗提示几乎全是现成的写管理后台页面时改属性就能用一天的活能压缩到半天。Vue 3 Element Plus当然也可以跑核心接口调用逻辑不受影响但组件API有差异从Vue 2的项目迁移过去需要动不少模板代码。如果你手里时间紧不要在这个环节上折腾版本升级先把业务链路完整跑通比什么都重要。2. 角色权限与核心业务链路设计2.1 三类角色的权限划分与登录鉴权这套系统把用户划分为三类角色顾客、厨师、管理员。数据库里user表通过role字段区分0是顾客1是厨师2是管理员。用户登录成功之后后端签发JWT令牌令牌里包含用户的id和role后续每次请求后端都通过拦截器校验令牌再结合自定义注解判断该角色是否有权限访问当前接口。顾客能做的事注册登录、浏览菜品和厨师、提交定制需求、选择上门时间、下单支付、确认完成、评价订单。厨师能做的事查看新订单、接受或拒绝、查看定制需求明细、设置个人排期、管理私房菜谱、查看收入记录。管理员能做的事审核厨师入驻申请、管理菜品分类、管理用户状态、查看监控所有订单、处理售后反馈。权限控制虽然实现难度不高但梳理清楚很关键。后端除了登录接口其他接口一律校验token再根据角色决定放行还是拒绝。前端也要配合Vue Router里配置meta字段标记角色路由守卫根据当前用户角色统一拦截。前后端双重控制一方面防止绕过界面直接调用接口另一方面也提升了系统的整体安全性。实际项目里接口权限漏配一个别人就能通过工具直接访问到管理接口这个问题我在早期的版本里踩过。2.2 订单主链路与状态机设计整套系统的核心链路是顾客提交定制需求选择菜品、填写口味偏好、设置上门地址、选时间→ 系统根据厨师排期匹配可接单人选 → 顾客下单 → 厨师端看到新订单 → 厨师接单/拒单 → 按约时间上门服务 → 顾客确认完成 → 顾客评价 → 订单完成。订单状态不能只用布尔值表示状态机必须清晰。我设计的状态是待接单(0) → 已接单(1) → 服务中(2) → 已完成(3) → 已评价(4)另外保留取消状态(-1)和退款状态(5)。状态流转不能随意跳跃比如已完成(3)的订单不能直接变回待接单(0)Service层必须有校验逻辑不能只依赖前端传参数。这一点在答辩时很加分——你讲清楚为什么用状态机而不是简单flag就体现出真实业务思维了。2.3 定制菜品的价格计算逻辑定制菜品的核心不只是让顾客填一个备注框而是可以对菜品进行结构化定制。我单独设计了一张customization表记录基础菜品id、口味偏好辣度/甜度等、食材替换要求、加料选项和备注信息。重点是价格计算不能只是固定菜品的原价否则定制就名存实亡。价格计算采用两步法菜品底价加上配料加价再加口味附加费。举例来说辣子鸡底价58元顾客选加一份鸡腿肉加8元选重辣口味加5元最终是67元。菜品底价存储在dish表配料选项存ingredient_option表管理员在后台维护前端拿到菜品ID后动态渲染配置项后端根据选项组合实时计算价格。这个逻辑一旦跑通整个定制模块的完成度就立起来了比那些只有一个文本框的项目高级太多。3. 核心功能模块的完整实现3.1 菜品分类与菜谱管理菜品分类用category表一层结构就够不搞多级嵌套。分类包括川菜、粤菜、江浙菜、时令菜、甜品汤品等。每个菜谱挂在分类下面菜谱表recipe保存菜品的基础信息名称、图片、底价、简介、口味可选列表用JSON字符串存储解析也方便。菜品图片上传用了后端静态资源映射。SpringBoot配置了upload目录的映射上传的图片保存到本地前端img标签直接就能访问。这个方案简单可靠适合本地部署场景。需要注意一个坑不要把图片存储在target编译目录内部否则重新打包会清空丢失正确做法是配置一个独立的物理路径这个问题在后面排坑实录里再细说。3.2 预约排期与并发冲突处理厨师要维护自己的可接单时间。schedule表里存厨师ID、日期、开始时间、结束时间、是否被占用状态。顾客在下单页面选时间段时前端只展示空闲时段提交订单时后端再做一次兜底校验避免两个用户同时抢同一个时间段。先查询后插入的方式存在并发隐患。实际操作中我做了两层防护第一层状态更新采用条件更新也就是UPDATE schedule SET status1 WHERE id? AND status0通过受影响行数判断是否抢单成功第二层业务上在订单表里为schedule_id加了唯一约束双保险。如果你在答辩时能讲明白这两层并发保护背后的数据一致性问题比写一堆业务代码更能体现水平。3.3 评价、退款与售后链路订单完成后顾客可以评价订单。review表记录评分1-5分、文字内容和上传图片。评分还会反哺到厨师列表页的平均分数让流量聚集到服务质量更好的厨师身上形成正向循环。售后主要针对退款/投诉场景。顾客发起申请后后台管理员审核通过后订单状态改为已退款。系统没接入真实支付退款操作的是模拟余额账户表里加了一个balance字段下单时冻结金额退款时原路退回。实际这个逻辑可以和真实支付非常平滑地对接只需要把模拟余额扣减替换成调用支付平台退款接口即可。类似项目里常见的错误做法是把退款实现成删除订单。订单是核心业务数据删掉会导致对账失败、数据统计残缺、用户行为分析断层。正确做法是保留订单记录通过状态字段标记退款这套设计才能支撑之后任何数据层面的分析。4. 数据库表结构设计与初始化4.1 核心表结构总览整套系统的核心表大概有这些user表用户、category表分类、dish表菜品菜谱、ingredient_option表配料选项、customization表定制记录、schedule表厨师排期、address表上门地址、orders表订单、order_item表订单明细、review表评价、refund表退款申请。表数量控制在10张上下既有足够的业务复杂度又不至于让新手看了头大。字段设计时遵循一个原则能用枚举值表示的不用字符串存长描述比如role和status字段用tinyint存数字在代码里定义常量映射这样查询和统计都高效。时间字段统一用datetime类型谁创建、谁更新、什么时候创建、什么时候更新这类审计信息全部带上排错时特别有用。4.2 关键表字段说明orders表是业务核心重要的字段包括订单号order_no业务编号方便人工查询、顾客ID、厨师ID、定制ID、地址ID、总金额、状态、下单时间、预约时间、完成时间。订单号建议不要直接用自增ID而是在代码里生成带日期的编号比如20250614103200123这样客服或管理员在后台查询订单时直接根据时间定位也好记忆也好都比一堆数字随机串直观得多。schedule表也很关键字段厨师ID、日期、开始时间段、结束时间段、状态。这里时间字段我存的是时间戳或者datetime方便做条件区间查询。如果只存一个字符串排期比较和冲突检测都会很难写。4.3 演示数据的准备与导入技巧数据库建好后需要导入三部分数据表结构、初始账号、演示数据。演示数据这一步极其重要。系统里直接塞满菜品分类、菜品记录、几个厨师账号、几个顾客账号、若干已完成订单打开系统第一眼就能看到完整的效果节省你手动造数据的大量时间。演示账号建议管理员admin/123456顾客user01/123456厨师cook01/123456。注意这些账号存在SQL脚本里的密码不是明文是BCrypt加密后的字符串安全考虑。如果导入后登录不上大概率是密码加密方式或者字符编码出问题重新生成BCrypt密文替换即可。5. 本地开发环境部署教程从零到一5.1 环境准备清单开始之前先把基础环境装好JDK 1.8这个项目的Java版本建议8稳定性最佳Maven 3.6以上MySQL 5.7或8.0Node.js 14以上IDEA或Eclipse后端开发VSCode或WebStorm前端开发有Docker基础的话MySQL数据库用容器跑更方便一条命令就能启动还能免去本机安装和服务的各种烦恼。不过这个项目本身对MySQL版本没有强依赖常规安装也完全OK不必为了炫技引入额外复杂度。5.2 后端工程启动步骤后端项目的启动分四步。第一步用IDEA打开SpringBoot工程等待Maven自动下载依赖这一步比较慢但不要中断你可以顺手浏览下代码结构。第二步修改application.yml里的数据库连接信息把url、username、password改成自己本机的值。第三步确认启动端口没有冲突默认8080你本机如果有其他项目占用了改一下server.port即可。第四步运行启动类看到Started xxxApplication的日志说明后端已经起来了。后端启动后先不要急着去联前端用浏览器或者Postman直接访问一个最简单的接口比如http://localhost:8080/api/health确认接口返回正常再往下走。5.3 前端工程启动步骤前端项目是标准Vue CLI结构。用VSCode打开前端目录先执行npm install等待依赖安装完成。这个过程中有几点要留意如果npm安装速度很慢或者卡住把镜像源切换到国内镜像源能极大提速如果中途报权限错误优先排查node_modules目录残留和npm缓存。安装完成后修改vue.config.js里的代理地址确保/api开头的请求都转发到后端服务地址一般是http://localhost:8080然后执行npm run serve启动。前端默认端口通常是8081启动后访问http://localhost:8081页面正常打开就算成功了一半。打开页面后先用演示账号登录然后走一遍完整业务流程确认前后端联通正常。5.4 前后端联调与验证联调最核心的一步是确认浏览器控制台没有报跨域或404错误。如果登录成功并且菜品列表能正常加载说明前后端数据通路已经打通。接着测试一个写操作——提交一条定制订单再去后台数据库确认orders表是否新增了一行数据。这一步通过后整个系统的数据流就闭环了。实际联调时我习惯在浏览器开发者工具的Network面板里看请求状态遇到接口报错第一时间看Response的JSON里返回的message字段大多数业务错误提示都已经写清楚原因。前端的异常提示不要忽略后端接口的报错日志也要同步查看两边对照才说不出错。6. 常见问题与排坑实录6.1 跨域配置的正确姿势前后端分离项目的第一坑就是跨域。即使你在vue.config.js里配置了代理开发环境请求能正常走部署后或某些特殊场景下依然可能遇到CORS拦截所以后端也要同时做一层CORS配置。常规做法是写一个配置类指定允许的来源地址、HTTP方法、请求头以及是否允许携带凭证。这里有个细节很多人会踩配置允许的来源时如果allowCredentials设置为true那么allowedOrigins不能写成*必须写具体的前端地址比如http://localhost:8081否则部分浏览器会直接拒绝请求。后端跨域配置大家可以直接记下来spring: mvc: cors: allowed-origins: http://localhost:8081 allowed-methods: GET,POST,PUT,DELETE,OPTIONS allowed-headers: * allow-credentials: true开发初期如果懒得写配置类直接用CrossOrigin注解也能顶一阵子但正式的完整项目最好全局配置省得每个Controller写注解。6.2 MySQL 8 时区配置的隐形坑MySQL 8刚装好时如果JDBC驱动版本是com.mysql.cj.jdbc.Driver连接URL必须加上时间时区参数比如jdbc:mysql://localhost:3306/private_dish?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai同时MySQL服务端本身也要设置default-time-zone8:00。不然你会遇到一个非常隐蔽的问题前端页面上显示的时间很正常数据库里存的时间也正常但某个接口查出来的时间就是差了8个小时。对订单这种强时间依赖的业务来说查出来时间和真实时间不一致会导致排期和统计全乱。这个问题排查起来非常费劲因为不报错只有数据对不上。所以我还是建议在初始化环境时一次性把数据库连接URL里的时间参数写对。6.3 MyBatis驼峰映射导致查询字段为null数据库字段习惯用下划线比如user_name实体类字段习惯用驼峰比如userName。MyBatis默认不会自动把下划线字段转换成驼峰属性需要手动开启配置。在application.yml里设置mybatis: configuration: map-underscore-to-camel-case: true没开启这个配置会让很多查询结果里userName、realName这类字段全部是null但SQL单独在数据库工具里跑又是正常返回的。最坑的是这种错误不会报异常等到页面上用户名显示空白才慢慢发现排查半天也不一定想到是映射配置的问题。所以强烈建议新项目在搭建骨架时就把这个配置加上。6.4 图片上传后前端访问404这个问题的本质是静态资源映射没配置对。后端收到文件后保存到了某个物理路径但Spring MVC默认没有把对应的URL路径映射到这个物理目录。正确做法是在配置类里注册资源映射器把/upload/**这类请求路径指向实际的存储目录。还有一个容易踩的细节本地IDEA里启动没问题等打包部署成jar后如果用相对路径保存文件jar所在目录和IDE工作目录不一致图片就会出现时好时坏的情况。建议直接用配置项指定绝对路径例如配置upload.dir属性然后代码里统一读取这个配置避免路径混乱。6.5 依赖安装失败与端口占用前端npm install如果失败大多是网络原因。切换镜像源、清楚缓存后重试简单有效。npm install -g cnpm --registryhttps://registry.npmmirror.com cnpm install后端Maven依赖下载慢同样可以换镜像源配置过之后效果很明显。启动时遇到端口占用后端报端口被占用通常是之前遗留的Java进程没退出Windows下可以用netstat命令查端口PID然后结束对应进程前端8082端口冲突就改vue.config.js里的端口配置。这些问题都很琐碎但实际开发阶段几乎天天遇到解决一次就记住了。6.6 问题速查表现象常见原因解决方向接口请求挂在Pending状态跨域或代理配置错误检查vue.config.js代理和后端CORS配置登录接口401token缺失或过期确认前端请求拦截器带token过期后重新登录数据库中文乱码字符集不一致连接URL加useUnicodetruecharacterEncodingutf8列表分页数据不对PageHelper拦截器配置问题检查分页插件版本和配置上传大图失败Spring上传大小限制配置spring.servlet.multipart.max-file-size前端路由刷新404history模式未配置改用hash模式或配置服务端回退7. 二次开发方向与学习建议7.1 四个值得做的扩展功能基础版本跑通之后可以顺着业务需求做几个扩展让项目差异化更明显。第一个加在线沟通。让顾客和厨师在下单前后能交流定制细节。最轻量级的实现就是轮询接口拉取消息记录不上WebSocket也能做出完整功能如果你愿意往深做用WebSocket做实时推送就是加分项。第二个加数据统计面板。管理员端用ECharts展示近一个月的订单量趋势、营业额变化、菜品热度排行、厨师服务质量对比。这类可视化页面做出来效果很直观管理员端的专业感立刻上来了。第三个加地图选地址。把默认的手动输入地址替换成地图API打点选点顾客体验会好很多。地图JavaScript API免费额度够用接入成本不高功能却很亮眼。第四个加模拟支付回调。让下单操作接上支付流水逻辑生成支付流水记录和回调模拟接口支付成功后自动更新订单状态。这个扩展做完后整个订单资金链就完整了后面接真实支付通道也只差一步。7.2 答辩与面试准备的重点如果你拿这个项目去做答辩或面试不要只背项目流程。重点准备三块内容。第一块项目架构。能清楚画出前后端分离的整体请求链路浏览器访问Vue页面Vue通过axios发请求请求经代理到后端Controller再经过Service处理业务、Mapper操作数据库数据返回后前端渲染。这个链路用两分钟讲清楚面试官就知道你是真的跑通过项目而不是只看过教程。第二块核心业务难点。订单状态为什么用状态机而不是布尔值并发预约为什么先条件更新再插入退款为什么保留订单记录而不是物理删除这几个问题回答得好比堆技术名词有用太多。第三块你自己的改动。哪怕只加了一个功能、修复了一个Bug也要能讲明白改动前是什么问题、你做了什么改动、验证结果如何。真实项目的完成度恰好体现在这些细节里而不是背一段流程。我个人做这个系列项目时最大的体悟是很多系统做完并不是因为代码写不出来而是业务逻辑没有理顺就急着撸代码。预约排期一开始我用的是单纯查询再插入并发测试直接翻车订单状态最初用boolean值后来要扩展退款状态时想死的心都有。如果你把这个项目当作毕设或面试作品来打磨把它彻底吃透比草草看完十篇教程都更有价值。
做私房菜定制上门这套系统前后端分离是我第二个版本才落地的方案第一个版本用的还是传统的服务端模板渲染改版时折腾了不少但改完回头看非常值得。SpringBoot Vue MyBatis MySQL这四个词基本是目前中小型Web项目里最常见的组合之一也是面试官和答辩老师最熟悉的一套拿它做项目起码不用担心被问到底层细节时无话可说。这套系统覆盖的角色和业务链路比较完整顾客端、厨师端、平台管理端都做了从菜品定制、选厨师、预约上门时间到下单支付、评价售后是一条完整闭环。这套项目适合谁课程设计、毕业设计、以及想完整跑通前后端分离流程的开发者都适用。如果你刚学完SSM和Vue基础想找一个综合性强一点、真实业务场景明确的项目练手这个也合适——它不是玩具项目订单状态流转、角色权限控制、预约排期冲突这些真实业务点都有跑通一遍之后你对整个Java Web开发的认知会清晰很多。1. 技术选型为什么这套组合最稳1.1 前后端分离不是炫技是效率妥协很多同学纠结要不要做前后端分离觉得多了一层接口调用复杂度更高。我的观点恰恰相反做完整源码项目前后端分离比模板渲染省事得多。模板渲染虽然写代码时少一步API调用但前后端逻辑混在一起前端一改样式后端模板就得跟着动后端一改数据传递前端页面也遭殃。两个人在一个项目里协作几乎是互相添乱。前后端分离之后前端只管Vue页面和调用API后端只管接口和业务逻辑两边可以并行推进。调试阶段更舒服前端可以用Mock数据先跑页面后端用Postman测接口返回互不阻塞。对毕设和课设来说分开还有一个额外的好处——答辩时可以演示的内容变多了分别展示后端接口返回、前端页面渲染、数据库落库情况展示的信息量直接翻倍。技术深度上也好讲跨域处理、JWT鉴权、接口规范这些话题都能展开聊几句比干巴巴一句用了SpringBoot和Vue要扎实得多。1.2 SpringBoot MyBatis常规但可靠SpringBoot选它核心原因是配置量少不需要像SSM时代那样堆一大堆XML配置文件。而且Spring生态的普及度摆在那里不管你把这个项目交给谁接手别人都不会觉得陌生。MyBatis之所以和SpringBoot配合得稳定是因为它的半ORM特性对SQL控制力很强这套系统里涉及不少多表联查和条件统计手写SQL可以精确控制每一行语句的行为调试时也方便直接复制SQL到数据库工具里跑不像JPA那样遇到复杂查询还要折腾规范。MySQL作为数据库免费、轻量、文档丰富Navicat和命令行都能操作部署成本几乎为零。整套系统只需要一个数据库实例和一份SQL脚本就能跑起来不会在环境准备阶段卡住人。这类项目最重要的就是开箱能跑一旦环境上出问题很多新手直接就放弃了。1.3 Vue Element UI生态成熟度优先前端选择Vue是因为它的学习曲线相对平缓组件化和数据响应式的理念对新手门槛不高。这里用的方案是Vue 2 Element UI不是为了守旧而是我实测下来最省心的一套组合。Element UI的表单、日期选择、表格分页、弹窗提示几乎全是现成的写管理后台页面时改属性就能用一天的活能压缩到半天。Vue 3 Element Plus当然也可以跑核心接口调用逻辑不受影响但组件API有差异从Vue 2的项目迁移过去需要动不少模板代码。如果你手里时间紧不要在这个环节上折腾版本升级先把业务链路完整跑通比什么都重要。2. 角色权限与核心业务链路设计2.1 三类角色的权限划分与登录鉴权这套系统把用户划分为三类角色顾客、厨师、管理员。数据库里user表通过role字段区分0是顾客1是厨师2是管理员。用户登录成功之后后端签发JWT令牌令牌里包含用户的id和role后续每次请求后端都通过拦截器校验令牌再结合自定义注解判断该角色是否有权限访问当前接口。顾客能做的事注册登录、浏览菜品和厨师、提交定制需求、选择上门时间、下单支付、确认完成、评价订单。厨师能做的事查看新订单、接受或拒绝、查看定制需求明细、设置个人排期、管理私房菜谱、查看收入记录。管理员能做的事审核厨师入驻申请、管理菜品分类、管理用户状态、查看监控所有订单、处理售后反馈。权限控制虽然实现难度不高但梳理清楚很关键。后端除了登录接口其他接口一律校验token再根据角色决定放行还是拒绝。前端也要配合Vue Router里配置meta字段标记角色路由守卫根据当前用户角色统一拦截。前后端双重控制一方面防止绕过界面直接调用接口另一方面也提升了系统的整体安全性。实际项目里接口权限漏配一个别人就能通过工具直接访问到管理接口这个问题我在早期的版本里踩过。2.2 订单主链路与状态机设计整套系统的核心链路是顾客提交定制需求选择菜品、填写口味偏好、设置上门地址、选时间→ 系统根据厨师排期匹配可接单人选 → 顾客下单 → 厨师端看到新订单 → 厨师接单/拒单 → 按约时间上门服务 → 顾客确认完成 → 顾客评价 → 订单完成。订单状态不能只用布尔值表示状态机必须清晰。我设计的状态是待接单(0) → 已接单(1) → 服务中(2) → 已完成(3) → 已评价(4)另外保留取消状态(-1)和退款状态(5)。状态流转不能随意跳跃比如已完成(3)的订单不能直接变回待接单(0)Service层必须有校验逻辑不能只依赖前端传参数。这一点在答辩时很加分——你讲清楚为什么用状态机而不是简单flag就体现出真实业务思维了。2.3 定制菜品的价格计算逻辑定制菜品的核心不只是让顾客填一个备注框而是可以对菜品进行结构化定制。我单独设计了一张customization表记录基础菜品id、口味偏好辣度/甜度等、食材替换要求、加料选项和备注信息。重点是价格计算不能只是固定菜品的原价否则定制就名存实亡。价格计算采用两步法菜品底价加上配料加价再加口味附加费。举例来说辣子鸡底价58元顾客选加一份鸡腿肉加8元选重辣口味加5元最终是67元。菜品底价存储在dish表配料选项存ingredient_option表管理员在后台维护前端拿到菜品ID后动态渲染配置项后端根据选项组合实时计算价格。这个逻辑一旦跑通整个定制模块的完成度就立起来了比那些只有一个文本框的项目高级太多。3. 核心功能模块的完整实现3.1 菜品分类与菜谱管理菜品分类用category表一层结构就够不搞多级嵌套。分类包括川菜、粤菜、江浙菜、时令菜、甜品汤品等。每个菜谱挂在分类下面菜谱表recipe保存菜品的基础信息名称、图片、底价、简介、口味可选列表用JSON字符串存储解析也方便。菜品图片上传用了后端静态资源映射。SpringBoot配置了upload目录的映射上传的图片保存到本地前端img标签直接就能访问。这个方案简单可靠适合本地部署场景。需要注意一个坑不要把图片存储在target编译目录内部否则重新打包会清空丢失正确做法是配置一个独立的物理路径这个问题在后面排坑实录里再细说。3.2 预约排期与并发冲突处理厨师要维护自己的可接单时间。schedule表里存厨师ID、日期、开始时间、结束时间、是否被占用状态。顾客在下单页面选时间段时前端只展示空闲时段提交订单时后端再做一次兜底校验避免两个用户同时抢同一个时间段。先查询后插入的方式存在并发隐患。实际操作中我做了两层防护第一层状态更新采用条件更新也就是UPDATE schedule SET status1 WHERE id? AND status0通过受影响行数判断是否抢单成功第二层业务上在订单表里为schedule_id加了唯一约束双保险。如果你在答辩时能讲明白这两层并发保护背后的数据一致性问题比写一堆业务代码更能体现水平。3.3 评价、退款与售后链路订单完成后顾客可以评价订单。review表记录评分1-5分、文字内容和上传图片。评分还会反哺到厨师列表页的平均分数让流量聚集到服务质量更好的厨师身上形成正向循环。售后主要针对退款/投诉场景。顾客发起申请后后台管理员审核通过后订单状态改为已退款。系统没接入真实支付退款操作的是模拟余额账户表里加了一个balance字段下单时冻结金额退款时原路退回。实际这个逻辑可以和真实支付非常平滑地对接只需要把模拟余额扣减替换成调用支付平台退款接口即可。类似项目里常见的错误做法是把退款实现成删除订单。订单是核心业务数据删掉会导致对账失败、数据统计残缺、用户行为分析断层。正确做法是保留订单记录通过状态字段标记退款这套设计才能支撑之后任何数据层面的分析。4. 数据库表结构设计与初始化4.1 核心表结构总览整套系统的核心表大概有这些user表用户、category表分类、dish表菜品菜谱、ingredient_option表配料选项、customization表定制记录、schedule表厨师排期、address表上门地址、orders表订单、order_item表订单明细、review表评价、refund表退款申请。表数量控制在10张上下既有足够的业务复杂度又不至于让新手看了头大。字段设计时遵循一个原则能用枚举值表示的不用字符串存长描述比如role和status字段用tinyint存数字在代码里定义常量映射这样查询和统计都高效。时间字段统一用datetime类型谁创建、谁更新、什么时候创建、什么时候更新这类审计信息全部带上排错时特别有用。4.2 关键表字段说明orders表是业务核心重要的字段包括订单号order_no业务编号方便人工查询、顾客ID、厨师ID、定制ID、地址ID、总金额、状态、下单时间、预约时间、完成时间。订单号建议不要直接用自增ID而是在代码里生成带日期的编号比如20250614103200123这样客服或管理员在后台查询订单时直接根据时间定位也好记忆也好都比一堆数字随机串直观得多。schedule表也很关键字段厨师ID、日期、开始时间段、结束时间段、状态。这里时间字段我存的是时间戳或者datetime方便做条件区间查询。如果只存一个字符串排期比较和冲突检测都会很难写。4.3 演示数据的准备与导入技巧数据库建好后需要导入三部分数据表结构、初始账号、演示数据。演示数据这一步极其重要。系统里直接塞满菜品分类、菜品记录、几个厨师账号、几个顾客账号、若干已完成订单打开系统第一眼就能看到完整的效果节省你手动造数据的大量时间。演示账号建议管理员admin/123456顾客user01/123456厨师cook01/123456。注意这些账号存在SQL脚本里的密码不是明文是BCrypt加密后的字符串安全考虑。如果导入后登录不上大概率是密码加密方式或者字符编码出问题重新生成BCrypt密文替换即可。5. 本地开发环境部署教程从零到一5.1 环境准备清单开始之前先把基础环境装好JDK 1.8这个项目的Java版本建议8稳定性最佳Maven 3.6以上MySQL 5.7或8.0Node.js 14以上IDEA或Eclipse后端开发VSCode或WebStorm前端开发有Docker基础的话MySQL数据库用容器跑更方便一条命令就能启动还能免去本机安装和服务的各种烦恼。不过这个项目本身对MySQL版本没有强依赖常规安装也完全OK不必为了炫技引入额外复杂度。5.2 后端工程启动步骤后端项目的启动分四步。第一步用IDEA打开SpringBoot工程等待Maven自动下载依赖这一步比较慢但不要中断你可以顺手浏览下代码结构。第二步修改application.yml里的数据库连接信息把url、username、password改成自己本机的值。第三步确认启动端口没有冲突默认8080你本机如果有其他项目占用了改一下server.port即可。第四步运行启动类看到Started xxxApplication的日志说明后端已经起来了。后端启动后先不要急着去联前端用浏览器或者Postman直接访问一个最简单的接口比如http://localhost:8080/api/health确认接口返回正常再往下走。5.3 前端工程启动步骤前端项目是标准Vue CLI结构。用VSCode打开前端目录先执行npm install等待依赖安装完成。这个过程中有几点要留意如果npm安装速度很慢或者卡住把镜像源切换到国内镜像源能极大提速如果中途报权限错误优先排查node_modules目录残留和npm缓存。安装完成后修改vue.config.js里的代理地址确保/api开头的请求都转发到后端服务地址一般是http://localhost:8080然后执行npm run serve启动。前端默认端口通常是8081启动后访问http://localhost:8081页面正常打开就算成功了一半。打开页面后先用演示账号登录然后走一遍完整业务流程确认前后端联通正常。5.4 前后端联调与验证联调最核心的一步是确认浏览器控制台没有报跨域或404错误。如果登录成功并且菜品列表能正常加载说明前后端数据通路已经打通。接着测试一个写操作——提交一条定制订单再去后台数据库确认orders表是否新增了一行数据。这一步通过后整个系统的数据流就闭环了。实际联调时我习惯在浏览器开发者工具的Network面板里看请求状态遇到接口报错第一时间看Response的JSON里返回的message字段大多数业务错误提示都已经写清楚原因。前端的异常提示不要忽略后端接口的报错日志也要同步查看两边对照才说不出错。6. 常见问题与排坑实录6.1 跨域配置的正确姿势前后端分离项目的第一坑就是跨域。即使你在vue.config.js里配置了代理开发环境请求能正常走部署后或某些特殊场景下依然可能遇到CORS拦截所以后端也要同时做一层CORS配置。常规做法是写一个配置类指定允许的来源地址、HTTP方法、请求头以及是否允许携带凭证。这里有个细节很多人会踩配置允许的来源时如果allowCredentials设置为true那么allowedOrigins不能写成*必须写具体的前端地址比如http://localhost:8081否则部分浏览器会直接拒绝请求。后端跨域配置大家可以直接记下来spring: mvc: cors: allowed-origins: http://localhost:8081 allowed-methods: GET,POST,PUT,DELETE,OPTIONS allowed-headers: * allow-credentials: true开发初期如果懒得写配置类直接用CrossOrigin注解也能顶一阵子但正式的完整项目最好全局配置省得每个Controller写注解。6.2 MySQL 8 时区配置的隐形坑MySQL 8刚装好时如果JDBC驱动版本是com.mysql.cj.jdbc.Driver连接URL必须加上时间时区参数比如jdbc:mysql://localhost:3306/private_dish?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai同时MySQL服务端本身也要设置default-time-zone8:00。不然你会遇到一个非常隐蔽的问题前端页面上显示的时间很正常数据库里存的时间也正常但某个接口查出来的时间就是差了8个小时。对订单这种强时间依赖的业务来说查出来时间和真实时间不一致会导致排期和统计全乱。这个问题排查起来非常费劲因为不报错只有数据对不上。所以我还是建议在初始化环境时一次性把数据库连接URL里的时间参数写对。6.3 MyBatis驼峰映射导致查询字段为null数据库字段习惯用下划线比如user_name实体类字段习惯用驼峰比如userName。MyBatis默认不会自动把下划线字段转换成驼峰属性需要手动开启配置。在application.yml里设置mybatis: configuration: map-underscore-to-camel-case: true没开启这个配置会让很多查询结果里userName、realName这类字段全部是null但SQL单独在数据库工具里跑又是正常返回的。最坑的是这种错误不会报异常等到页面上用户名显示空白才慢慢发现排查半天也不一定想到是映射配置的问题。所以强烈建议新项目在搭建骨架时就把这个配置加上。6.4 图片上传后前端访问404这个问题的本质是静态资源映射没配置对。后端收到文件后保存到了某个物理路径但Spring MVC默认没有把对应的URL路径映射到这个物理目录。正确做法是在配置类里注册资源映射器把/upload/**这类请求路径指向实际的存储目录。还有一个容易踩的细节本地IDEA里启动没问题等打包部署成jar后如果用相对路径保存文件jar所在目录和IDE工作目录不一致图片就会出现时好时坏的情况。建议直接用配置项指定绝对路径例如配置upload.dir属性然后代码里统一读取这个配置避免路径混乱。6.5 依赖安装失败与端口占用前端npm install如果失败大多是网络原因。切换镜像源、清楚缓存后重试简单有效。npm install -g cnpm --registryhttps://registry.npmmirror.com cnpm install后端Maven依赖下载慢同样可以换镜像源配置过之后效果很明显。启动时遇到端口占用后端报端口被占用通常是之前遗留的Java进程没退出Windows下可以用netstat命令查端口PID然后结束对应进程前端8082端口冲突就改vue.config.js里的端口配置。这些问题都很琐碎但实际开发阶段几乎天天遇到解决一次就记住了。6.6 问题速查表现象常见原因解决方向接口请求挂在Pending状态跨域或代理配置错误检查vue.config.js代理和后端CORS配置登录接口401token缺失或过期确认前端请求拦截器带token过期后重新登录数据库中文乱码字符集不一致连接URL加useUnicodetruecharacterEncodingutf8列表分页数据不对PageHelper拦截器配置问题检查分页插件版本和配置上传大图失败Spring上传大小限制配置spring.servlet.multipart.max-file-size前端路由刷新404history模式未配置改用hash模式或配置服务端回退7. 二次开发方向与学习建议7.1 四个值得做的扩展功能基础版本跑通之后可以顺着业务需求做几个扩展让项目差异化更明显。第一个加在线沟通。让顾客和厨师在下单前后能交流定制细节。最轻量级的实现就是轮询接口拉取消息记录不上WebSocket也能做出完整功能如果你愿意往深做用WebSocket做实时推送就是加分项。第二个加数据统计面板。管理员端用ECharts展示近一个月的订单量趋势、营业额变化、菜品热度排行、厨师服务质量对比。这类可视化页面做出来效果很直观管理员端的专业感立刻上来了。第三个加地图选地址。把默认的手动输入地址替换成地图API打点选点顾客体验会好很多。地图JavaScript API免费额度够用接入成本不高功能却很亮眼。第四个加模拟支付回调。让下单操作接上支付流水逻辑生成支付流水记录和回调模拟接口支付成功后自动更新订单状态。这个扩展做完后整个订单资金链就完整了后面接真实支付通道也只差一步。7.2 答辩与面试准备的重点如果你拿这个项目去做答辩或面试不要只背项目流程。重点准备三块内容。第一块项目架构。能清楚画出前后端分离的整体请求链路浏览器访问Vue页面Vue通过axios发请求请求经代理到后端Controller再经过Service处理业务、Mapper操作数据库数据返回后前端渲染。这个链路用两分钟讲清楚面试官就知道你是真的跑通过项目而不是只看过教程。第二块核心业务难点。订单状态为什么用状态机而不是布尔值并发预约为什么先条件更新再插入退款为什么保留订单记录而不是物理删除这几个问题回答得好比堆技术名词有用太多。第三块你自己的改动。哪怕只加了一个功能、修复了一个Bug也要能讲明白改动前是什么问题、你做了什么改动、验证结果如何。真实项目的完成度恰好体现在这些细节里而不是背一段流程。我个人做这个系列项目时最大的体悟是很多系统做完并不是因为代码写不出来而是业务逻辑没有理顺就急着撸代码。预约排期一开始我用的是单纯查询再插入并发测试直接翻车订单状态最初用boolean值后来要扩展退款状态时想死的心都有。如果你把这个项目当作毕设或面试作品来打磨把它彻底吃透比草草看完十篇教程都更有价值。
