企业官网建设流程全解析

做这套私房菜上门定制系统的时候，我最大的感觉不是"写代码好累"，而是"把业务理清楚比写代码难十倍"。那阵子市面上大多数同类项目都是把私房菜做成"高端外卖"，用户下单、商家配送，本质上和美团没什么区别。但真正的私房菜上门定制，核心不是"送餐"，而是"定制"和"上门"——用户约的是一顿饭，更是一个个性化的用餐体验。

我最后用一个SpringBoot项目把这些需求全部落地了，顺便把源码、论文、部署文档、讲解视频一套交付物都整理齐。整个过程踩了不少坑，尤其是订单状态流转、厨师排期冲突和定制项的数据结构这三块，几乎每个都能单独写一篇文章。这篇文章就把我整个设计和实现过程完整复盘一遍，从需求拆解到技术选型，从核心模块到部署上线，该给的配置、该贴的代码、该避的坑，全都整理出来。不管你是拿这系统当毕设模板，还是想搞清楚SpringBoot项目从零到部署的完整链路，应该都能少走很多弯路。

1. 私房菜上门定制，到底在定制什么

1.1 我最初把需求想窄了

刚开始拿到这个题目，我的第一反应是：私房菜上门定制 = 预约厨师 + 上门做菜。听起来跟团购的"大厨到家"很像，用户选套餐、付钱、厨师上门。但真正去做需求调研的时候发现完全不是一回事。

用户在平台上下单，但他的需求可能是"家里老人过生日，想请一位擅长家常菜、口味清淡的厨师来做一顿饭"；也可能是"朋友聚会，想要川菜，但家里有小孩不能太辣"。这些需求里最关键的并不是"订哪个厨师"，而是"这顿饭怎么按我的要求做"。换句话说，定制的是"一顿饭的方案"，而不仅仅是"一个厨师的时间"。

这样一来，系统的核心业务就变成了三块：

• 用户端：浏览厨师、浏览菜品、提交定制需求、管理预约时间
• 厨师端：维护自己的菜品和擅长菜系、接单、管理日程、标记食材偏好
• 管理端：审核厨师资质、审核菜品上架、处理订单纠纷、查看平台数据

1.2 三个角色的核心痛点与功能蓝图

角色的痛点决定了功能的边界。我把它们梳理成了一张表，后面所有模块设计都是按照这张表来的。

所以说，这个系统的核心不是"菜谱管理"，也不是简单的"预约表"，而是"用户-厨师-订单"这三者之间的信息流转。订单表的设计直接决定了系统的上限。

2. SpringBoot项目骨架搭建与技术选型

2.1 为什么选SpringBoot而不是SSH或SSM

不是SpringBoot有多高大上，是选它真的能让开发效率高不少。以前用SSM，光是配置文件就得写一大堆：spring-mvc.xml、spring-dao.xml、mybatis-config.xml，还要手动配置事务管理器、扫描包、视图解析器。SpringBoot把这些全部收编了，spring-boot-starter-web一个依赖搞定web层，spring-boot-starter-data-redis搞定缓存，自动装配机制基本把常规配置都处理掉了。

对毕设或中小型实战项目来说，最大的好处其实是"上手快、排错简单"。遇到问题，报错信息直接指向业务代码而不是配置文件，排查成本低一大截。

2.2 技术栈清单与选择理由

这里的选型逻辑是：稳定第一，文档齐全第二，学习成本第三。

提示：如果是在校生做毕设，不建议直接上SpringCloud微服务那一套。单机版SpringBoot项目反而更能体现你对业务和基础框架的理解深度。面试官或答辩老师更想看到的是你把订单流程、并发控制这些基础问题处理得多干净。

2.3 项目包结构设计与分层逻辑

项目的包结构遵循了经典的四层架构，不过我在具体命名上做了点调整，让代码的职责更清楚：

com.dish.custom ├── controller │ ├── user # 用户端接口 │ ├── chef # 厨师端接口 │ └── admin # 管理端接口 ├── service │ ├── order # 订单核心服务 │ ├── customize # 定制需求服务 │ ├── schedule # 厨师排期服务 │ └── user # 用户与认证服务 ├── mapper ├── entity ├── dto # 前后端交互的视图对象 ├── vo # 对外显示的视图对象 ├── common # 全局异常、统一返回、常量 ├── config # Redis、MyBatis-Plus、跨域等配置 └── utils # JWT、日期工具、自定义注解

为什么controller和service要按业务域分包而不是按类型分？我一开始也是所有controller堆在一起，后来订单模块和排期模块互相依赖，改一个方法能牵连三四个文件。按业务域分之后，改动范围一眼就能定位，答辩的时候讲到"模块化设计"也更有底气。

3. 订单模块：这个系统的心脏

3.1 订单状态机的设计

订单系统最怕“状态满天飞”。我见过有同学用整数存状态，0表示待支付、1表示已支付、2表示已接单，代码里到处写if (status == 1)，后期改需求直接崩溃。我采用的方式是用枚举把状态流转集中管理起来。

待支付(0) -> 待接单(1) -> 已接单(2) -> 烹饪中(3) -> 配送中(4) -> 已完成(5) -> 已取消(6) -> 已退款(7)

关键点在转状态的校验逻辑。比如用户取消订单，只有待支付和待接单两个状态能取消；厨师接单，只有待接单状态能接。我在service层写了一个状态校验方法：

public void changeOrderStatus(Long orderId, OrderStatus from, OrderStatus to) { Order order = orderMapper.selectById(orderId); if (!from.equals(order.getStatus())) { throw new CustomException("订单当前状态不允许该操作"); } order.setStatus(to); orderMapper.updateById(order); }

这样每次调用转状态方法时，必须传入期望的"前状态"，如果订单已经不是那个状态，直接抛出异常。配合数据库里的乐观锁版本号字段，能最大程度避免并发情况下状态被覆盖。

3.2 厨师排期与时间冲突校验

这个模块是我开发过程中想得最久的部分。厨师可不是机器人，他同一时间段只能接一单。如果两单时间重叠，就可能会出现"一个厨师同一时间出现在两个家庭厨房里"的闹剧。

光靠前端校验肯定不行，必须后端校验。我的方案是：厨师在接单时，根据订单的预约日期 + 时间段去查排期表，如果该时段已经被占用就拒绝接单。

数据库表设计上，我用了一张chef_schedule表：

校验的核心逻辑：

// 加锁的key：schedule:{chefId}:{scheduleDate}:{timeSlot} boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", 3, TimeUnit.SECONDS); if (!locked) { throw new CustomException("该时间段正在被其他用户预约，请稍后重试"); } try { int count = scheduleMapper.checkReserved(chefId, scheduleDate, timeSlot); if (count > 0) { throw new CustomException("该时间段已被预约，请更换时间"); } scheduleMapper.updateReserved(chefId, scheduleDate, timeSlot); // 后续创建订单的逻辑... } finally { redisTemplate.delete(lockKey); }

这一段用了Redis的分布式锁思路——把"检查时间段是否空闲"和"锁定时间段"两个操作变成原子操作，防止两个用户同时抢同一个时间段。虽然项目规模不大，但这种并发处理意识在答辩时很加分。

3.3 定制需求的数据结构

定制需求是用户下单的重点。用户在页面上可能选择的定制项包括：

• 菜系偏好：川菜、粤菜、湘菜、家常菜
• 口味标签：微辣、中辣、清淡、少油、少盐
• 忌口信息：不吃香菜、海鲜过敏、清真
• 特殊要求：老人过生日、儿童餐、低糖低脂

最开始我打算做成一张定制详情表，每个字段一列，比如taste_type、allergy_info、is_no_onion。后来发现用户的需求自由度太高了，固定字段根本不够用。

最后的设计是"固定字段 + JSON扩展"的组合方式。主表固定存几项高频需求，剩下自定义内容存到extra_json字段里，用MySQL的JSON类型存储。读取的时候用FastJson或Jackson解析就行，既照顾了结构化查询的需求，也保留了个性化扩展的空间。

CREATE TABLE order_customize ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL COMMENT '订单ID', cuisine_type VARCHAR(20) COMMENT '菜系偏好', taste_tag VARCHAR(50) COMMENT '口味标签', taboo_info VARCHAR(200) COMMENT '忌口信息', expected_date DATE COMMENT '期望上门日期', time_slot VARCHAR(20) COMMENT '期望时间段', extra_json JSON COMMENT '扩展定制需求' );

注意：如果你的数据量很小，JSON字段随意用没关系。但如果你是在做商业项目，建议把高频查询的字段单独拎出来做索引列，JSON只用来存低频扩展属性。这是一个从"能用"到"好用"的细节。

4. 菜品定制与推荐模块的实现思路

4.1 定制选项怎么拆维度

推荐模块一开始被我想复杂了。我甚至想过引入协同过滤算法，后来发现数据量就几百条，协同过滤根本转不起来。最终采用的是"基于标签的倒排匹配"——每个厨师维护自己的"擅长标签集"，每个用户提交需求时形成"需求标签集"，两边做匹配打分。

标签体系分四个维度：

4.2 标签匹配与相似厨师推荐

匹配逻辑很简单。用户定制需求提交后，系统提取出标签集，然后遍历厨师表中的标签，计算重合度。重合度大于等于一定阈值，就返回给前端作为推荐结果。

public List<ChefVO> recommendChefs(CustomizeRequest req) { List<String> userTags = req.getTags(); List<Chef> allChefs = chefMapper.selectList(null); return allChefs.stream() .filter(chef -> chef.getAuditStatus() == 1) // 只推荐审核通过的厨师 .map(chef -> { List<String> chefTags = Arrays.asList(chef.getTags().split(",")); long overlap = chefTags.stream().filter(userTags::contains).count(); ChefVO vo = new ChefVO(); vo.setChefId(chef.getId()); vo.setMatchScore(overlap * 10); return vo; }) .sorted(Comparator.comparing(ChefVO::getMatchScore).reversed()) .limit(3) .collect(Collectors.toList()); }

这套逻辑不高端，但胜在简单直接、容易说明白。答辩的时候，与其讲一个调参复杂到连自己都讲不清楚的深度学习模型，不如把一套规则透明、可解释性强的匹配逻辑讲透。

4.3 冷启动问题怎么缓解

冷启动在传统推荐系统里是个老大难，但在私房菜场景下反而好解决：因为用户在下单前本来就会主动提供很多需求信息，这些信息就是最天然的"特征"。

我的做法是：用户注册时做了个"口味偏好"引导页，选几个标签就能生成初始标签集。这样即使用户第一次下单，推荐模块也有数据可用。除此以外，平台新用户会给一次"今日精选"推荐位——管理员手动配置几个高质量厨师和招牌菜，相当于人工兜底。

5. 交付一套能过审的毕设：源码、论文、部署文档、讲解一条线

5.1 源码目录如何组织才不乱

源码不只是代码，更是一套交付物的总称。我的项目目录是这样的：

springboot-private-cuisine/ ├── backend/ # SpringBoot后端 │ ├── src/main/java │ ├── src/main/resources │ │ ├── mapper/ │ │ └── application.yml │ └── pom.xml ├── frontend/ # Vue前端 │ ├── src/ │ │ ├── api/ │ │ ├── views/ │ │ └── router/ │ └── package.json ├── sql/ # 数据库脚本 │ ├── schema.sql │ └── data.sql ├── docs/ │ ├── 部署文档.md │ ├── 需求文档.md │ └── 设计文档.md └── README.md

README是很多人会忽略但特别重要的东西。我建议至少包含：项目简介、技术栈、启动步骤、默认账号。启动步骤写详细些，JDK版本、MySQL配置、Redis启动、前端代理配置，一样都不能少。相信我，部署文档写得好的项目，给老师的印象分会直接上一个台阶。

5.2 论文写作技巧：图文并茂、五章标准结构

如果这个项目是毕设，论文基本可以按这个结构来：

• 第一章 绪论：背景、意义、国内外现状
• 第二章 相关技术介绍：SpringBoot、MyBatis-Plus、Vue、Redis
• 第三章 系统分析：用例图、业务流程、可行性分析
• 第四章 系统设计：架构图、功能模块划分、数据库ER图和表结构
• 第五章 系统实现：每个模块的核心代码和截图

千万别忽略截图。每个核心功能模块最好配1-2张操作界面截图，加上对应的核心代码片段。老师大概率没有时间把你几千行代码全读一遍，看图+看关键代码是最高效的评审方式。

5.3 部署文档里最容易漏的东西

我阅过不少毕设项目的部署文档，最常翻车的几个点：

• 只说"导入项目"，没说用什么版本JDK。JDK 8、11、17在某些配置上差别很大，SpringBoot 2.7配合JDK 17没问题，但如果你用了老的javax.*包就可能有问题。
• 数据库字符集没说明。MySQL默认字符集不是utf8mb4，插入表情符号直接报错。
• 忽略了Redis的启动。很多初学者以为装了Redis服务就会自己启动，实际上Windows下要手动启动redis-server.exe，Linux下systemctl start redis前面可能还要改配置文件。
• 前端接口代理忘了配。Vue开发模式连后端接口需要配vue.config.js里的devServer.proxy，忘了配就是一片白屏。

6. 部署过程中我踩过的那些坑

6.1 SpringBoot版本和JDK版本不匹配

我的本机JDK版本是17，一开始图省事选了SpringBoot 3.0版本，结果一堆javax包找不到。因为SpringBoot 3.x把javax.servlet换成了jakarta.servlet，很多旧代码的import javax.servlet.http.HttpServletRequest全部报红。后来果断降到2.7.x，问题迎刃而解。

所以强烈建议：做毕设或者中小型项目，用SpringBoot 2.7.x + JDK 8或JDK 11。不是因为3.x不好，而是生态里大量资料和代码还是基于2.x的，出问题了网上好搜，不会孤立无援。

6.2 MySQL8时区与SSL连接问题

我本地MySQL是8.0，连接字符串一开始不加参数直接报错The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。这个坑几乎是每个MySQL8初学者的必经之路。

正确的JDBC连接串应该是：

spring: datasource: url: jdbc:mysql://localhost:3306/private_cuisine?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

另外记得在MySQL侧执行SET time_zone = '+8:00';，或者用SHOW VARIABLES LIKE 'time_zone';确认一下。不然订单表的create_time会和本地时间差8个小时，排查起来特别迷惑。

6.3 打包后静态资源404和端口占用

如果用前后端分离，SpringBoot后端打包后用java -jar启动，默认端口是8080。但如果本机装了其他服务占用了8080，启动会直接失败。排查方式：

netstat -ano | findstr :8080 # Windows lsof -i:8080 # Linux/Mac

找到占用进程后要么换端口，在application.yml里改server.port；要么杀掉进程。这是一个小问题，但在答辩现场当场翻车的情况不少见——大家上台之前一定要先确认端口没被占。

6.4 本地跑通和服务器部署是两码事

本地能跑通不算完，部署到云服务器才是完整交付。我在CentOS服务器上部署时遇到了一个坑：后端配置了CORS跨域，前端服务器地址和接口地址不同，请求通了但带不了cookie。最后把前端和后端用Nginx做了反代，同一个域名前缀转发到不同端口，问题解决了。

Nginx配置片段：

server { listen 80; server_name your.domain.com; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } }

这样用户只访问一个域名，/api/开头的请求自动转给SpringBoot，其余请求全部走Vue的静态文件，Cookie和JWT都不会遇到跨域问题。

7. 绕不开的源码理解问题

7.1 为什么建议把SpringBoot自动装配拆一遍

很多同学担心答辩时被问源码，尤其是"SpringBoot自动装配原理"这种高频问题。我的建议是：不用背别人的总结，自己找到关键类spring.factories和@EnableAutoConfiguration看一眼，再用实际代码验证一遍。

你只需要搞懂三件事：

• SpringBoot启动时，@SpringBootApplication里面有一个@EnableAutoConfiguration
• @EnableAutoConfiguration通过AutoConfigurationImportSelector去读取META-INF/spring.factories里的配置类
• 这些配置类上基本都有@ConditionalOnClass、@ConditionalOnMissingBean等条件注解，只有当类路径存在对应依赖时才自动装配

把一个简单例子讲清楚，比如为什么引入了spring-boot-starter-web就能自动配置Tomcat和DispatcherServlet。这个思路比背通篇源码有用得多。

7.2 反编译工具到底有没有用

网上经常看到"怎么把SpringBoot打包的jar反编译成项目"这种问题。确实有工具能做到，比如jd-gui可以看class文件的源码，idea插件java-decompiler也可以。但这在我们这个场景下更多是"应急手段"，不是常规开发方式。真需要维护老项目却没源码时，反编译能救命；但如果是为了"省事不去写源码"，那不建议走这条歪路。

我自己在整理项目时习惯每写完一个模块就立刻提交代码到Git仓库，推送到远程。这样即使后来改坏了也能回滚，这个习惯后来帮我省了不少时间。

8. 一些自己的体会

做完这个私房菜上门定制系统，我的感受是：技术上真正难的不是某个知识点，而是把业务规则梳理成可执行的状态流转和数据结构。

比如订单状态机的设计，看上去就是几个状态的枚举，但考虑"哪些状态允许取消、哪些允许退款、什么时候触发通知"，这些才是系统能不能真正落地的关键。再比如Redis锁的应用，看起来就是一两行代码，但锁的粒度、过期时间、释放方式，任何一点没处理好都会在并发场景下出问题。

如果你也准备做类似的SpringBoot项目，我建议不要急着写代码。先用一个星期做需求梳理和数据表设计，把每个角色的行为路径画出来，把每个状态变化的触发条件写清楚。设计阶段多花点时间，开发阶段的效率会快很多。

最后分享一个小技巧：给用户的定制需求表单，尽量做成向导式，一页一个问题，而不是全都堆在一个长表单里。用户填写意愿高很多，后台拿到的数据也干净很多。这个交互细节不会体现在技术文档里，但实际使用体验差距很大。