项目沉淀与学习复盘

本页作为网站详细版页面维护，集中承接项目沉淀、工程复盘、学习路径与成长总结。

开发者说明：这个项目是怎么一步步长出来的

这个项目的起点，来自 黑马点评 的教学代码与课程实践。我更愿意在文档和面试里主动把这件事说清楚，而不是把它包装成一个“完全凭空起步”的项目。

原因其实很简单：

• 教学项目是一个很好的起点：它让我快速建立了本地生活业务、缓存、秒杀、MQ、热榜这些基础认知。
• 但教学项目不是终点：如果要把它做成一个真正能拿去讲“系统设计与工程能力”的项目，就必须继续补齐用户侧完整闭环、商家端后台、平台治理、AI、IM、审核中心、文档资产这些能力。
• 我的真实投入在后半程：SmartLive 不是“照着教学项目抄完就结束”，而是在此基础上持续做业务扩展、服务拆分、工程重构和文档沉淀，最后才演进成现在这个版本。

如果让我用一句话总结这段经历，我会这样讲：

这个项目起步于黑马点评的教学地基，但真正体现我能力的部分，是我如何识别原有系统边界、重新定义模块职责，并把它逐步扩展成一个同时具备用户端、商家端、平台管理端、AI、IM、审核治理与完整文档资产的平台级项目。

0. 先看这个项目最终沉淀下来了什么

如果把这 6 个月的投入压成最关键的沉淀，我认为不是“学会了很多技术名词”，而是沉淀下来了这些真实资产：

• 16 个业务模块、19 个服务应用，已经形成完整的平台级系统
• 831 个 Java 文件、71 个 Controller，说明项目已经不再是轻量 Demo
• 18 个 @FeignClient、30 个 @RabbitListener、26 个 @XxlJob，说明微服务协同、消息可靠性和调度补偿都进入了主链路
• 73 张链路图、102 张截图、11 篇专题页，说明不仅有代码，还有可复盘、可答辩、可开源表达的文档资产
• 223 条 Git 提交记录，能看出项目不是一次性堆出来，而是持续迭代长出来的

所以这页真正想回答的是： 这个项目最后让我学会了什么、删掉了什么、又真正沉淀下来了什么。

1. 架构设计维度

• 从 0 到 1 的微服务边界设计：如何把 16 个业务模块拆清楚，同时让 19 个服务应用保持高内聚、低耦合，避免重新长成大泥球
• 缓存架构的演进，不是“一层 Redis”就结束：从详情缓存，到列表缓存、计数缓存、热榜缓存，再到滚动分页与 Geo 检索，开始真正理解“缓存也是数据模型的一部分”
• 异步解耦要有完整闭环：RabbitMQ 不是只负责“发消息”，还必须和 Confirm、Return、幂等、ACK/NACK、死信队列、XXL-JOB 补偿一起看
• 分布式一致性不是非黑即白：多数互联网业务更适合最终一致性；只有资金、退款、券状态这类场景才值得进一步引入强一致能力

2. 代码设计维度

• YAGNI 原则的正确实践：何时该抽象，何时该删掉抽象，比“会不会用设计模式”更重要
• 策略 + 工厂模式的组合价值：互动模块最终形成了 Like / Star / Follow / Review / Comment / Resource / HotRank 多套策略工厂，把公共流程沉到抽象层，把业务差异留在具体策略里
• 模板方法模式的复用价值：像 AbstractInteractionStrategy 这类抽象，不是为了写得花哨，而是为了把 MQ 投递、用户资源同步、日志和异常收敛到一处
• 真正的成长不是“抽象更多”，而是“敢删掉无意义抽象”：项目做大之后，越来越能体会“少一层无用封装，本身就是代码质量”

3. 高并发处理维度

• 秒杀场景的“超卖”与“少卖”治理：Redis Lua 原子校验 + RabbitMQ 延迟补偿，才构成完整闭环
• 缓存三大难题要落到实际数据结构上：穿透、击穿、雪崩不是八股答案，真正难的是什么时候该用 String、什么时候该用 ZSet、什么时候该接受短暂脏数据
• 分布式锁不是“加上就完了”：从简单锁思路，到 RedissonClient 的工程化接入，再到与业务状态机配合，才算真的理解它
• 削峰的艺术在于边界前移：秒杀链路真正的价值不是“用了 Lua”，而是把大量无效流量挡在 DB 之前

4. AI / 向量检索维度

• RAG 不是单点问答，而是业务能力增强：项目里的 AI 同时覆盖了用户端问答、博客生成、评价生成，以及商家端回复、分析、营销建议
• 向量检索不是“接个 Milvus”就结束：真正要考虑的是四类向量空间如何拆分、同步消息如何路由、Milvus 不可用时如何降级到 SimpleVectorStore
• Agent 路由设计要服从业务复杂度：当前更适合的是 意图分类 + AgentRouter + 框架路由，而不是一上来就堆复杂多 Agent 方案
• 提示词工程和上下文控制是真正的工程问题：同一个模型，Prompt、上下文裁剪、历史会话和工具调用顺序不同，结果会差很多

5. 工程化实践维度

• 脚本化与容器化的价值，不在“炫技”，而在“减少接入摩擦”：bin/、docker/、docker-compose-infra.yml、docker-compose-java.yml 这些资产，核心价值是把本地联调和演示部署标准化
• 完整 Git 历史的价值非常大：223 条提交不只是数字，而是你的思考轨迹、重构节奏和问题修复过程
• 文档是工程资产，不是展示附件：73 张链路图、102 张截图、11 篇专题页，本质上是在把代码里的设计决策显性化
• 单人项目越做越大，越需要“给未来的自己交接”：很多文档、命名和注释，并不是写给别人，而是写给几周后的自己

6. 产品思维维度

• 性能优化不等于堆技术：很多性能提升最后都回到对业务读写模式的理解，而不是多上一个中间件
• 功能完整性比单点亮点更重要：登录、首页、搜索、下单、支付、退款、评价、审核、AI，这些闭环都通了，项目才像一个产品
• 用户体验细节往往最体现工程判断：Feed 滚动分页、临期提醒、到期未使用自动退款、聊天会话同步，这些都不是“锦上添花”

7. 测试与故障定位维度

• 最重要的学习之一，是意识到“没有测试也是一种现状”：当前仓库 Java 测试文件 = 0，这不是优点，但它让我更明确后续应该优先补哪些链路测试
• 核心链路越靠近“钱、库存、状态”越要优先补测试：下单、支付、退款、核销、审核回写这些路径，出了问题影响最大，不能只靠手点验证
• 分布式问题不能靠猜，要靠链路证据：关键消息体、业务主键、死信单据、补偿日志、定时任务执行记录，都应该成为排查入口
• 先缩小问题空间，再修问题本身：线上问题首先要判断是缓存、MQ、数据库、调度还是第三方依赖出了问题，而不是一上来就改代码

8. 技术判断维度

• 微服务不是拆得越细越好：真正合理的边界，取决于业务变化频率、数据耦合程度和后续演进成本
• 不是所有场景都值得上 AI / 向量检索：只有在自然语言理解、语义召回、内容生成真的能带来价值时，AI 才是正收益
• 很多优化的本质不是换框架，而是找对数据结构：例如列表、详情、计数分层存储，本质上是访问模型设计，而不是 Redis 本身的魔法
• 开源项目里，真实比“看起来高级”更重要：比如 Seata 当前是预留能力而不是全链路落地，文档就应该据实表达

9. 开源表达与复盘维度

• 好项目不只靠代码，也靠表达：README、链路图、页面导览、接入文档，会直接决定别人能否在 5 分钟内看懂你的系统
• “会做”和“会讲”是两套能力：能把代码讲成架构、把链路讲成业务、把取舍讲成判断，项目才真正有说服力
• 链路图不是装饰，而是设计说明书：当你能把主链、补偿链、缓存链、调度链讲清楚时，系统边界也会更清晰
• 复盘文档会反过来暴露问题：一旦开始整理文档，就会更容易发现命名混乱、职责重叠、链路缺图和设计断层

10. 独立推进项目维度

• 复杂项目要从“最小闭环”开始搭建：先跑通登录、首页、下单、支付、评价，再逐步补 AI、审核、推荐、IM 等扩展能力
• 单人项目更需要节奏感：不是一口气把所有模块堆出来，而是按“可运行 -> 可扩展 -> 可优化 -> 可展示”逐层推进
• 正确性永远先于性能：库存不能乱、状态不能错、补偿要完整，在这之后再谈 QPS、缓存和吞吐量才有意义
• 长期项目拼的是持续迭代能力：能把 223 次提交沉淀成一个结构清晰、链路完整、可讲可跑的项目，本身就是一种工程能力

11. 如果只让我总结这 6 个月最大的 3 个沉淀

如果只能讲 3 条，我会讲这三件事：

1. 学会了把“功能实现”升级成“链路设计”

   • 不再只盯 Controller 和 Service，而是开始从缓存、MQ、调度、幂等、补偿、审核这些角度看系统

2. 学会了把“代码完成”升级成“工程沉淀”

   • 不只是把功能写完，还要留下脚本、图、文档、README、导览页和可复述的话术

3. 学会了把“项目做出来”升级成“项目讲清楚”

   • 这份项目最终最重要的收获，不只是代码规模，而是我已经能比较系统地解释自己的设计判断、取舍和演进方向

12. 如果你想继续看“这个项目是怎么一步步长出来的”

这一页更偏“最后沉淀了什么”，如果你想继续看项目从教学起点到当前版本的完整演进过程，建议直接看：

• 开发历程与演进记录