企业官网建设流程全解析

做计算机毕业设计，最怕的不是功能少，而是功能写完了自己都讲不清。很多同学上来就选“商城系统”“图书管理系统”，论文写得像说明书，答辩时被老师一问业务流程就卡壳。私厨服务菜品定制平台这个题目不一样，它有一条天然清晰的业务主线：用户找厨师、厨师报菜品、用户提定制需求、双方确认订单、完成交易并评价。整条链路自带角色区分、状态流转、数据关联，用来学习 Spring Boot 做 Web 项目，再合适不过。这篇文章我会顺着项目从选型、设计、编码到部署的完整过程，把该注意的坑和能加分的细节一次性讲清楚。

1. 项目背景与整体设计思路

1.1 私厨服务行业的痛点与平台定位

我在带毕业设计的时候，一直强调一个问题：选题目先想清楚“解决谁的什么痛点”。私厨服务里的“私厨”，指的不是普通餐馆，而是个人厨师、家宴厨师或小型餐饮工作室。这类群体有手艺，但缺乏一款低成本、轻量的小工具来管理菜品和接单；用户侧同样有痛点，想找一位能按自己口味做菜的厨师，靠朋友圈打听效率太低。这个平台的价值，就是提供一套完整的在线撮合和定制下单工具。

从功能角度看，平台把“找厨师—看菜品—定制需求—下单—评价”这条链路打通。它解决的不是“做菜”的问题，而是“信息匹配和流程管理”的问题。对毕业设计来说，这个定位特别舒服：不涉及真实支付，不涉及物流跟踪，但又有足够复杂的业务逻辑可以写进论文。

我建议把平台定义成 B2C 轻量撮合平台，核心模块五块：用户中心、厨师入驻、菜品管理、定制下单、订单与评价。以这些为主线，把用户端和厨师端分开展示，前端页面清晰，后端接口职责也清楚。以后想扩展营销活动、会员积分、营养计算，都是在这些模块上长出来的，不会推翻已有设计。

1.2 用户角色与核心功能拆分

系统采用三种角色：普通用户、厨师用户、系统管理员。三者的页面差异很大，但账号体系建议共用一张 user 表，用 role 字段区分角色，而不是拆成三张用户表，否则登录、注册、修改个人信息全部要写三遍，答辩时也会有隐患——查用户信息要连表查三四张表，复杂度完全没必要。

普通用户：浏览私厨和菜品、发布定制需求、提交订单、模拟支付、评价订单。厨师用户：入驻申请、维护个人资料与菜品、查看定制需求、接单或拒绝、更新订单状态。管理员：审核厨师入驻、管理菜品分类、处理用户举报、查看统计数据。

接口设计也有讲究。像登录、注册、公开的厨师列表和菜品列表，不需要鉴权；涉及用户订单、厨师接单、后台管理的接口，一定要加 Token 校验。前后端接口路径建议统一前缀，比如用户端/api/user/**、厨师端/api/chef/**、管理端/api/admin/**，答辩时可以直接说“我按角色对接口做了纵向划分”。

1.3 为什么选 Spring Boot 作为核心框架

这句话在答辩时大概率会被问到，自己必须先想清楚。Spring Boot 对毕设项目最大的价值是自动配置（auto-configuration）和起步依赖（starter）。

没有 Spring Boot 的年代，整合 Spring MVC、MyBatis、数据源要写大量的 XML 配置、组件扫描和代理配置，很多同学光搭环境就要耗掉一两周。Spring Boot 的 starter 机制把常用依赖打包，比如 spring-boot-starter-web 自带内置 Tomcat、Spring MVC、Jackson，引入一个依赖就能启动 Web 项目。自动配置会根据 classpath 中的类动态装配 Bean，比如 classpath 里有 MyBatis 相关 jar 时，它就自动读取数据源配置并创建 SqlSessionFactory。

更关键的是，Spring Boot 还承担了内嵌容器、健康检查、外部化配置这些“运维侧”的工作。你可以把数据库账号密码放在 application.yml，也可以放到环境变量里，部署时不用重新编译。这些点写进论文的“技术选型”部分，比干巴巴列功能清单有力得多。

但有一点要提醒：Spring Boot 再省事，你也要自己过一遍依赖引入、配置启动这几个动作。只会在 IDEA 里点击下一步，答辩时老师问“系统启动时发生了什么”，你会很难受。后面第 4 节我会给出完整搭建步骤。

2. 技术选型与架构方案

2.1 后端技术栈清单

后端技术栈先说结论：

• Spring Boot 2.7.x，打底版本，稳定优先
• MyBatis-Plus 3.5.x，简化单表 CRUD，配套代码生成器
• MySQL 5.7 或 8.0，成熟可靠，排错资料多
• Redis 5.0+，缓存验证码和热点菜品数据
• JWT，无状态登录认证，适合前后端分离
• Minio，菜品图片对象存储，展示层和解耦效果好
• Maven 3.6+，项目构建管理

注意我没有推荐 Spring Boot 3.x。很多同学看到新版本教程就跃跃欲试，结果碰到“springboot版本太高”引发的兼容性问题：某个 starter 还没有适配、JDK 版本不对、自动配置行为变化。毕业设计求稳是第一原则，Spring Boot 2.7.x 是目前生态最成熟的一条线，网上资料多，报错也好搜，完全够用。

JDK 建议用 8 或 11。如果你的电脑只有 JDK 17，可以装一个 11，在 IDEA 的 Project Structure 里切换 SDK，保持代码编译版本一致。我见过有人用 JDK 17 跑 Spring Boot 2.6，启动报“Unsupported class file major version”，其实换成 11 就没问题了。

2.2 前端方案：Thymeleaf 与 Vue 的取舍

前端规划上，其实有两条路线。第一条是传统服务端渲染，用 Thymeleaf，页面放在 templates 目录下，后端一套搞定，适合精力有限、不想折腾前后端分离的同学。第二条是 Vue 前后端分离，开发时前端用 vite 或 webpack 启动，后端只提供 JSON 接口，最后把前端打包放进 Spring Boot 的 static 目录，实现单项目部署。

我带过的毕设项目，相当比例选了 Vue 2 + Element UI 或 Vue 3 + Element Plus。原因是这套组合“看起来专业”，而且接口返回统一 JSON 后，前端逻辑非常直观。但对应代价是要处理跨域、接口鉴权、打包部署三个额外的技术点，这些我都整理在第 5 节。

如果你对前端很陌生，就不要强行上 Vue。选 Thymeleaf 其实更容易拿“页面完整”这个基础分，把省下来的时间用于优化后端业务逻辑。无论选哪一条，核心页面都要覆盖：登录注册页、菜品列表页、菜品详情页、定制需求表单页、订单列表页、厨师管理页。

2.3 数据库选型与核心表设计

数据库选 MySQL，不需要花哨的理由。MySQL 成熟、资料多、出问题好排查，导师也熟悉。如果学校要求国产数据库，可以换金仓，但需要调整 driver-class、方言配置，而且排错经验少，不建议第一次配数据源时折腾这些。

我建议核心表保持在 10 张左右。太多表会加重开发负担，太少表则体现不出关联设计。核心表如下：user、chef、dish、dish_category、customize_request、orders、order_detail、comment、favorite。

表设计有一条黄金原则：一个表只放它自己需要管的字段，关联关系通过逻辑外键解决，比如 order_detail 表里存 dish_id 和 dish_name，但业务上要和 dish 表保持引用关系。物理外键少建或者不建，毕业设计里反而更容易解释扩展性：系统发展时要加字段、做分库，物理外键往往成为瓶颈。

3. 核心功能模块设计与实现

3.1 用户登录与 JWT 鉴权

登录是整个系统的入口，我建议用 JWT 做无状态认证。为什么不用传统 Session？因为前后端分离部署之后，Session 要解决跨域携带 Cookie、集群共享会话等问题，而 JWT 把用户身份直接编码在 Token 里，后端拿到请求头里的 Token 解析即可。毕业设计答辩时，这也是一个很能聊的技术点。

具体流程分四步：

1. 用户提交用户名密码，后端用 BCrypt 校验密码。
2. 校验通过后，把 userId 和 role 放入 JWT 的 claims，生成 Token 返回。
3. 前端保存 Token，在 axios 拦截器里统一添加 Authorization 头。
4. 后端自定义拦截器解析 Token，解析失败返回 401，并设置跨域响应头。

JWT 相关的代码不多：一个 TokenService 负责生成和解析，一个 JwtInterceptor 负责拦截请求，再把拦截器注册到 WebMvcConfigurer 中。代码量不大，但能把“认证与授权”这条线讲透。

3.2 厨师入驻与菜品管理

厨师入驻流程两步：提交申请，管理员审核。chef 表里用 status 字段标记 0 待审核、1 通过、2 驳回，审核通过后厨师端页面才可见。这个“状态字段”思路几乎贯穿整个平台，所有多步业务都可以用状态字段推进，代码里多写几个 ifelse 也不乱。

菜品管理是厨师端的主战场，核心是 CRUD 加图片上传。菜品表建议字段：chef_id、category_id、name、description、base_price、image、support_custom（是否支持定制）、sales_count、status（上架/下架）。要注意，菜品价格用 decimal 类型，不用 float，float 算钱会得到 19.99999，答辩时被评审老师抓住这个细节就很尴尬。

图片上传有两种方案：第一种是本地文件存储，配置 upload-path，再通过静态资源映射暴露/uploads/**；第二种是接 Minio，对象存储服务，把图片放到 bucket 里统一管理。Minio 的整合其实不难：写一个配置类，注入 endpoint、accessKey、secretKey，然后调用 putObject 上传。答辩时就可以说“我实现了文件资源的对象存储管理”，加分。

3.3 菜品定制流程与订单状态机

定制流程是这个项目的灵魂，我讲一个简单可靠的方案。

用户发起定制时，选择厨师、选择一道底菜、填写口味标签和备注、填写期望时间和期望价格，系统生成一条 customize_request 记录，状态为“待接单”。厨师查看需求后选择接受或拒绝。接受后自动生成 orders 订单，订单状态从“待确认”开始流转：待确认 → 制作中 → 配送中 → 已完成 → 已评价。

为什么一定要拆 customize_request 和订单两个实体？因为定制需求可能被厨师拒绝，需求存在不等于订单成交。业务链路是“先询价、再下单”，这样既符合私厨人力服务的真实场景，也让你在设计表结构时多一层层次感，答辩时有东西聊。

订单号生成也值得写一笔。给用户看的订单号用时间戳加随机数拼接，比如yyyyMMddHHmmss + 4 位随机数，数据库自增主键只作内部使用。直接拿自增 id 当订单号展示给用户，大多数产品都会出问题。

3.4 个性化定制的业务细节

个性化定制如果只做一个“备注框”，系统观感太单薄。建议加“口味标签”选择，比如咸淡偏好、忌口（不要香菜/不要辣椒）、场景（家宴/健身餐/低卡）、辣度等级。这些标签在数据库里用逗号分隔存储，展示时 split 出来即可，不需要单独建关联表，因为定制场景的标签数量有限。

菜品表加 support_custom 字段，标识这道菜是否支持定制。前端根据这个字段决定展示“去定制”还是“直接下单”，交互逻辑清晰。customize_request 表里加 expect_time 和 expect_price，用户写明期望用餐时间和可接受预算，厨师接单时才有依据。

把定制详情做成一条“卡片”，前端展示厨师信息、底菜图片、标签列表、用户备注，命令行接口只返回一条 JSON 数据。这些细节单独看都不复杂，但组合在一起，就让整个平台比“菜谱展示系统”高出一个层级：你不仅在做信息展示，还在做“按需服务”的撮合。

4. 关键代码实现与实操步骤

4.1 项目骨架搭建与依赖配置

创建项目我不推荐手写所有配置。用 IDEA 的 Spring Initializr，或者直接到 Spring Initializr 网站生成，选 Spring Boot 2.7.x，依赖先勾 Web、MyBatis、MySQL Driver。生成后把 pom.xml 打开，补充 MyBatis-Plus、JWT、Lombok 这些依赖。核心内容长这样：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency>

application.yml 是启动的命门。列出三个核心注意点：

• datasource url 必须带 serverTimezone=Asia/Shanghai，否则 MySQL 8.0 报时区错误。
• mybatis-plus 的 mapper-locations 要指向 xml 所在目录，默认classpath:mapper/*.xml。
• 文件上传的 multipart 限制要提前调大，否则前端传图报 413。

启动类上必须加 @MapperScan，告诉 MyBatis 去哪里找 Mapper 接口。这一步漏掉，启动时会报“mapper not found”，运行时报“Invalid bound statement”。这个简单但高频的错误，每年都有人踩：

@SpringBootApplication @MapperScan("com.example.privatechef.mapper") public class PrivateChefApplication { public static void main(String[] args) { SpringApplication.run(PrivateChefApplication.class, args); } }

搭完骨架后，先写一个/api/health接口，确认能访问，再把前端页面接上来。先跑通最小闭环，再往后加业务，这个顺序能省你至少一天调试时间。

4.2 MyBatis-Plus 快速开发技巧

MyBatis-Plus 对毕设太友好了，尤其是 BaseMapper。你把 Mapper 接口继承 BaseMapper 后，insert、delete、updateById、selectById 这些单表操作全部免费。写条件查询时用 LambdaQueryWrapper，防止手写字段名拼错：

LambdaQueryWrapper<Dish> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Dish::getChefId, chefId) .eq(Dish::getStatus, 1) .orderByDesc(Dish::getSalesCount); List<Dish> dishes = dishMapper.selectList(wrapper);

后端分页一定要配置分页插件，否则 page 方法只能查出全表再内存分页，数据量一大就卡。加一个 MybatisPlusConfig 配置类，注入 PaginationInnerInterceptor，然后在 service 里用 Page 对象调用 selectPage 方法即可。答辩时你说“我用 MyBatis-Plus 分页插件做了数据列表的分页查询”，这句话本身就是技术考核点。

4.3 统一返回结果与全局异常处理

给前端对接定一个统一协议：返回 JSON 结构固定为 code、message、data。写一个 R 类，包含 ok() 和 error() 静态方法。所有 Controller 都返回 R，前端拦截器只判断 code，异常时弹一条全局消息，业务代码里几乎不用写 try-catch。

全局异常处理用 @RestControllerAdvice 注解，捕获 BizException、参数校验异常和兜底 Exception。把系统异常统一包装成 R，就不会出现前端拿到一段英文堆栈的情况。这个小设计一定要写进文档，评审老师很看重这种规范性的东西。

4.4 文件上传与图片资源管理

菜品图片上传，前端用 Element Plus 的 el-upload 组件，后端写一个 uploadController，接收 MultipartFile，把文件写到指定目录，再返回 HTTP 可访问的 URL。

本地存储版最小实现思路是这样：

@PostMapping("/upload") public R<String> upload(MultipartFile file) { String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID() + ext; file.transferTo(new File(uploadPath + fileName)); return R.ok("/uploads/" + fileName); }

注意几个坑：文件名一定要用 UUID 重命名，防止中文名和重名；上传目录要确保应用有写权限；如果走 Minio，就把这段逻辑换成 minioClient.putObject，同时把桶名和访问域名配到 yml 中。Minio 的好处是文件不随应用重启而丢失，Spring Boot 传文件的常规解法是你必须掌握的基础能力。

5. 常见问题与避坑速查

5.1 Spring Boot 版本与启动失败排查

先说说版本问题。每年都有同学因为选了太新的 Spring Boot 版本，导致开发周期延迟。最常见的现象是 JDK 版本不匹配、某个依赖没有适配、自动配置行为变化。如果你刚接触 Spring Boot，我更建议选 2.7.x，配合 JDK 8 或 11，这是最稳的搭配。热词里“springboot版本太高”不是调侃，是无数人用眼泪换来的教训。

启动失败是排查大项，我整理成一张速查表：

排查有一个好方法：把 MyBatis 的 SQL 日志打开，看实际执行的语句。在 application.yml 里配置log-impl: org.apache.ibatis.logging.stdout.StdOutImpl，一切 SQL 都会打在控制台，报错时一目了然。

5.2 前后端联调常见的三个坑

第一个是跨域。前后端分离开发时，前端跑在 5173，后端跑在 8080，浏览器会拦截跨域请求。解决方案是在后端配置跨域映射：

registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600);

注意 allowCredentials 和 allowedOriginPatterns 必须配套使用，不能写 allowedOrigins("*") 加 credentials，否则部分浏览器会报错。

第二个是登录后没带 Token。前端 axios 实例里要加请求拦截器，把 localStorage 里的 Token 放到 Authorization 头。忘记加的话，后端所有需要登录的接口都会返回 401，这个错误新手最容易踩。

第三个是文件上传 413 问题。原因一般是后端 multipart 限制太小，或者 Nginx 的 client_max_body_size 没调。先调大 Spring 配置，再检查代理层配置，两处缺一不可。

5.3 数据库设计中的细节

数据库设计有三个细节值得单独强调。金额字段用 decimal(10,2)，不要用 float/double；订单号用生成的长单号，不要用自增 id 暴露给用户；时间字段建议用 datetime，保存时指定 update_time 自动更新。

另一个容易忽略的是“逻辑删除”。用户或菜品删除时，不要真的 DELETE，可以在表里加一个 deleted 字段，MyBatis-Plus 的 @TableLogic 注解会帮你自动实现逻辑删除。这样数据可以留痕，答辩时也可以提“我做了数据的软删除设计”。数据库设计的规范程度，在答辩时远比代码行数更能体现工程素养。

6. 打包部署与答辩准备

6.1 Maven 打包与 Docker 部署

项目完成后，打包部署这块直接决定演示效果。用 Maven 打 jar 包：

mvn clean package -DskipTests

运行时先用java -jar验证本地能启动，再考虑容器化。如果你愿意折腾，可以写 Dockerfile：

FROM openjdk:11 WORKDIR /app COPY target/privatechef-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

构建和启动：

docker build -t private-chef . docker run -d -p 8080:8080 private-chef

这里有个细节：容器里访问 MySQL 不能再用 localhost，要写宿主机的局域网 IP，或者在 docker run 的时候加 --network host。我在指导时见过不少人在容器连不上数据库的坑里折腾半天，提前说清楚能少走弯路。

部署时也可以把前端 Vue 打包后的 dist 目录复制进 Spring Boot 的 static 目录，实现“一个 jar 包跑全部”。Vue 打包前把接口地址改成相对路径或同域路径，不然上线后接口全挂。

6.2 答辩演示流程与亮点话术

演示时不要只点页面，要按业务链路来。从注册登录开始，浏览厨师和菜品，发起一条定制需求，切到厨师端接单，回到用户端支付，最后评价。一条链路走通，所有模块全部覆盖，评委不需要过多追问就能理解。

技术亮点准备两句就够了：

第一句：登录认证采用 JWT 无状态方案，服务端不保存会话状态，适合前后端分离部署。

第二句：数据层使用 MyBatis-Plus 的条件构造器和分页插件，在中小规模数据场景下显著提高开发效率。

这两句话术比你读半天论文有用。答辩最忌讳从头念文档，按业务流程讲故事，才是正确打开方式。

6.3 可扩展方向与加分项

如果时间充裕，想拿更高分，可以选下面几个方向做一个深入扩展。

私厨按距离排序：在 chef 表里存经纬度，用 Haversine 公式计算距离并排序，前台显示“距离 3 公里”。

厨师接单日历：以天为维度展示可约时间段，用户按时间段发起需求，从根源上避免时间冲突。

营养计算：菜品表加热量、蛋白质、脂肪等字段，按订单汇总显示营养表，适合健身餐场景。

语音定制：接 ASR 识别接口，把用户语音需求转文字，填入定制备注，体验直接上一个台阶。

这些都建立在已完成的业务链路上，扩展成本低、亮点足，论文的创新点也不用挤在同一个模块里反复吹。

最后再分享一点个人体会。毕业设计和商业项目不一样，它更像是一次完整的工程训练：你要把一个需求从零变成能演示、能讲清的系统。私厨服务菜品定制平台这个方向，胜在业务闭环清晰、技术上刚好覆盖 Spring Boot 常用能力，只要按流程做完，论文和答辩都不会差。

这些年我带毕设有个固定建议：做完主体功能后，一定要写一个“演示数据初始化”SQL 文件，把所有厨师、菜品、订单、评价都填满具名的、看起来真实的数据。截图好看、演示顺滑、评委体验也会好很多。另一个建议是答辩前换一台电脑完整跑一遍流程，环境差异带来的奇怪坑，遇到了才知道痛。找到一条稳定可复现的演示路径，比你多写一百行代码都更重要。