学了八个多月 Java，SSM、Spring Boot 这些框架跟着视频敲了个遍，但说实话，每次别人问我“你做过什么项目”，我都底气不足。大学里的课设是个图书管理系统，代码量摆在那，自己都嫌薄。纠结了一阵子之后，我终于决定找个完整的、能写进简历的实战项目来啃，选来选去，盯上了“苍穹外卖”。
这套项目在 Java 学习圈里名气不小，是一套前后端分离的外卖点餐系统，覆盖管理端和客户端两端。管理端管分类、菜品、套餐、订单、数据统计，客户端是微信小程序，用户可以登录、点餐、下单、支付。技术栈基本踩在主流框架上，Spring Boot + MyBatis + MySQL + Redis，外加 JWT、Spring Cache、WebSocket 这些常见组件，正好把我零散学的东西串成一条线。
这篇日记我打算如实记录第一天的经历，包括我怎么把项目跑起来、怎么读它的代码结构、踩了哪些坑、以及我制定的学习复盘标准。如果你也是刚学完框架、正在找第一个完整项目练手的人，这篇应该能帮你少走点弯路。
1. 为什么挑“苍穹外卖”，而不是自己从零写个外卖系统
1.1 完整闭环和零散教程之间差着一整条业务线
我之前写过的练习项目，大多是“单表 CRUD”的程度：一个 Controller、一个 Service、一个 Mapper，对着数据库里一张表做增删改查。但在苍穹外卖里，一个点餐动作牵扯到用户认证、菜品缓存、购物车、下单、支付回调、订单状态流转、来单提醒，最后还要进统计报表。整个链路是闭合的，很多设计是零散教程根本不会讲到的。
就拿“菜品展示”这一块来说，客户端首页要显示分类和菜品，直接查数据库当然也能做，但项目里用了缓存策略：先把数据加载进 Redis，后续请求直接读缓存，减少数据库压力。这背后就涉及缓存更新时机、key 的设计、数据库和缓存一致性问题。自己从零写系统，大概率不会主动考虑这些；但跟项目学，就能看到别人是怎么在真实场景里做取舍的。
1.2 技术栈正好覆盖招聘 JD 上的常见要求
我翻了不少初级 Java 岗位的招聘要求，出镜率最高的就是 Spring Boot、MyBatis、MySQL、Redis，偶尔会提 Spring Cloud、消息队列。苍穹外卖这套老版本包含 Spring Cloud 微服务版，新教程也有单体架构版本。我拿到的这套是单体版，但业务完整度没打折。单体架构对初学者反而友好，不用一上来就拉扯一堆微服务中间件，能把核心业务逻辑吃透。
我整理了一下这套项目的模块和我们学的技术点对应关系：
| 项目功能模块 | 涉及的主要技术点 | 我第一天的关注程度 |
|---|---|---|
| 管理端登录认证 | JWT 生成与校验、拦截器、ThreadLocal | 重点读代码 |
| 菜品/套餐管理 | MyBatis 分页查询、文件上传、Redis 缓存 | 先跑通再深挖 |
| 客户端微信登录 | 微信小程序登录流程、HTTP 调用 | 了解为主 |
| 购物车与下单 | 事务管理、多表关联操作 | 重点理解事务边界 |
| 订单支付回调 | 支付回调接口、状态机流转 | 后续重点复盘 |
| 来单/催单提醒 | WebSocket 实时通信 | 新鲜，标记待读 |
| 数据统计 | ECharts 报表、时间区间查询 | 知道方向即可 |
这个清单我直接打在笔记里，后面每一篇日记对一项。相比漫无目的看源码，这种带目标的学习方式效率高很多。
1.3 有现成源码不等于让你照着抄
我给自己定了个规矩：坚决不直接抄源码提交。项目视频和源码是学习材料，不是作业答案。别人的代码可以帮助我理解设计模式、业务边界、异常处理方式，但如果我提交到简历上的是 CV 出来的代码，面试官随便问几个为什么就穿帮了。
所以第一天我做的第一件事就是——把源码当课本读，把启动过程当实验做，把踩坑经历当笔记写。
2. 第一天实操：从环境准备到项目成功启动
2.1 我列出的环境清单，照着配就行
第一步先把环境对齐。这套项目虽然整体不挑机器，但版本差异会引出各种诡异报错。我的本地环境是这样的：
| 软件 | 我用的版本 | 备注 |
|---|---|---|
| JDK | 1.8 | 项目编译目标版本，别一上来用 17/21 |
| Maven | 3.6.3 | 太高的 3.9.x 暂时不用，避免插件兼容问题 |
| MySQL | 5.7 | 5.7 和 8.0 都行，但导入脚本时要注意默认字符集 |
| Redis | 3.2.100（Windows 版） | Windows 老版本网上很多，但启动方式要单独处理 |
| Node.js | 14.x | 前端依赖安装需要，新版本可能导致 node-sass 安装失败 |
| 开发工具 | IDEA 2022+ | 需要安装 Lombok 插件 |
这里最容易被忽略的是 JDK 和 Node 版本。好多人项目启动不起来，不是代码问题，而是本机 JDK 版本过高，依赖里的旧版字节码处理库不兼容，直接抛异常。Node 更坑，教程里写npm install，你用 Node 18 去装老项目的 node-sass，会下载二进制失败，卡半小时找不到原因。
2.2 启动的先后顺序，真的不能乱
我整理了一条启动顺序，后面照这个跑基本稳：
- 初始化数据库：执行项目配套的
sky.sql脚本。这个脚本建库建表，并且会插入一批初始数据，否则管理端登录进去没有分类和菜品可以看。 - 启动 Redis：项目运行中管理端登录、菜品缓存、购物车都会用到 Redis。Redis 没起来，项目能启动，但一登录就报错。
- 启动后端服务：改完
application.yml里的数据库账号密码，直接启动主类。看到 Tomcat 端口（默认 8080）起来就说明后端通了。 - 启动管理端前端：前端是 Vue 项目，先
npm install，再npm run serve。访问localhost:9528就能看到管理后台登录页。 - 启动客户端（微信小程序）：用微信开发者工具导入
sky-take-out-frontend目录，填入自己的 AppID（没有的话选测试号也能体验大部分功能）。
我第一次跑的时候自作聪明，想着“后端启动慢，先启动前端”，结果前端页面白屏，控制台一串跨域和 404 报错。后来才反应过来，管理端页面登录请求要打到本地后端，后端都没起来，前端页面拿不到任何数据。前后端联调的项目，后端必须先于前端就位。
2.3 登录进去看到的第一个界面
管理端默认账号是配置文件里写好的，通常有一个管理员账号admin，密码初始值一般也在文档里或者配置文件注释里标注。我记得当时登录进去，看到左侧菜单上有工作台、分类管理、菜品管理、套餐管理、订单管理、数据统计这些模块，心里才踏实下来：这确实是一个“能完整跑起来”的项目，不是教程里只讲了一部分的半成品。
把项目跑通这一刻，其实已经比很多下载完源码就丢在桌面吃灰的人走得远了。接下来的时间，我才开始真正啃代码。
3. 当天最折腾我的三个坑，完整排查链路分享
3.1 启动直接秒退：JDK 版本不一致导致 Lua 脚本加载崩了
第一个报错出现在后端启动阶段，日志里提到了 Redis 的 Lua 脚本相关异常。我第一反应是“Redis 脚本问题”，赶紧去看 Redis 配置，折腾了半天发现和 Redis 本身没关系。
后来无意间用java -version看了一眼，发现自己默认 JDK 是 17，而教程推荐的是 JDK 8。项目里用到的某个依赖对 JDK 版本敏感，在 17 下直接加载异常。解决方式很简单：把 IDEA 的 Project Structure 和全局 JDK 都切回 1.8，再刷新 Maven 重新编译启动，服务秒起。
这个坑属于“版本环境坑”，特点是报错信息跟真正原因隔得很远。它给我的经验是：遇到启动报错先别急着改代码，先检查三件套——JDK 版本、Maven 版本、依赖是否完整。很多时候问题出在这三层。
3.2 Windows 下 Redis 启动没反应
第二坑是 Redis。我第一次双击redis-server.exe，窗口一闪而过，后面再试也没有反应，后端日志不断提示Unable to connect to Redis。
排查过程是这样的：
- 先确认端口有没有被占用：
netstat -ano | findstr 6379，结果没有进程在监听； - 再尝试命令行启动：
redis-server.exe redis.windows.conf，这次看到一个报错提示，说配置里的日志路径或工作目录有问题； - 检查
redis.windows.conf，把logfile路径改成当前目录下的相对路径，把dir配置调整好，重新启动，一切正常。
这个坑提醒我：Windows 下 Redis 的老版本确实很敏感，配置文件里默认路径放在 Linux 习惯的位置，到 Windows 上不存在就会启动失败。所以不要双击 exe 就觉得它启动了，终端输出才是真实的启动状态。
3.3 npm install 卡死在前端依赖上
前端项目的依赖安装是另一座山。我用 Node 18 执行npm install，等了几分钟，最后报错node-sass安装失败。
原因是：老项目里node-sass版本比较旧，在 Node 18 上只能下载源码然后本机编译，而编译又依赖 Python 和 Visual Studio 构建工具，我本机根本没装全套。与其去补编译环境，不如换思路：
nvm install 14.17.0 nvm use 14.17.0 rm -rf node_modules package-lock.json npm install --registry=https://registry.npmmirror.com用 nvm 切到 Node 14 之后，node-sass直接走预编译二进制，几十秒就装完了。如果你没装 nvm，我强烈建议装一个，前后端项目多了，Node 版本来回切换是家常便饭。
从这三个坑能看到一个共性：多数启动失败不是代码的锅，而是本机环境和项目假定环境不一致。所以拿到任何开源项目，第一步永远是看它的环境说明和版本要求，这比急着看代码重要得多。
4. 启动成功后，我把登录功能当成“请求链路解剖课”
4.1 一个登录请求到底是怎么走完的
项目能跑起来只是热身，真正开始学习是在代码阅读阶段。我选了登录功能下手，因为它是理解整个后端架构的最短路径。
我看到管理端登录的 Controller 接收前端传过来的用户名和密码，然后调 Service。Service 里做这几件事：
- 根据用户名查数据库，拿到用户实体；
- 比对密码（项目里用了 BCrypt 或者 MD5 加密，具体看版本）；
- 登录成功后，用 JWT 生成一个 token；
- 返回给前端，前端存起来，后续请求带上这个 token 访问接口。
这个流程单看并不复杂，但配合源码能看出一个关键设计：为什么用 JWT 而不用 Session？因为这套项目除了管理后台，还有微信小程序端，两个端共享后端服务，如果用 Session 维护登录态，就得处理跨域携带 Cookie 的问题，还要考虑分布式环境下 Session 不共享的问题。JWT 是无状态的，后端不需要存储会话，只需要在每次请求时核验签名。想明白这一点，再去看 JWT 工具类里的parseToken方法，代码就通了。
4.2 拦截器和 ThreadLocal：一个我一开始没看懂的设计
再看请求进来之后的处理，我发现并不是每个 Controller 方法里都写了解析 token 的逻辑。项目用一个拦截器统一处理：请求先被拦截器拦住，拦截器取出请求头里的 token，校验通过之后放行，否则直接返回 401。这个设计叫“拦截器 + 上下文存储”。
让我一开始没看懂的是 ThreadLocal。代码里有一个BaseContext类，里面是一个ThreadLocal<Long>，用来存当前登录用户的 ID。Service 层创建订单、更新数据的时候，直接从BaseContext.getCurrentId()拿当前用户 ID，不需要在 Controller 方法里把用户 ID 当一个参数传来传去。
这有什么用？我当时的理解是省事，后来才意识到更重要的是：它让“当前操作者是谁”这个信息在整个请求链路里随处可用，不必污染每个方法的参数列表，而且线程隔离天然保证了一个请求的数据不会串到另一个请求。
但是用 ThreadLocal 有个必须做干净的事：请求结束要 remove。如果线程池复用了线程，不清理的话，下一次请求很可能读到上一个请求留下的用户 ID。这个 bug 一旦出现非常隐蔽，好在项目源码里已经处理了，这也让我记住了 ThreadLocal 的正确用法。
4.3 为什么第一天就该搞懂这条链路
我见过不少人项目跑起来之后直接看 CRUD 页面怎么增删改查，把后端 Controller 里几行代码抄一遍就算学完了。但我觉得如果一开始就把请求链路理解清楚，后面看任何模块都会很快，因为你见的不是“零散的代码片段”，而是一个“请求从进到出的完整骨架”。
骨架理解了，看菜品管理、订单管理，无非是在这个骨架上挂新的业务逻辑、新的表、新的校验规则而已。所以我把登录链路画在了笔记里（手画的，没画时序图工具），包括前端请求、拦截器、Controller、Service、Mapper、数据库每一层分别做了什么。这张图会一直伴随着我后续的学习。
5. 第一天的学习复盘：怎么判断自己“真学会”了，还是只是“看懂了”
5.1 我给自己定的三条“真学会”标准
读完登录模块的代码，我合上电脑问自己：如果让我现在自己写一个带 JWT 登录的后端接口，我能写完吗？答案是不一定能直接写对，因为里面有不少细节我还没动手敲。
所以我给自己定了三条判断标准，配套到每一块功能上：
- 不看源码能画出流程图：前端哪个按钮、调哪个接口、后端哪个类处理、查了哪几张表、最终返回什么结构；
- 不看源码能复写核心代码：比如 JWT 的生成与拦截器校验，这部分我要求自己能够默写出来，理解每个注解和参数的含义；
- 能回答“为什么这样设计”：为什么用缓存、为什么用枚举、为什么状态字段用 Integer 而不是 String。回答不了，说明还没吃透。
这三条标准直接影响了第一天的学习节奏：我没有急着去下一个模块，而是把登录功能相关的代码重新读了一遍，照着源码自己敲了个简化版。简化版里我没有管微信登录，只实现了“用户名密码登录 + JWT + 拦截器 + ThreadLocal”，敲完全程用了大概一个小时。虽然敲的时候频繁翻源码，但至少我迈出了从“看别人代码”到“自己组织代码”的第一步。
5.2 接下来的规划：带着问题进入菜品模块
苍穹外卖的功能模块很多，贪多嚼不烂。我给自己排的下一步是菜品管理模块，主要问题是这几个：
- 文件上传是怎么处理的？本地存储和云端存储各自优缺点是什么？
- Redis 缓存菜品数据，更新菜品后缓存是怎么清除的？
- 分类和菜品是多对一关系，MyBatis 里怎么设计的关联查询？
- 管理端和客户端看同一份菜品数据，接口为什么分成两套？
这些问题我写在了笔记末尾，下一篇学习日记我会围绕它们来写，而不是按视频集数一集集往下看。带着问题去读代码，比被动地跟着视频点鼠标更容易留下深刻印象。
最后再分享一个当天的小习惯，我觉得挺管用的：我会在 IDEA 里给关键类都加上书签，项目启动成功后第一件事不是乱逛，而是把骨架类过一遍。这样后面读到任何模块，我都能第一时间定位到它挂在哪个大类下面。苍穹外卖这种项目体量不小，早点建立代码地图，后面几十天学下来才不容易迷路。
