企业官网建设流程全解析

SpringBoot + Vue 的美食网站管理平台，Java + MySQL，B/S架构——这几个关键词凑在一起，基本就是一套非常适合毕设或课设的现成源码。前阵子A同学在选题上卡了一周，纠结做移动端还是网页端，我把这个平台的结构拆给他看之后，他两天就把登录、菜品列表和下单流程全部打通。这篇文章会把整套项目从数据库到前端页面完整拆开讲，包括表结构怎么设计、登录鉴权怎么做、订单状态怎么流转、前后端怎么对接，以及实际跑项目最容易踩的坑。适合的对象很明确：正在做毕设或课设、需要一套能跑通又讲得清的项目同学，或者想练手前后端分离开发的学习者。

1. 这个美食平台解决了什么问题

1.1 用户端与后台管理端双视角

一个完整的美食网站，只做前台展示是不够的，还要有人维护菜单、处理订单。所以项目天然分成两条线：用户端负责注册登录、浏览菜品、加入购物车、下单和评价；管理端负责菜品增删改、分类维护、订单状态流转和用户管理。两条线共用同一个数据库，但视图和接口完全分开，这在毕设里叫“角色维度完整”。

很多同学起步时容易只做前台，演示的时候老师一问“菜单谁维护？订单你怎么处理？”就答不上来。这套平台最大的价值是帮你把两个视角都补齐，形成从“用户下单”到“商家接单”的完整闭环。就算你最后只挑其中一部分去重构，也能很自然地说清楚大部分业务是怎么走通的。代码在手，逻辑自洽，这和那种只摆了一堆页面的半成品项目，完全是两个量级。

1.2 为什么 SpringBoot + Vue 始终是首选

说句实话，技术栈在毕设里占的分数没有想象中高，但选一个主流、稳定、参考资料多的组合，能省掉大量查资料的时间。SpringBoot 的核心价值是自动配置。过去写 SSM 或者 SSH 要配一堆 XML，现在靠起步依赖和 application.yml 就能把一个 Web 项目跑起来，内嵌 Tomcat 让部署也简单很多。Vue 这边的优势是组件化开发，把页面拆成组件后，首页、列表、详情可以复用同一套样式和逻辑，代码维护起来很轻松。MySQL 则是免费、稳、SQL 直观，几乎所有教程都能直接套用。

这个组合相比传统的 JSP+Servlet 写法，还有一个隐藏优势：前后端分离。你可以在答辩时说“前端是独立工程、后端是独立工程，通过 HTTP 接口通信”，这一句话本身就体现了现代 Web 开发的核心思路，老师听到通常不会追问太深。而且 Vue 生态里的组件库非常齐全，表格、表单、弹窗这些管理端常见界面，都是拖拽级别的工作量，适合在有限时间内把功能做完整。

1.3 B/S 架构在毕设场景里意味着什么

B/S，也就是浏览器/服务器结构，用户打开浏览器就能访问，不用安装客户端。毕业设计演示现场通常只有一台主机和一台投影，B/S 项目用浏览器打开就能跑，基本不会因为环境问题翻车。如果需要体现“移动端可用”，在同一个局域网里用手机访问后端地址，现场演示效果会好不少，这比临时去配一台带公网地址的机器要省心得多。

这种架构对应的就是三层关系：前端 Vue 负责展示和交互，后端 SpringBoot 负责业务逻辑，MySQL 负责数据存储。前端发请求，后端处理后返回 JSON，前端再把 JSON 渲染成页面。把这句说清楚，你就已经掌握了这个项目的整体脉络，后面所有代码都是围绕这条链路展开的。对新人来说，先建立起这条链路的概念，再去读源码，就不会一头扎进细节里出不来。

2. 数据库表结构：动手前先理顺六张核心表

数据库设计是这类项目最不该跳过的部分。很多同学上来就写代码，写到订单明细的时候发现根本没有地方记录“某个订单里包含哪些菜品”，只能重来。按照下面这套设计，至少能把主要业务闭环塞进一个比较规整的模型里，后面写接口时能少改很多地方。

2.1 六张核心表及字段设计

我建议按下面的表结构来建，字段名统一使用小写下划线风格，后面写 MyBatis 对应关系时不会头疼，前端拿到 JSON 之后也容易分辨。这张表基本覆盖了一个美食网站的全部核心数据。

user 表里加一个 role 字段用来区分管理员和普通用户，比单独建管理员表简单得多。dish 表里的 sales 用来做销量排序，这就是“推荐菜品”背后的数据来源。orders 表必须有一个 order_no，它在用户端是给用户看的单号，在内部则是防止并发重复的关键字段。密码那栏一定要存加密后的值，不要明文入库，这是安全底线。

2.2 表之间如何关联，订单状态字段怎么设计

先看外键关系：orders.user_id 关联 user.id，order_detail.order_id 关联 orders.id，order_detail.dish_id 关联 dish.id，comment 同时关联 user 和 dish。逻辑上一目了然，但有个细节我建议照做：order_detail 里除了 dish_id，还要冗余存一份 dish_name 和 price。为什么？因为如果厨师把某道菜改名，或者菜品涨价，你总不能要求用户的历史订单跟着变。冗余字段换来的，是历史订单展示的正确性——这在答辩中非常加分，能体现出你考虑过真实业务场景，而不只是跟着教程建表。

订单状态用整数：0 待支付、1 已支付、2 制作中、3 配送/待取餐、4 已完成、5 已取消。判断只用 ==，不会出现字符串拼错的情况。Java 端写一个 OrderStatus 常量类，前端也定义对应的文本映射，两边对死就不会乱。关键约束是状态不能跳着变：已取消的订单不可能被改成已支付，这些校验在后端做一层，能挡掉大多数脏数据。

2.3 建库脚本和初始数据

建库时注意字符集要用 utf8mb4，因为这个字符集支持表情符号和生僻字，避免菜品描述里出现特殊字符时写入失败。初始化脚本里至少放四样东西：一个默认管理员账号、若干示例分类、一批菜品数据，以及一两条测试订单。菜品图片推荐使用项目内部的本地路径，比如 /images/dish/p1.jpg，不要写死外网链接，否则换环境演示时图片全部裂开。

SQL 文件我建议放在项目根目录 sql/food_db.sql，并在 README 里写清楚导入步骤。导入完成后用 SELECT 验证一下 dishes 表和 orders 表是否有数据，再启动后端。这一步花五分钟，能省下后面一个小时的排查时间。导入时机也很重要：最好在后端启动之前完成，因为现在很多项目启动时会自动校验数据库，连不上直接退出。

3. 后端 SpringBoot 实现里最值得琢磨的四个点

后端代码量不算大，但有几个地方是“会写”和“写得好”的分水岭。我按自己实际写项目的顺序来讲，每一块看完都能直接落到你的工程里。

3.1 controller-service-mapper 三层怎么落

项目里最常用的结构是 com.xxx.controller、service、mapper、entity、common 这几个包。controller 只负责接收前端参数和返回统一格式，不写业务；service 处理校验、计算、状态流转；mapper 和数据库打交道。这样做的好处是，出 Bug 时你能根据报错堆栈很快定位在哪个层，答辩时也能用一句话讲清设计思路。

我习惯封装一个 Resp 对象，所有接口都返回这种格式：{ code: 200, msg: "操作成功", data: ... }。前端拿到之后统一判断 code，而不是直接操作 raw body，可以减少很多联调中的理解成本。比如菜品列表接口，controller 里就几行，核心逻辑全部在 service 层。对新手来说，这种“贫血模型”的分层方式虽然不花哨，但是最容易理解和维护的，也最不容易被老师挑出结构性问题。

3.2 JWT 登录鉴权：为什么不用 Session

前后端分离的项目，我强烈推荐 JWT 代替 Session。Session 依赖服务器内存和 Cookie，跨域时要额外配置，前端还要处理 Cookie 携带问题。JWT 是无状态的：后端签发一个带签名和过期时间的 token 给前端，前端每次请求把它放在 Authorization 头里，后端验签通过就算登录，不需要在服务器存 Session。权限校验完全可以在网关层或者拦截器里完成，分布式环境下优势更明显。

实现不难：先在 pom 里引入 jwt 依赖；登录接口查用户并比对加密后的密码；验证通过后用密钥生成 token，payload 里放 userId 和 role，过期时间给 24 小时；再写一个拦截器，对 /api/** 路径放行登录接口，其余都要从请求头里解析 token，解析失败返回 401。还需要在配置类里把静态资源和登录相关接口排除在拦截范围之外。管理端接口再补一步 role 判断，挡住普通用户访问后台。

3.3 下单事务和订单状态流转

下单是整个项目里最不能出错的地方。在 service 层用 @Transactional 包住整个方法：先根据明细里的菜品 id 批量查价格和库存，校验库存是否充足；算出总价插入 orders 表；再把每个菜品插入 order_detail；最后扣减库存。事务只要有一环失败就全部回滚，不会出现“订单生成了但库存没减”的情况。

状态流转是一个业务规则问题。用户下单后 status=0，支付成功后变成 1，管理端点开始制作变成 2，制作完成变成 3，用户点击确认收货变成 4。每一步都加判断：比如已取消的订单不能支付，已完成的订单不能再改状态。代码里可以维护一个状态流转 Map，key 是当前状态，value 是允许跳转到的下一批状态，流转时先查 Map 再落库。这样即使前端乱点按钮，后端也能保证订单状态始终合法。

3.4 菜品图片上传：本地存储最简单

毕设场景下，图片上传建议先用本地文件存储方案：前端把图片文件通过 FormData 提交给后端的 /upload 接口，后端用 MultipartFile 接收，保存到项目外的独立目录，再把访问路径返回给前端。这里有个坑：如果保存进项目内部 target 目录，执行 maven clean 之后图片会一起没掉，所以项目外路径更安全，例如配置成 D:/data/food_images/。

保存完成后，还需要给后端加一个静态资源映射配置，让 /images/** 这类路径能映射到本地图片目录。前端拿到返回的图片相对路径后，拼上后端地址就能显示。如果时间充裕，可以给文件名加上 UUID 前缀，避免不同用户传了同名文件互相覆盖；正式环境下不少人会改用对象存储之类的服务，但毕设本地方案完全够用，而且能省掉账号和网络方面的考虑。

4. 前端 Vue 页面与接口对接的实战笔记

前端部分按“用户端页面 - 管理端页面 - 请求封装 - 联调细节”四块讲。这里以 Vue 2 + Element UI 为例，如果你拿到的是 Vue 3 + Element Plus 的源码，思路完全一样，只把组件名做少量替换，不影响阅读。

4.1 用户端页面结构

用户端至少需要这几个页面：首页 /、菜品列表 /dishes、菜品详情 /dish/:id、购物车 /cart、订单列表 /orders 和登录 /login。首页放一个轮播图加推荐菜品，推荐逻辑就调销量最高的几个接口。菜品列表页支持分类切换、关键词搜索、分页，这些在原生 HTML 里很难写利索，但 Vue 配合组件库很快。每个菜品卡片显示图片、价格、销量，点击进入详情页后展示描述和评论列表。

购物车我用 localStorage 来实现，不做后端持久化。加购物车时把菜品信息、数量、单价写入一个数组并同步到本地，结算时把这个数组带到下单接口。这么做的理由是：购物车属于临时会话数据，存本地可以少写一套增删改查接口，对毕设完全够用，也能让代码量更聚焦在下单和订单管理这些核心逻辑上。缺点是换设备购物车不同步，但这不影响一个课程设计的核心验收点。

4.2 管理端页面与权限控制

管理端做成一套 /admin 下的独立路由，布局用侧边菜单加顶栏，菜单项是分类管理、菜品管理、订单管理、用户管理。表格用组件库的 table，表单用 dialog 弹窗，每个管理页都包含增删改查。菜品管理里要特别注意表单校验：价格必须大于 0，图片必须选择，分类不能为空。订单管理页的操作列放“更新状态”按钮，把订单 id 和新状态传给后端，后端按当前状态判断能不能流转。

权限控制靠两步。第一步是路由导航守卫，在 beforeEach 里读 localStorage 中存的 role，如果目标是 /admin 开头且不是管理员，就跳转到登录页。第二步是后端接口也做 role 校验。前端可以挡页面跳转，后端负责挡真实请求，两边都做才安全。很多项目只做了前端隐藏菜单，直接访问后端接口照样能操作数据，这种漏洞在演示时被老师抓到会很尴尬。

4.3 axios 请求封装与 token 注入

所有请求建议统一走一个 request.js：创建 axios 实例，baseURL 设为 /api，然后在 request 拦截器里把 token 从 localStorage 取出拼到 Authorization 头，response 拦截器里统一判断 code。后端返回 401 时，拦截器直接清空登录状态并跳转登录页；其他错误统一提示后端返回的 msg。这样业务代码里就不会到处重复写“处理 token、弹错误提示”的样板逻辑。

token 注入是前后端分离的核心动作。Session 时代浏览器会自动带 Cookie，JWT 时代就得自己手动带，很多人忘记这一步导致“登录成功但没过多久又让你登录”。你把 token 存进 localStorage 并写在拦截器里，这个坑就在全项目范围一次性解决。对新手来说，这个封装还能顺便统一处理 loading 状态，请求发出时显示加载遮罩，结束后关闭，视觉上会专业很多。

4.4 联调时的跨域与字段对齐问题

跨域要处理两层：开发环境用 Vue 的 devServer 代理把 /api 转发到后端地址，生产环境靠反向代理转发。后端同时配一个 CORS 配置放行常见请求头和方法，两边都做最稳。常见现象是浏览器 Network 里请求能发出、后端也能收到，但前端看到的是跨域报错，这就是后端响应头少了 Access-Control-Allow-Origin。

字段对齐是另一个高频 Bug。后端的 price 是 BigDecimal，序列化后是数字，前端直接展示没问题；但日期类型默认是一长串，必须加 @JsonFormat 注解指定格式。还有分页参数，后端用 page 和 pageSize，前端传的就是这两个名字，千万别一边叫 current 一边叫 size，否则数据永远翻不到第二页。最简单的联调口诀：先看后端返回的 JSON 里字段叫什么，前端就访问什么，两边对齐之后 90% 的展示问题都没了。

5. 从零跑通项目：启动步骤与高频踩坑清单

我知道大部分同学拿到源码的第一反应是直接导入 IDE 然后点运行，然后面对一片报错开始崩溃。这一节把从环境到启动的完整顺序，以及我见过最多的几个坑一次性列清楚。

5.1 环境准备与启动顺序

基础环境四件套：JDK 1.8 或 11、Maven 3.6 以上、MySQL 5.7 或 8.0、Node 14 以上。先启动 MySQL 并导入 SQL 脚本，再启动后端，最后启动前端，这个顺序不要乱。后端在 IDE 里直接运行 Application 类，或者命令行切到项目根目录执行 mvn spring-boot:run，看到 Started Application 才算起来。前端切到 frontend 目录执行 npm install，然后 npm run dev，控制台出现 localhost 加端口号就说明开发服务器正常。

整个项目实际会占用三个端口：MySQL 的 3306、后端接口的 8081、前端页面的 8082。建议启动后用浏览器分别访问后端的一个简单接口和前端的首页，先确认单端正常再开始联调。一次只解决一个问题，比面对一屏幕报错乱猜高效得多。很多人把时间浪费在同时改三个端口上，结果分不清错误到底来自哪一段链路。

5.2 这四个坑占掉了我八成排错时间

第一个坑最常见也最容易被忽略：很多人 Java 环境日志写得明明白白是连不上数据库，却还在反复检查代码。记住，数据库服务本身必须是一个独立启动的服务，不是 IDE 能帮你启动的。第四个坑建议拿到源码后第一时间配置镜像源，不然等 npm 下载完依赖会消耗大量时间。排错的核心思路是沿着请求链路逐段判断：前端能不能发出请求、后端有没有收到、SQL 能不能查到数据，逐项缩小范围。

5.3 拿到源码后的五步检查清单

第一步，在项目根目录找 SQL 文件，导入到 MySQL 并确认表数量正确。第二步，打开 application.yml，核对数据库账号密码、端口、JWT 密钥，这三个不对项目永远起不来。第三步，打开前端 vue.config.js，确认 proxy 目标指向正确的后端地址和端口。第四步，在前端目录执行 npm install 前先确认 Node 版本，过老的 Node 装不上新依赖。第五步，把数据库重置成干净初始数据再做联调测试，避免上一批脏数据干扰判断。

这套检查清单我接手不熟悉的项目时经常用到，基本能在一小时内让一套源码跑起来。遇到问题的时候冷静点，先观察是哪一段链路断了：浏览器 Network 能发出请求，说明前端正常；后端日志有没有打印，是后端探测信号；SQL 能不能手写返回，是数据层是否正常。按链路逐段判断，比盯着报错硬想省时间得多。

6. 答辩与扩展：把“能跑”的项目讲成“值得高分”的项目

项目跑通只是开始。很多人的代码能运行，但答辩时讲不清楚，被老师问两句就卡住。这里把我带学生过程中最有效的一套讲述思路和几个低成本扩展方向整理给你。

6.1 答辩时按“需求 - 设计 - 实现 - 验证”四条线讲

不要从代码第一行讲到最后一行，那会让听的人迅速失去兴趣。建议按四条线讲，每条几十秒：先讲需求，你发现传统美食网站前台和后台割裂，所以要做一体化管理平台；再讲设计，数据库六张表、前后端分离、JWT 鉴权；接着挑一个核心模块深讲，比如下单状态流转，配合状态图示说明规则；最后讲验证，列出你测过的典型场景，比如用户下单后管理员更新状态、用户确认收货后订单完成。

老师最常见的追问是“为什么选这个技术”“有没有考虑另一个方案”。回答的关键是承认权衡，而不是死撑。比如“为什么不用 Redis？因为毕设规模下 MySQL 够用，但订单量大了以后可以在菜品接口前加缓存”，这种回答比背概念有说服力得多。还有个实用技巧：演示前把浏览器开成无痕模式，现场从登录开始操作，顺便展示不会误带本地缓存数据，思路也能更清晰。

6.2 五个短期能落地的扩展方向

如果时间还有两周以上，建议从下面几个方向里挑一个去加，而不是五个都碰。第一个，加 Redis 缓存菜品列表，首页频繁查询的性能问题直接改善，答辩还能讲缓存一致性。第二个，用 ECharts 做后台营业额统计，按天展示订单总额和销量 Top 菜品，视觉效果非常加分。第三个，细化角色权限，引入“管理员”“厨师”“配送员”三种角色，让不同角色只看到自己能操作的订单。第四个，给菜品表加乐观锁版本号，模拟多人同时下单扣库存的并发场景，老师也爱问这类并发问题。第五个，引入自动生成接口文档的组件和全局异常处理器，让项目结构更接近真实团队开发。

扩展功能只要写透一个就够，关键是你必须能讲清楚它解决了什么问题、怎么实现的。贪多嚼不烂，反而会被追问到细节答不上来。每加一个功能，都要预留一天时间来回归测试，确保原有流程不被破坏。

最后说一个我做项目养成的习惯：每次改完数据库字段，先调一次后端接口，看看返回的 JSON 里有没有新字段，再刷新前端页面确认显示一致，两边对不上就把字段名核对一遍。准备答辩演示前，把购物车、登录状态全清一遍，重置成干净数据，现场才能行云流水。这个小流程帮我避免了太多次临场翻车，你照着做基本也不会有什么意外。