开发历程与演进记录
本页专门回答一个很实际的问题：这个项目是怎么一步步长出来的，它和最初的教学起点到底是什么关系？
0. 先把最关键的话说清楚
SmartLive 的起点，确实来自 黑马点评 的教学代码与课程实践。
这件事我更愿意在文档和面试里主动说明，而不是回避。
原因很简单：
- 教学项目是起点，不是终点：它帮助我快速建立了本地生活业务、缓存、热榜、秒杀、MQ 等基础认知。
- 真正的难点在后续系统性扩展：要把一个教学演示项目，扩展成一个能覆盖用户端、商家端、平台管理端、AI、IM、审核治理和完整文档资产的平台级系统，靠的不是“照着抄”，而是持续的业务建模、边界拆分、代码重构和工程沉淀。
- 这页的重点不是“证明我从零空白起步”：而是诚实说明这个项目从哪里开始、经历了什么阶段、最终长成了什么样子。
如果面试官问“这是不是基于黑马点评做的”，最稳的回答其实是：
是，项目起步于黑马点评的教学地基；但后续围绕服务拆分、交易闭环、商家端、平台治理、AI、IM、审核治理和完整文档站做了系统性扩展，当前版本已经不是原教学项目的能力边界。
1. 从起点到当前版本：最重要的演进差异
| 维度 | 起点（黑马点评教学代码） | SmartLive 智评生活（当前版本） |
|---|---|---|
| 定位 | 教学演示项目 | 面向本地生活场景的完整业务闭环平台 |
| 服务形态 | 偏教学型单体 / 局部拆分 | 19 个独立服务应用协同 |
| 业务模块 | 围绕少量核心交易与互动模块展开 | 16 个业务模块，覆盖交易、内容、社交、AI、治理、资产等完整域 |
| 前端覆盖 | 无或仅单端演示 | 用户端 App / H5 + 商家端 Web + 平台管理端 Web |
| AI 能力 | 无 | 用户侧问答 / 生成 + 商家侧经营助手 + 业务数据型 RAG |
| IM 模块 | 无 | Netty 长连接 + Chat 落库 + MQ 广播双通道 |
| 审核治理 | 无完整治理体系 | 覆盖 用户 / 店铺 / 博客 / 商品 / 评论 / 评价 的 6 类审核链 |
| 调度补偿 | 基础或弱依赖调度 | 26 个 @XxlJob 处理器，形成提醒、补偿、修正和批处理闭环 |
| 数据模型 | 更偏教学型核心表 | 53 张核心表、8 个数据域 |
| 文档资产 | 无完整在线文档体系 | 73 张链路图、102 张截图、11 篇专题页、在线文档站 |
如果只看“起点”，这个项目并不特殊；真正让它变得有价值的，是后续把边界不断补齐，最后形成了完整的平台级版本。
2. 为什么我决定继续做，而不是停在教学版本
跟完教学项目之后，我很快意识到几个问题：
- 它可以很好地解释某几个技术点，但很难支撑“完整系统”的讲法。
- 它没有完整的商家侧和平台治理侧，业务角色不够完整。
- 它没有 IM、AI、审核中心、经营分析、完整部署文档这类更接近真实系统的能力。
- 很多链路只完成了“功能演示”，还没有继续沉淀到“补偿、治理、答辩表达和开源接入”这一层。
所以后续我没有把它当作“课程结束后的成品”，而是把它当作一个可继续扩展的业务地基：
- 先把用户端主链路补全
- 再把商家端和平台管理端做出来
- 再把 AI、IM、审核、调度、文档站这些差异化能力补齐
- 最后把它整理成可阅读、可答辩、可开源接入的一体化资料
3. 这 6 个月大致是怎么长出来的
下面这条时间线是按仓库实际提交节奏做的粗粒度归纳，更适合面试时讲“项目演进”，而不是背模块名。
| 阶段 | 时间 | 主要工作 | 对外最值得怎么讲 |
|---|---|---|---|
| 第 1 阶段 | 2025.10 | 初始化仓库，打通登录、首页、地图、搜索、私信与 AI 评论 / 下单雏形 | 先证明项目从一开始就不是单接口练习，而是在做完整用户侧闭环 |
| 第 2 阶段 | 2025.11 | 引入 RabbitMQ、死信队列、线程池、ES 同步和首页聚合能力 | 这一步开始从“能跑”进入“能异步解耦、能削峰、能同步副本” |
| 第 3 阶段 | 2025.12 | 整理互动域，统一点赞 / 收藏 / 评论 / 关注策略模式，升级到 Boot 3.2.2，并把 AI 工程并回主仓库 | 这一步最适合讲“从堆功能转向做结构化抽象” |
| 第 4 阶段 | 2026.01 | 重构 Netty IM，补代金券、订单、动态推送、审核中心初版，统一 DTO / 返回结构 | 这一步最适合讲“开始做跨服务协同和业务骨架收束” |
| 第 5 阶段 | 2026.02 | 深化 AI 会话与审核链路，重构缓存体系、评论评价系统、XXL-JOB 同步、热榜与搜索策略 | 这一步最适合讲“系统从单链路扩展成多链路协同” |
| 第 6 阶段 | 2026.03 | 完成订单过期与自动退款、MQ 幂等与重试补偿、商家 AI 助手，并集中建设文档站、链路图和页面导览 | 这一步最适合讲“把项目从能做完推进到能讲清楚、能开源、能答辩” |
如果把这 6 个月压成一句话，我会这样概括：
前 2 个月搭主链和中间件底座，中间 2 个月做边界拆分和结构抽象，最后 2 个月补齐 AI、补偿、治理和文档资产。
4. 这条演进线上，最值得讲的 4 个转折点
4.1 从“做页面和接口”转到“做业务闭环”
真正有价值的变化，不是多写几个页面，而是把：
- 登录
- 发现
- 搜索
- 下单
- 支付
- 退款
- 评价
- 社交
- 商家经营
- 平台治理
这些原本分散的点，串成同一个平台里的闭环。
4.2 从“会用中间件”转到“会设计协同关系”
项目后期最重要的成长，不是我会不会背 Redis、MQ、ES、Milvus 的概念，而是开始能回答：
- 为什么这里该走缓存，那里该走异步
- 为什么这个场景适合最终一致性，而不是重事务
- 为什么搜索和向量库必须异步同步
- 为什么 IM 要拆成实时推送和消息持久化双通道
4.3 从“模块很多”转到“边界讲得清楚”
一个系统能不能拿去面试讲，很大程度上取决于你能不能讲清：
- 模块为什么这么拆
- 调用关系为什么这么设计
- 数据为什么这么建模
- 哪些链路最值得讲
这也是我后来不断补页面导览、链路图、数据模型页和 FAQ 的原因。
4.4 从“有代码”转到“有完整可验证资产”
现在这个项目真正能支撑答辩和求职，不只是因为代码量大，而是因为它已经沉淀了：
16 个业务模块19 个服务应用53 张核心表18 个@FeignClient30 个@RabbitListener26 个@XxlJob73 张链路图102 张截图11 篇专题页
这些资产共同构成了“可验证性”。
5. 如果面试官问：你怎么证明这个项目不是拼出来的
我建议按下面这个逻辑答：
- 先承认起点
- 项目确实起步于黑马点评教学代码，这是我建立业务认知的地基。
- 再讲演进跨度
- 当前版本已经扩展出商家端、平台管理端、AI、IM、审核治理、订单过期自动退款、完整文档站等能力，边界远超原始教学内容。
- 最后给可验证证据
- 让对方去看页面导览、核心链路、系统架构、数据模型和 Git 提交记录，而不是只听口头描述。
一句话版本可以这样讲：
我不回避项目起点来自教学代码，但我真正想证明的是：我有能力识别原始系统边界，并围绕它做持续的服务拆分、业务扩展、工程重构和文档沉淀，最终把它演进成一个完整平台。
6. 这页最适合怎么用
- 项目介绍场景：先讲“起点 vs 当前版本”这张表，快速建立真实感。
- 面试追问真实性场景：直接讲 6 个月时间线和 4 个关键转折点。
- 复盘场景：把这页和 项目沉淀与学习复盘 放在一起看，一页讲“怎么长出来”，一页讲“最后沉淀了什么”。