企业官网建设流程全解析

做外卖点餐管理系统的人不少，但真正把Java后端、Vue前端、数据库脚本和配套文档凑齐全套的并不多。这套“基于Java + Vue的外卖点餐管理系统”就是这样一个全栈项目：Spring Boot提供REST接口，Vue负责页面交互，MySQL保存业务数据，三者组成一个可以直接跑起来、也可以二次开发的完整闭环。对于想找练手项目的开发者，或者准备拿来做课程设计、简历项目的同学来说，这套系统最大的价值不是“能登录能下单”的表面流程，而是你可以在一个真实业务场景里看到前后端如何配合、权限如何设计、订单状态如何流转这些课本上很难讲透的东西。

我要先说明一下，下面所有内容不是单纯的“项目介绍”，而是我从一个“拿到这套源码后该怎么用起来”的角度，把核心模块、代码思路、常见坑位一条条拆开讲清楚。你可以把它理解成一份高浓度的使用笔记加源码导读，比对着文档瞎改代码要省力得多。

1. 项目概览与技术栈解析

1.1 一个系统，三种角色，两条业务线

拿到这套系统后，第一件事不是看代码，而是先理解角色划分。外卖点餐系统天然存在三方参与者：普通用户负责点餐，商家负责出餐，平台管理员负责运营。如果用一套代码支撑三种角色，最直观的做法是在用户表里设计role字段，0是普通用户、1是商家、2是平台管理员，后端根据角色控制接口权限，前端根据角色渲染不同菜单和页面。

三条角色线对应两条核心业务线：用户侧的下单链路，从浏览商家、挑选菜品、加入购物车、提交订单到模拟支付；平台侧的运营链路，从商家入驻审核、菜品上下架到订单状态跟踪、销售数据统计。我见过很多半成品项目只做了用户点餐，商家端只是摆设，这套项目把两端流程都做全了，这也是它值得拿来学习的一个重要原因。

1.2 技术选型：为什么是Java + Vue + MySQL

后端用Java生态是外卖类管理系统最常见的选择，原因很实在。Spring Boot大幅简化了配置，内嵌Tomcat让部署变成一个java -jar命令；Spring Security或JWT方案做登录鉴权成熟稳定；MyBatis-Plus进一步减少了CRUD的重复劳动。对比Python系或PHP系，Java在事务控制、并发处理、接口规范上更严谨，正好匹配一个“订单+金额+库存”的核心场景。

前端选择Vue也很合理。Vue的组件化开发适合把用户端、商家端、管理端拆成独立模块，Element UI组件库自带表格、表单、级联选择、分页组件，能快速搭出后台管理界面。加上Vue Router做路由控制、Axios做HTTP请求，一套代码里同时管理三种角色视图非常顺手。

数据库选MySQL没有悬念。开源、稳定、资料多，学生项目和企业系统都用它。设计好索引、用对事务，几千甚至几万条订单对MySQL来说完全没压力。

为什么不是微服务？因为外卖点餐的核心业务都在同一个领域边界内，订单、菜品、用户之间的调用关系紧密，单体应用+MVC分层足够清晰。盲目拆微服务只会增加部署和调试成本，这也是我反复跟想做这个项目的同学强调的一点。

1.3 源码+数据库+文档的组合拳，解决了什么

很多开源项目只有源码，没有初始化数据库脚本，也没有配套说明，光是接通环境就得耗掉半天。这套项目把三者打包齐了：源码告诉你代码怎么写，数据库脚本告诉你表结构怎么建，文档告诉你系统有哪些功能、怎么启动、接口怎么设计。

实际价值在于“可复现”。你不需要靠猜去补字段，不需要自己琢磨某个模块的原始设计意图。导入SQL脚本，改一下数据库连接配置，前后端分别启动，就能看到一套完整的外卖系统跑起来。这个从零到一的闭环完成之后，再改代码、加功能，心里才有底。

2. 数据库设计拆解

2.1 核心表结构：8张表撑起整套系统

打开SQL脚本，你会发现这套系统的表结构并不复杂，但每一张表都对应明确业务模块。最基础的是tb_user用户表，除了用户名、密码、手机号，还有一个关键的role字段区分角色；商家信息单独抽成tb_merchant表，存放店铺名称、地址、评分、营业执照信息，这样用户表和商家表职责清晰，不会揉成一团。

菜品相关的表有两张：tb_category菜品分类表和tb_dish菜品表。分类表挂在商家ID下，菜品表再挂到分类ID下，这种“商家→分类→菜品”的三级结构是外卖系统的通用建模方式。菜品表里的status字段控制上下架，stock字段控制库存，sales字段统计销量，是后续订单和统计功能的基础。

再往下是购物车、订单和地址模块。tb_cart购物车表只需记录用户ID、菜品ID、数量等基础信息；tb_address收货地址表保存用户常用地址；tb_orders订单表和tb_order_item订单明细表是整套系统中最核心的两张表，也是我建议你花最多时间研究的地方。

以tb_user表的建表语句为例，你能看到不少值得模仿的细节：

CREATE TABLE `tb_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(64) NOT NULL COMMENT '登录名', `password` varchar(128) NOT NULL COMMENT '密码（BCrypt加密存储）', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `avatar` varchar(255) DEFAULT NULL COMMENT '头像地址', `role` tinyint(4) DEFAULT '0' COMMENT '角色：0-用户 1-商家 2-管理员', `status` tinyint(4) DEFAULT '1' COMMENT '状态：1-正常 0-禁用', `create_time` datetime DEFAULT NULL COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

2.2 订单表与订单明细表：为什么必须拆开

很多新手在设计订单功能时会纠结：一个订单里可能包含多个菜品，如果只在订单表里放一个dish_ids字段，用逗号拼接，看似省事，实际上会带来一连串问题。比如你想统计某个菜品卖了多少份，就必须把订单里的字符串拆出来算，性能差、容易错，还没法用SQL直接查询。

正确的做法是拆两张表。tb_orders订单表只保存一次下单的摘要信息：订单编号、用户ID、商家ID、总金额、订单状态、收货地址ID、备注、创建时间。tb_order_item订单明细表保存该订单对应的每一道菜品：菜品ID、菜品名、菜品图片、购买单价、购买数量、小计金额。

这两张表通过order_id建立主外键关系，形成典型的“一父多子”结构。它的好处体现在几个场景里：商家接单时只需要看订单表；对账时按订单明细逐项核对；用户查看“我的订单”时拿到订单表主记录后，再用order_id查出明细列表。下单的时候，两张表必须在同一个数据库事务里同时写入，避免出现“有订单没明细”或者“有明细没订单”的脏数据。

2.3 金额字段与状态字段：建表时留下的关键教训

外卖系统里所有跟钱相关的字段，都必须用decimal，不能用float或double。这一点我每次都要强调，因为浮点数在二进制里没法精确表示，0.1加0.2算出来可能是0.30000000000000004，一旦累计到订单金额、分成比例上，对账就会出问题。decimal(10,2)表示最多存8位整数加2位小数，对于外卖订单金额完全够用。

订单状态字段建议用tinyint存数字枚举，而不是直接存中文。比如0待支付、1已支付待接单、2商家已接单、3配送中、4已完成、5已取消、6已退款。数字状态在代码里用常量类或枚举维护，展示时再映射成中文，这样写条件判断简单，也不怕改动文案导致数据错乱。

时间字段统一用datetime，手机号、备注等长度差异大的字段不要省空间，保持合理冗余。所有表都用utf8mb4字符集，避免用户输入生僻字或者表情符号时出现乱码。这几个细节看起来不起眼，但直接影响系统能不能在真实环境中稳定跑下去。

3. 后端重难点：登录鉴权、订单状态机与并发扣库存

3.1 JWT登录鉴权：前后端分离的安全基线

前后端分离项目里，Session方案不好用，因为前端和后端不在一起，跨域携带Cookie麻烦，分布式部署时Session共享也是问题。这套系统用JWT（JSON Web Token）做登录鉴权，思路很简单：用户登录成功后，后端签发一个带签名和过期时间的Token返回给前端；前端把Token存在localStorage里，之后每次请求在Authorization头带上；后端写一个拦截器统一校验Token，合法才放行。

核心代码长这样：

String token = Jwts.builder() .setSubject(userId.toString()) .claim("role", userRole) .setExpiration(new Date(System.currentTimeMillis() + 7200000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

签发的Token里只放用户ID和角色，不放大对象，因为Token一旦泄露，里面的敏感信息就等于裸奔。密码必须用BCrypt加密存储，哪怕数据库被拖走，攻击者也拿不到明文密码。拦截器里遇到token缺失、过期、签名非法时，统一返回401状态码，前端收到401后清理本地登录态并跳回登录页。

这个流程你会在项目中反复看到：登录接口、拦截器、前端拦截器三个环节彼此配合。弄清这套链路，所有需要登录认证的功能都能通。

3.2 订单状态机：每一步都要有迹可循

外卖订单不是提交完就结束的，从生成到完成要经历多个状态。这套系统的订单状态流转是典型的有限状态机，不允许乱跳。用户提交订单后状态是待支付；支付成功后变成已支付待接单；商家接单后变成制作中；出餐配送变成配送中；用户确认收货或者系统自动确认到站后变成已完成。用户也可以在支付前取消订单，商家接单前的取消不需要审核，接单后取消则需要走退款流程。

前后端对状态的处理有一个关键点：后端必须统一校验状态转移合法性，不能只靠前端按钮控制。比如商家点击“接单”时，后端要检查当前订单状态是否为待接单，如果是其他状态就要返回业务异常。我见过有的项目只在接口里直接update ... set status = 2 where id = ?，结果用户先取消、商家后接单，状态直接变成“已接单且已取消”这种逻辑混乱的脏数据。

正确写法是在一条UPDATE语句里带上当前状态条件：

UPDATE tb_orders SET status = 2, accept_time = NOW() WHERE id = #{orderId} AND status = 1

如果更新影响行数为0，说明状态已被其他操作修改，后端抛出“订单状态已变化，请刷新页面”的提示。用这种方式做并发保护，比查出来再判断再更新更可靠，这条经验建议写到任何状态流转的逻辑里。

3.3 并发扣库存：别等上线之后才想起来补锁

点餐高峰期会同时有大量用户在下单，如果菜品库存只剩下最后一份，多个请求同时进来，就可能出现超卖。后端解决方案不是用synchronized锁单个方法（在分布式环境里没用），也不是查库存再更新（存在时间差），而是在更新语句里加库存条件做乐观锁控制：

@Update("UPDATE tb_dish SET stock = stock - #{quantity} " + "WHERE id = #{dishId} AND stock >= #{quantity}") int deductStock(@Param("dishId") Long dishId, @Param("quantity") Integer quantity);

这条SQL的语义是“只有当当前库存大于等于购买数量时才扣减”，MySQL底层的行锁保证同一时刻只有一个请求能成功更新这一行，其余请求要么等待、要么更新0行返回失败。开发者在Service层判断deductStock返回的影响行数，为0就提示库存不足，回滚整个订单事务。

下单链路里有两步必须放在同一个事务里：扣减库存、写入订单和明细。事务保证“要么全部成功，要么全部回滚”，这样可以避免出现钱付了但库存扣了、或者库存扣了但订单没生成的问题。这套思路是外卖点餐项目在真实世界里最该学的核心工程点之一。

4. 前端Vue实战：路由守卫、Axios封装与购物车联动

4.1 多角色路由与前端权限骨架

前端项目用Vue Router管理页面跳转。因为是三套角色共用一套代码，直接把所有页面都放进路由表会让菜单混乱，权限也难控制。合理的做法是按功能模块拆分视图目录：用户端页面放views/user，商家端页面放views/merchant，管理端页面放views/admin，公共页面诸如登录、注册、首页单独放一层。

每个需要登录才能访问的路由，在meta里打上requiresAuth: true标记，然后写一个全局前置守卫做登录校验：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { next('/login'); } else { next(); } });

如果还做角色级权限，可以在路由的meta里配置roles数组，比如商家管理页面允许角色为1和2的用户访问，普通用户角色访问时直接跳403或商家入驻提示页。登录成功后用this.$router.push跳向对应角色首页，菜单根据后端返回的角色动态渲染。这样一套前端代码，三套体验，结构清清楚楚。

4.2 Axios拦截器：统一处理Token与业务错误

前端项目里每个页面都要发HTTP请求，如果每个组件里都自己拼Authorization头、自己处理401，代码会非常冗余。这套项目在utils/request.js里封装了Axios实例，并且配置了请求拦截器和响应拦截器。

请求拦截器负责在每次请求发出前，从localStorage读取Token，放到请求头的Authorization字段：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; });

响应拦截器负责统一处理两种情况：如果HTTP状态码为200且业务码为成功，直接返回data字段，页面代码只需要拿到干净的结果；如果后端返回401，清理本地Token并跳转登录页；如果是业务异常，统一弹出错误提示。

service.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res; } if (res.code === 401) { localStorage.removeItem('token'); router.push('/login'); } Message.error(res.message); return Promise.reject(new Error(res.message)); }, error => { Message.error('网络请求异常，请稍后重试'); return Promise.reject(error); } );

这套封装是前端工程化的标配，也是面试里高频考察的点。你把这个文件看懂了，几乎所有后台管理类前端项目的请求层都能举一反三。

4.3 购物车：跨商家合并与实时计算总价

购物车是前端交互最密集的模块，也是后端“写购物车表”和前端“本地联动”容易出问题的地方。常见的交互需求是：用户在不同商家分别点餐，购物车里按商家分组展示，每个商家的菜品单独小计；用户勾选某一道菜、修改数量时，页面右下角的总价实时变化。

这套系统里的实现思路是：购物车数据以后端为准，前端每次进入购物车页面时先拉取购物车列表，并按merchantId分组；加减数量调用后端接口更新数量，成功后重新拉取列表或直接本地更新小计。有一个关键点容易踩坑：一个商家的菜品只能出现在同一个商家的分组下，下单时也要按商家拆单——如果用户点选了A、B两个商家的菜，前端要把它们分别提交成两笔独立订单，而不是混成一单。

单位换算也值得留心。购物车里的数量单位可能是“份”，后端库存扣减的也是“份”。前后端传值时统一用quantity整数，避免把字符串数字传来传去，否则quantity = quantity + 1在字符串拼接下就会变成“11”而不是“2”。这种代码写多了就能体会到，前后端数据规范比功能本身更影响稳定性。

5. 部署、联调与排错指南

5.1 从零到能跑起来：启动步骤按顺序做一定顺畅

拿到源码后，不要急着点运行，先把启动顺序理顺。整套环境的依赖是：JDK 8以上、Maven、MySQL 5.7或8.0、Node.js 14以上、npm。

第一步，创建MySQL数据库并导入脚本身。打开项目里的SQL文件，通常是一条包含建库、建表、初始化数据的完整脚本，在Navicat或命令行里执行即可。执行完检查一下表是否齐全，重点看看用户表里是否有一条管理员账号，没有的话后续管理端登录不了。

第二步，修改后端配置。打开application.yml，把数据源部分的url、username、password改成你本机MySQL的实际配置。Java项目的数据库连接串里注意加上时区和字符集参数：

spring: datasource: url: jdbc:mysql://localhost:3306/takeout?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: yourpassword

第三步，启动后端。在项目根目录执行mvn spring-boot:run，或者用IDEA打开后端工程直接运行启动类。看到“Started Application in xx seconds”日志，且无报错，说明后端启动成功。

第四步，启动前端。进入前端目录，先执行npm install安装依赖，再执行npm run serve，等待Vue开发服务器启动。这里要注意，前端默认配置了开发代理，把/api开头的请求转发到后端8080端口，所以后端必须保持运行。

第五步，用配置好的管理员账号登录管理端，按正常流程浏览商家端和用户端页面。如果页面能正常加载数据，能下单、能改状态，整个环境就算全部打通了。

5.2 常见报错排查速查表

我整理了一张问题排查表，是前后端项目里最常遇到的几类情况，建议打印出来放桌边：

5.3 我在实际项目中踩过的三个坑

第一个坑是订单金额用Double累加导致的精度问题。当时给购物车算总价，前端拿0.2 + 0.1算出0.30000000000000004，传回后端又被转成字符串保存，数据库里出现了一长串乱码小数。后来统一在前后端都用“分为单位”的整数传递，展示层做除以100的换算，彻底消除了浮点误差。这套系统里的金额字段虽然用decimal，但前端计算时也要注意用库函数或整数运算，尽量避免裸用浮点数相加。

第二个坑是订单状态流转没有加条件更新。早期版本商家接单接口直接按订单ID更新状态，结果用户先取消了订单，商家再点接单还能成功，界面上出现一条“已接单但已取消”的诡异状态。改成UPDATE ... WHERE id = ? AND status = 1之后，这种并发下的脏状态再也没有出现过。

第三个坑是前端路由守卫只校验了是否存在Token，没校验Token是否过期。用户挂着旧Token等到第二天继续操作，接口返回401，页面却还在正常跳转。后来在Axios响应拦截器里全局处理401，并结合路由守卫做兜底，才算把登录态失效这整条链路打通。

这三类问题都是实际项目中大概率会遇到的，与其以后在线上一脸懵，不如现在读源码的时候多留心对应位置的处理方式。

6. 这套源码还能怎么改出花样

把基础流程跑通之后，建议你别急着开新项目，试着在现有代码上做增量改造。最简单的方向是给订单加上“超时自动取消”的定时任务，严格来说每5分钟扫描一次待支付订单，超过10分钟未支付就把订单改成已取消并回滚库存。这个功能看似简单，却能让你深入理解定时任务、库存回滚和订单状态联动。

进阶一点的方向是把模拟支付换成真实接入，或者是给商家端做一个简单的销量统计图表，按日、按周聚合订单数据。前端用ECharts画柱状图和折线图，后端写聚合查询接口，做完你就能掌握“报表类功能”的完整实现套路。

如果想把项目做得更完整，还可以加一个Redis缓存层，把菜品列表、店铺信息这些读多写少的数据缓存起来。外卖系统的读请求量远高于写请求量，引入缓存后接口响应速度会明显提升。这套源码的核心骨架搭得很规整，在这些方向上动刀都不算伤筋动骨。

从我的经验来看，能把这套系统从头到尾跑通，再把其中任意一个模块改成自己想要的样子，你对Spring Boot + Vue全栈的理解会跨上一个台阶。

最后再分享一个实际心得：拿到这类完整项目，别一上来就翻代码，先把SQL脚本导入数据库，用数据库工具看一眼表结构和初始化数据，再照着文档跑一遍流程。带着“数据在哪些表之间流转”的视角去看代码，你会看到以前忽略掉的细节——比如购物车分组如何驱动前端UI，状态字段如何约束后端更新逻辑。这套项目我在指导某开发者复盘时反复梳理过，每次都有新的收获。动手改几处、踩几次坑，再回头看，这套系统的设计思路才真正变成你自己的东西。