简介针对黑马程序员“苍穹外卖”项目的一套完整配套资源面向正在学习Spring Boot后台开发、Vue前端以及小程序开发的读者也适用于毕业设计与项目实训。资源覆盖外卖平台从需求分析、数据库设计、产品原型到前后端编码的完整链路既包含Markdown讲义、SQL脚本、JSON接口定义也提供Java后端与前端工程代码。压缩包约69.96MB包含2000个文件类型构成丰富png、svg等图片素材用于界面展示java、xml为Spring Boot后端逻辑及配置js、css、html、vue对应前端交互与页面md讲义、sql脚本和json文件帮助梳理技术方案与数据接口另有wxml/wxss等小程序资源可满足多端学习需要。已有2547人学习浏览。从理论文档到可运行工程目录按模块组织方便按需查阅配合产品原型与数据库设计能帮助理解项目演进过程无论是跟学实践还是二次开发都是值得收藏的参考资料。1. 苍穹外卖这套资源能解决什么从跑通到看懂一个 Java Spring Boot 外卖项目第一次拿到苍穹外卖全套资源时很多人第一反应是先启动后端然后对着浏览器问一句“为什么页面上没订单”。这套资源的价值不是让你看完一个静态项目而是把一个外卖系统的完整链路摆在面前Java Spring Boot 后端、管理后台前端、用户端小程序、数据库脚本、接口文档和部署配置全都打包在一起。对正在准备 Spring Boot 实战项目、想把“会写增删改查”升级成“会设计业务模块”的开发者来说它直接省掉了从 0 搭项目的时间。适合刚学完 Spring Boot 基础的人去做二次开发也适合作为学期设计或简历项目的底座。业务复杂度刚好没有中间件满天飞但订单、缓存、定时任务、文件上传这些真实业务该有的东西都齐了。2. 项目骨架Spring Boot 多模块、核心表设计和 Redis 的三个落点2.1 多模块拆分为什么把 controller、service、mapper 拆到不同地方开发外卖系统最容易犯的错就是所有代码堆在一个包下改一个 VO 字段要重新编译整个工程。苍穹外卖后端的做法是按 Maven 多模块拆开常见结构是三个模块sky-common放统一返回结果、全局异常处理、JWT 工具sky-pojo放实体类和数据传输对象sky-server放 controller、service、mapper。这个拆分不是炫技它的直接收益是编译隔离。外卖系统里大量存在“用户端和管理端口径不同但底层数据相同”的场景比如订单展示给用户看只需要订单号、金额、状态管理端却要多看收货地址、联系电话、备注信息。如果实体类兼顾数据库映射和前端返回模型数据库字段一变所有接口的返回全部受影响。拆开之后DTO、VO 各自演进公共工具类集中在 common 模块数据库实体留在 pojocontroller 只做参数校验和结果包装service 处理业务规则mapper 只翻译 SQL。实际开发中我很依赖这种结构改错某个 VO 时编译报错会被限制在一个模块内而不是整条接口链路全红排查成本差很多。这个拆法也有前提模块之间依赖方向必须稳定。sky-server依赖sky-pojo和sky-commonsky-pojo不应反向依赖sky-server否则又会把分层拧成一团。有些下载资源里的代码已经出现循环依赖拿到手第一件事就是检查pom.xml看是否有 server 模块被 pojo 反向引用。一旦出现这种问题Maven 编译会周期性报错处理起来比业务 Bug 更耗时。2.2 核心表与订单状态流转先看懂这些表再动代码苍穹外卖这种外卖系统的核心表不算多但每张表之间都有关联。先分清哪张表管账号、哪张表管商品、哪张表管交易后面看代码会轻松很多。表名作用关键字段employee管理端员工/管理员账号id, username, password, statuscategory菜品/套餐分类id, type, name, sort, statusdish菜品基础信息id, category_id, name, price, image, statussetmeal套餐主表id, category_id, name, price, statusshopping_cart购物车id, user_id, dish_id, setmeal_id, number, amountorders订单主表id, number, user_id, amount, delivery_amount, status, address_book_idorder_detail订单明细快照id, order_id, dish_name, dish_image, number, amount这里特别值得留意的是order_detail表。它不是简单记录“订单关联了哪个菜品”而要把下单时刻的菜品名称、图片、价格都保存一份。原因很现实菜品价格和图片是会变的历史订单必须展示下单那一刻的信息。如果回去联查dish表菜品改价之后所有历史订单金额对不上财务报表直接翻车。这是最容易踩坑的地方动手改代码前务必保留这个快照思路。订单状态流转基本围绕一张orders表完成。常见约定是数字状态1 待付款、2 待接单、3 已接单、4 配送中、5 已完成、6 已取消。用户端提交订单后进 1模拟支付成功进 2商家端接单进 3骑手取货后进 4用户确认收货进 5超时或用户取消则进 6。理解状态值的迁移顺序很重要因为很多定时任务就是在订单位置“倒计时取消”的判断的。比如订单卡在 1 超过 15 分钟定时任务把这单改成 6 并释放库存。如果状态枚举值理解错了写出来的定时任务会把已完成订单也取消掉属于比较严重的事故。2.3 Redis 的三个落点菜品缓存、登录态、购物车苍穹外卖里 Redis 出场频率很高但用途基本可以归结为三类菜品缓存、登录态管理、购物车临时数据。这三类用途的数据特征完全不同不能混在一段代码里无脑操作。最典型的是菜品缓存用户端首页按分类展示菜品时如果每次都查 MySQL热点分类会被频繁查询打穿。常见做法是用分类 ID 拼一个 key把查询结果序列化成 JSON 存进 Redis设置 30 分钟过期String key dish_cache: categoryId; String cached stringRedisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseArray(cached, DishVO.class); } ListDishVO dishList dishMapper.getByCategoryId(categoryId); stringRedisTemplate.opsForValue().set(key, JSON.toJSONString(dishList), 30, TimeUnit.MINUTES); return dishList;这段代码的逻辑是先读缓存命中直接返回未命中则查数据库再写回缓存。参数30和TimeUnit.MINUTES是过期时间避免冷数据长期占用 Redis。这里有一个很常见的误区更新菜品后只操作数据库没有删除对应分类的缓存 key导致用户端看到的还是旧菜品。解决办法是在新增、修改、删除菜品的 service 方法里手动把dish_cache:开头的相关 key 删掉。不要尝试“更新缓存”直接删除就是最稳的一致性好方案。登录态用 Redis 是另一个思路。JWT 令牌不只放在客户端请求头里服务端也会在 Redis 里存一份key 用用户 ID 拼接value 存令牌。这样做的最大好处是服务端能主动让某个登录态失效比如管理员禁用员工账号后只需要删掉该员工对应的 Redis key旧令牌立刻作废。购物车则更适合直接用 Redis 存整个 JSON用户加购、改数量、清空都只是读写同一个 key不需要频繁操作数据库。常见 key 设计是cart_ userId过期时间按业务需要设比如 7 天。如果购物车也放进 MySQL并发高时行锁冲突会很明显体验很差。3. 把它跑起来从环境准备到做出第一份订单3.1 环境准备JDK、Maven、MySQL、Redis 缺一不可苍穹外卖这类 Spring Boot 项目本地跑通前先检查软件环境别一上来就导入代码。先确认以下四个基础组件存在java -version mvn -version mysql --version redis-cli pingredis-cli ping返回 PONG 才说明 Redis 正常如果命令不存在就是 Redis 没装或者没有加入环境变量。项目整体基于 Spring Boot 2.x 那套生态本地常用搭配是 JDK 1.8 或 11、Maven 3.6、MySQL 5.7 或 8.0、Redis 3.2 以上。数据库初始化通常由资源包里的sky_take_out.sql脚本完成导入时注意 MySQL 版本差异MySQL 8 默认字符集是 utf8mb4老脚本如果带了utf8建表语句也能兼容但如果是 5.7 导 8.0 备份文件可能会有排序规则冲突。遇到这类报错先把 SQL 文件里的COLLATE相关语句检查一遍再用命令行导入不要用 GUI 工具直接乱点。环境变量方面Maven 仓库建议提前配好国内镜像否则下载依赖会卡得让人怀疑人生。把settings.xml里的镜像换成常见公网仓库即可这一步能省下大量等待时间。3.2 改配置文件数据源、Redis 连接、JWT 密钥和文件上传后端跑起来之前先改配置文件。项目一般把不同环境的配置拆成application-dev.yml、application-prod.yml本地默认读 dev。关键配置通常在数据源、Redis、日志三个位置先把这几项对齐自己的环境spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/sky_take_out?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf-8 username: root password: root redis: host: localhost port: 6379 database: 0 servlet: multipart: max-file-size: 10MB sky: jwt: admin-secret-key: skyadmin admin-ttl: 7200000 admin-token-name: token user-secret-key: skyuser user-ttl: 7200000 user-token-name: authentication数据源四项要改的是url里的库名、账号和密码。serverTimezoneAsia/Shanghai是为了避免日期时间差 8 小时这个参数建议保留。Redis 的database: 0表示使用第 0 个库如果本地 Redis 已经有其他业务数据可以改成 1 避免 key 冲突。JWT 配置分管理员端和用户端两套密钥不要用默认值。实际项目中我一般会生成两段随机字符串替换上去避免别人用公开资源的默认密钥直接伪造令牌。admin-ttl和user-ttl单位是毫秒如果改成 7200000就是 2 小时过期。文件上传大小限制10MB是 Spring MVC 的 multipart 配置搭建菜品图片上传时用到如果后续要传视频或大图可以按需调大但不能无限制调否则容易压垮本地内存。配置改完先别急着启动检查一下pom.xml里是否引入了spring-boot-configuration-processor否则 YAML 里的自定义前缀sky.jwt可能无法被 IDE 自动提示写错字段名也不报错只在运行时读取到 null这个后续排查起来很隐蔽。3.3 启动后端并用接口验证先证明服务是活的配置完成后启动方式分两种一种是用 IDEA 直接运行主启动类另一种是命令行 Maven 启动。如果工程是多模块结构在根目录执行mvn spring-boot:run -pl sky-server -am-pl sky-server表示只启动 server 模块-am表示同时构建它依赖的其他模块。如果没有-am单独启动 server 模块时经常报“找不到 sky-common 的类”这就是模块依赖没被构建进来的典型症状。如果工程只有一个后端模块直接运行主类即可。启动成功后先用一个真实接口验证服务是否活。管理端登录接口通常长这样curl -X POST http://localhost:8080/admin/employee/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}如果返回 JSON 里包含 token 字段说明数据库连接、密码加密、JWT 生成链路都正常。如果返回用户名为空或密码错误多半是数据库脚本没导入成功查一下employee表里是否有数据。这一步别跳过它能区分“代码问题”和“环境问题”。3.4 启动管理后台和用户端联调才是完整闭环后端接口通了再启动前端。管理后台一般是 Vue 工程常见命令是cd sky-take-out-web npm install npm run servenpm install如果很慢检查 npm 镜像源是不是默认的国外源换成国内镜像会快很多。npm run serve启动后默认端口通常是 8080 或 5173 附近打开浏览器看到登录页就正常。用户端小程序不是直接在浏览器里跑要按对应脚手架的构建命令先打包再把生成目录导入开发者工具预览。这一步最容易出错的是接口地址后端在本机启动小程序模拟器里写localhost会指向模拟器自己必须改成电脑的局域网 IP比如http://192.168.x.x:8080。管理后台一般有代理转发开发环境请求/api会自动转发到8080小程序没有这个机制得在请求封装文件里直接改 baseURL。联调验证的标准很简单管理后台能登录、能新增菜品分类小程序端能浏览菜品、加购物车、提交订单。走完这三步项目才算真正跑通后面改代码才有验证基准线。4. 实战改一处业务规则固定运费改成满减运费的前后端完整改动4.1 需求拆解先定规则再动表结构很多下载资源能跑起来但你不动它它就永远只是别人的代码。选一个最简单的业务规则改动练手最合适比如把配送费从“固定 6 元”改成“订单金额满 50 元免配送费否则收 6 元”。这个需求听着简单实际涉及三层改动。第一层是数据库确认orders表里有配送费字段如果没有需要补一个字段并加上默认值。第二层是后端下单时根据订单金额计算配送费并把配送费加进实付金额。第三层是前端结算页要展示配送费是免了还是收 6 元。先看数据库这层。通常orders表已经包含delivery_amount或delivery_fee字段如果字段名不统一先确认代码里用的是哪个。缺字段时补建ALTER TABLE orders ADD COLUMN delivery_fee DECIMAL(10,2) NOT NULL DEFAULT 6.00 COMMENT 配送费; ALTER TABLE orders ADD COLUMN pay_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 实付金额;这段 SQL 的意义是把配送费和实付金额显式落到表里而不是让前端算好再传。实付金额落库很重要否则后续对账时只能拿订单金额和配送费临时相加规则一变历史数据就失了准头。DECIMAL(10,2)的精度够外卖订单用十万以内的金额都不会溢位。4.2 后端改造在提交订单的服务里改计算规则后端核心改动点在订单提交服务里常见实现类名称类似OrderServiceImpl。先抽一个独立方法计算配送费让主流程干净一点private BigDecimal calculateDeliveryFee(BigDecimal orderAmount) { if (orderAmount null) { return new BigDecimal(6); } // 满 50 元免配送费否则固定 6 元 if (orderAmount.compareTo(new BigDecimal(50)) 0) { return BigDecimal.ZERO; } return new BigDecimal(6); }这段代码有两个细节必须注意。第一金额比较不能用符号BigDecimal是对象compareTo才是按数值大小比较equals会比较精度new BigDecimal(50).equals(new BigDecimal(50.0))返回 false这种坑光靠肉眼很难发现。第二订单金额为 null 时兜底收 6 元避免空指针导致下单接口直接 500。接下来在提交订单的主逻辑里调用BigDecimal orderAmount cartService.calculateCartAmount(cartList); order.setAmount(orderAmount); order.setDeliveryFee(calculateDeliveryFee(orderAmount)); order.setPayAmount(orderAmount.add(order.getDeliveryFee()));这里先算出订单里所有菜品的合计金额然后计算配送费最终实付金额是两者相加。要注意order.setAmount存的是商品总价不包含配送费pay_amount才是用户真正要支付的金额。很多人改到这里会把商品总价直接加上配送费再塞进amount导致对账时商品金额虚高属于逻辑错误。业务规则无论怎么改amount和pay_amount的语义拆分不要动。4.3 前端展示与联调边界值必须测三个点后端把配送费算好返回后前端结算页要展示这个字段。Vue 页面里一个小改动就能体现效果div classfee-row span配送费/span span{{ orderInfo.deliveryFee 0 ? 免运费 : ¥ orderInfo.deliveryFee }}/span /div这里不要在前端再写一遍“满 50 免运费”的判断逻辑直接展示后端返回的deliveryFee。前端只做展示规则以服务端为准否则以后活动规则变成满 80 免运费前端还得重新发版改造成本高还可能两端不同步。联调时边界值至少测三个订单金额 49.99 元应收 6 元运费50 元整应免运费50.01 元也应免运费。前后端配合测试时每个边界看结算页展示、订单表里的delivery_fee、实付金额三个地方的数值是否一致。如果订单表里已经存了 6 元但前端显示免运费说明改的接口和下单用的接口不是同一个这在大项目里非常常见要检查是否走错了 service 方法。5. 避坑排查苍穹外卖运行和改造中常见的五个翻车点5.1 启动报“Connection refused”但 MySQL 本地明明开着现象后端启动时控制台报错Cannot connect to MySQL server或Connection refused但用数据库客户端能正常连接。原因最常见的是application-dev.yml里的端口和本地 MySQL 不一致比如代码里写的是 3307本地装的 MySQL 跑在 3306。另一种可能是指定了错的数据库名比如配置里库名是sky_take_out但 SQL 脚本建出来的库叫sky_takeout。解决先不要看代码直接命令行连接一遍确认端口和库名再把配置文件里的url逐段复制到客户端工具里测试。顺手确认数据库字符集字符集不对时后续导中文数据也会出乱码。5.2 订单卡在“待付款”不动模拟支付没反应现象下单成功订单状态是待付款点模拟支付后前端提示成功但订单状态没变。原因模拟支付成功后会回调后端接口更新状态。回调地址往往配置成localhost在本地联调时用户能访问到但回调来源是模拟器或另一台设备请求根本打不到电脑上。另一个原因是支付回调接口的路径和配置里不一致。解决把支付回调地址改成电脑局域网 IP如http://192.168.1.100:8080/notify/paySuccess确保端口防火墙放行。然后在回调接口里打日志看请求到底有没有进来。如果日志里完全没有回调记录问题一定在网络地址或支付配置上不用去查订单状态逻辑。5.3 菜品图片裂了控制台也没有报错现象管理后台能正常上传菜品新增菜品成功后列表里有文字记录但图片位置是裂图。原因资源包自带的图片访问地址指向某个对象存储空间这套地址是原作者自己的别人访问不了或者上传功能配置的存储路径本地还没创建。解决先看图片 URL 指向哪。如果是外链改成自己申请的对象存储 Bucket 配置或者在后端加一层本地静态资源映射把上传的图片存进本地目录再通过/images/**映射到磁盘路径。如果是本地路径不存在创建目录并检查写权限。上传文件用相对路径不要用绝对路径避免换一台电脑就找不到目录。5.4 定时清理订单的任务到点没执行现象配置了每天凌晨 2 点清理超时订单到点去看数据库订单还是卡在待支付。原因大部分下载资源的定时任务不只是一个Scheduled注解还可能依赖中间件或调度平台。本地直接跑单体模块时调度注册不上或者启动类少了EnableScheduling注解导致所有定时任务都失效。解决先在启动类上确认有EnableScheduling没有就补上。有的话再看日志里启动时是否打印了 Scheduled 任务的注册记录。如果项目里集成了调度平台检查本地是否配置了对应的执行器地址最简单的方式是把任务入口改成Scheduled并临时把执行频率调成每分钟一次验证逻辑能跑通再改回生产时间。5.5 前端拿到的字段总是 undefined后端返回却是正常的现象postman 调接口能看到字段前端页面显示undefined或者空白。原因前后端字段大小写不一致。比如后端实体类属性是deliveryFee前端用了delivery_fee或者后端 VO 里没有这个字段返回时被序列化忽略前端拿到的对象里不存在这个 key。解决打开浏览器开发者工具的 Network 面板直接看接口返回的原始 JSON。如果原始 JSON 里有该字段问题在前端取值如果原始 JSON 里根本没有问题在后端 VO。统一采用驼峰命名不要一部分用下划线一部分用驼峰。另外检查 getter 是否存在实体类属性若没有 getterJackson 会直接跳过序列化这是个隐蔽坑。6. 进阶调试用 Postman 串起整条下单链路再靠日志反向补齐业务盲区6.1 用 Postman 自动携带 Token按真实顺序跑一遍订单流程项目能跑通、改过逻辑之后下一步是把接口链路串起来验证。通用做法是把登录和下单流程拆成一串 Postman 请求用环境变量传递 Token而不是每次手动复制。登录接口返回 Token 后在 Tests 标签页写入脚本// 登录成功后把 token 存进环境变量 const json pm.response.json(); if (json.code 1) { pm.environment.set(adminToken, json.data.token); } pm.expect(json.code).eq(1);后续需要鉴权的请求里在 Pre-request Script 中动态写入请求头// 从环境变量读取 token 并注入请求头 pm.request.headers.add({ key: token, value: pm.environment.get(adminToken) });这样设计的好处是更换账号时只需要改登录请求的 body所有后续接口自动生效。用户端和管理端的 Token 不能混用这算一个容易忽略的点管理员能访问的接口和普通用户能访问的接口是两套权限体系联调下单流程时要用用户的登录接口获取 userToken否则接口返回权限不足。建议把请求按业务顺序放进同一个文件夹用户登录、查看分类、查看菜品、加购物车、提交订单、模拟支付、查询订单状态。每跑完一步看一眼返回数据和数据库记录确认不是“接口返回 200 但状态没变”。6.2 打开 SQL 日志观察事务回滚和慢查询Postman 验证的是接口产出日志验证的是 SQL 执行过程。建议在开发配置里打开 MyBatis 的 SQL 日志logging: level: com.sky.mapper: debug这个配置会把每个 mapper 方法最终执行的 SQL 和参数值都打印出来。调试配送费规则时可以通过日志确认 INSERT 订单的 SQL 中delivery_fee字段是否为 0也可以看到数据库连接是否在同一个事务里提交。事务回滚的日志标志是Rolling back transaction。一旦出现回滚往前翻最后几条 SQL基本就能锁定是哪个表的更新触发了异常。常见情况是更新订单明细时某条数据因唯一索引冲突失败导致整个下单链路回滚。这个定位习惯在改代码时很有用直接看最后一条 SQL比断点调试快得多。从那以后我每拿到一套外卖类教学资源都会强制走一遍“改配置、跑通接口、改一个字段、查一次日志”的循环。第一次跑订单链路时我发现修改运费后前端展示正确、后端存储正确但支付金额没同步最后在日志里才发现实付金额是在下单之后才计算导致数据不一致。这种问题只看代码很难注意到非得把整条链路跑完才现原形。希望这套步骤能让你避掉同样的坑真正把资源变成自己能掌控的代码。本文还有配套的精品资源点击获取