0. 前言：深夜的 Bug 与崩溃的边缘

凌晨两点，窗外蝉鸣阵阵，你的 IDE 控制台却在一遍遍刷新着报错。

“为什么 Redis 的缓存总是不一致？”
“明明配置了 JWT，为什么拦截器还是报 401？”
“订单状态流转的逻辑，怎么写才能优雅而不像屎山？”

很多开发者在接触苍穹外卖这类企业级项目时，往往会被其复杂的业务流和嵌套的架构搞得头晕脑胀。这篇文章，就是为了终结你的痛苦。我们不只聊 How（怎么做），更要深挖 Why（为什么这么设计）。

1. 系统整体架构：拒绝“草台班子”

苍穹外卖不是一个简单的 CRUD Demo，它采用了标准的企业级分层架构。

1.1 技术栈概览

1.2 核心业务流程

2. 核心技术痛点剖析（避坑指南）

2.1 鉴权体系：JWT 与拦截器的爱恨情仇

痛点：
在多端（用户端、管理端）并存时，如何优雅地处理身份校验？

底层逻辑：
项目利用 Spring MVC 的 HandlerInterceptor。关键点在于 ThreadLocal 的使用。

关键点：
在拦截器中解析 JWT 获得 userId 后，必须存入 BaseContext（包装了 ThreadLocal），确保在同一个线程的 Service 层能直接获取当前操作人 ID。

2.2 数据脱敏与公共字段自动填充

重复在每个 SQL 里写 update_time 和 update_user 是极其低效的。

解决方案：
使用 AOP（面向切面编程） + 自定义注解 加粗样式@AutoFill。

避坑：
反射赋值时，要注意属性名必须严格匹配，否则会抛出 NoSuchMethodException。

3. 性能优化：如何让系统“跑”得更快？

3.1 Redis 缓存策略

对于高频访问的菜品和套餐，频繁查询数据库会导致连接池枯竭。

优化思路：

读操作：
先查 Redis，命中则返回；未命中查数据库并回写 Redis。

写操作：
数据变更时，必须保证数据一致性。项目采取的是“修改数据后直接清理对应 Key”的策略。

3.2 报表统计：POI 的性能考量

当需要导出运营报表时，大批量数据的循环会导致 OOM。

面试加分项：
在处理大数据量导出时，建议使用 SXSSF 代替 HSSF/XSSF，利用磁盘空间换内存，防止系统崩溃。

4. 底层逻辑分析：Spring 事务失效的真相

在处理订单提交这类核心业务时，@Transactional 是必加的。但你是否遇到过事务不回滚的情况？

检查点 1：
异常类型是否被捕捉？默认只回滚 RuntimeException。建议配置 @Transactional(rollbackFor = Exception.class)。

检查点 2：
方法是否是 public 的？

检查点 3：
是否存在类内部调用？（同类内 A 方法调用加了事务的 B 方法，事务会失效）。

5. 面试加分项：你可以这样聊苍穹外卖

如果你在面试中只说“我写了个外卖系统”，那只能拿 60 分。试着这样说：

• 关于并发： “我在处理订单支付回调时，通过数据库唯一索引配合分布式锁（或状态机检查）确保了幂等性，防止重复处理回调。”

• 关于解耦：“在系统解耦上，虽然本项目使用了简单的 HttpClient，但在实际生产环境，我会建议引入 消息队列 处理接单提醒，实现流量削峰。”

6. 总结与每日一思

苍穹外卖不仅是一个 Spring Boot 项目，更是一套企业级工程化思路的缩影。

核心结论：
技术不是为了炫技，而是为了支撑业务。理解了 ThreadLocal、AOP 和缓存一致性，你就掌握了该项目的灵魂。

每日一思：
如果你要给苍穹外卖增加一个“秒杀套餐”功能，你会如何设计其高并发下的下单逻辑？欢迎在评论区留下你的方案！

如果你觉得这篇文章对你有帮助，欢迎：

点赞 👍（据说点赞的人 Bug 越改越少）

关注 ➕（第一时间获取更多企业级项目深度解析）

收藏 ⭐（存进你的面试通关秘籍库）

你的支持是我更新的最大动力！