项目全貌与答辩说明
本页作为网站详细版页面维护，适合用作项目介绍、答辩说明与面试展开的统一入口。
如果你准备围绕项目做一次完整讲解，建议优先按这个顺序展开：
- 如果你只有 3 分钟
- 项目定位与规模
- 为什么值得继续看
- 页面导览与业务闭环
- 核心链路与设计判断
如果你准备按整站“面试拆解与答辩”那组一路往下讲，建议统一按下面这条顺序：
- 项目全貌与答辩说明
- 核心亮点与项目价值
- 我的核心设计与实现
- 性能指标与结果
- 数据建模与表关系怎么讲
- 技术选型理由
- 难点踩坑与解决方案
- 未来规划 Roadmap
- 核心架构拷问 FAQ
🙋 个人独立项目声明：本项目由作者从零开始独立设计、编码并持续维护， 非培训项目或拼接式 Demo，仓库内保留了完整的开发与演进记录。
0. 如果你只有 3 分钟
如果你是第一次看这个项目，最推荐先抓住下面 3 组信息：
- 它不是单点 Demo，而是完整平台
覆盖用户端 App / H5、商家端 Web、平台管理端 Web三类入口，不只是“后端接口 + 几张页面”。 - 它不是轻量 CRUD，而是多中间件协同工程
当前项目有16 个业务模块、19 个可运行服务、53 张核心表、18 个 FeignClient、30 个 RabbitMQ 监听器。 - 它不是只会跑，而是已经能讲清楚
文档站已经沉淀了73 张链路图、102 张截图、11 篇专题页，可以直接对照页面、链路和代码展开面试说明。
如果你只想看 3 个入口，我建议按这个顺序：
一句话介绍版本可以直接这样讲：
SmartLive 是一个面向本地生活场景的微服务平台，覆盖用户端、商家端和平台管理端三类入口，把交易、搜索、社交、审核、IM、支付、积分、热榜和 AI/RAG 串成了同一套可运行、可追踪、可继续扩展的系统。
0.5 如果你正好是因为 AI / RAG 点进来的
如果你最关心的是“这个项目里的 Spring AI 和 RAG 到底是不是做实了”，最推荐先看下面这张总图，再决定要不要继续深入源码。
这张图把 SmartLive 里的 AI 主链路拆成了两条最关键的线：
- 知识建库链路：商品、店铺、评价、博客等业务数据先通过 MQ 增量同步进 Milvus。
- 在线问答链路：用户问题进入 Agent / Tool / RagService 后，再做向量检索和业务化生成，最后通过 SSE 把回答或卡片回给前端。
所以这套实现并不是“普通聊天页 + 一点向量检索点缀”，而是更接近生产落地的业务数据型 RAG。
如果你只想先看一页把这个问题讲清楚，可以直接跳到：
1. 项目定位
SmartLive（智评生活） 是一个面向本地生活服务场景的微服务平台，覆盖用户发现、交易履约、内容互动、商家经营与平台治理。
它不是单一业务 Demo，而是把交易、搜索、社交、审核、IM、支付、积分、热榜、AI/RAG 等能力放进同一套可运行、可追踪、可继续扩展的系统里。
2. 这个仓库覆盖什么
- 后端微服务主仓库：包含
16个核心业务模块，并连同auth / gateway / monitor组成19个可运行服务应用。 - 三类前端入口闭环：既覆盖用户端 App 的找店、下单、评价、博客、聊天与 AI 问答，也覆盖商家端 Web 的经营后台，以及平台管理端 Web 的审核治理与运营配置。
- 多中间件协同：Redis、RabbitMQ、Elasticsearch、Milvus、MinIO、XXL-JOB、Nacos、Gateway、Sentinel、Seata 等共同支撑核心链路。
- 仓库边界清晰：当前仓库聚焦后端与基础设施编排，前端管理端和用户端仓库入口见后文“项目仓库”。
3. 项目仓库矩阵
| 仓库 | 角色定位 | 技术栈 | 入口 |
|---|---|---|---|
| smartLive-Cloud | 后端微服务主仓库，承接交易、社交、搜索、AI、审核、调度与基础设施编排 | Spring Boot / Spring Cloud Alibaba / Redis / RabbitMQ / Elasticsearch / Milvus | GitHub |
| smartLive-admin | 商家端 Web 与平台管理后台，覆盖店铺、商品、订单、审核、运营、系统管理等后台能力 | Vue + Element UI | GitHub |
| smartLive-web | 用户端 App，覆盖登录、发现、下单、评价、博客、社交消息与 AI 能力 | Vue 移动端 / H5 页面体验 | GitHub |
这三者的关系可以简单理解成：Cloud 负责后端与中间件协同，smartLive-admin 负责商家与平台后台，smartLive-web 负责用户端前台体验。阅读项目时，建议先看本仓库，再配合页面导览理解前端呈现。
补充说明：
- 如果你按本地工作区理解，这三套代码当前分别对应
smart-live-Cloud、smart-live-app、smartLive-ui三个目录。 - 这一节保留的是对外展示时的仓库入口口径，方便招聘方或面试官直接跳到对应仓库。
4. 为什么值得开源阅读
| 维度 | 内容 |
|---|---|
| 业务范围 | 覆盖本地生活场景中的发现、交易、履约、评价、社交、经营分析与平台治理 |
| 技术主题 | 微服务拆分、Redis 分层缓存、消息可靠投递、秒杀与订单补偿、热榜计算、AI/RAG 集成 |
| 文档资产 | 首页导览图、业务链路图、Redis 设计图、XXL-JOB 调度图、真实页面截图 |
| 适合人群 | 想看完整 Java 微服务项目、准备面试复盘、或想学习“业务闭环 + 工程化设计”落地方式的人 |
5. 项目规模
| 维度 | 数值 | 说明 |
|---|---|---|
| 核心业务模块 | 16 个 | 用户、店铺、商品、订单、博客、互动、搜索、AI、IM 等核心业务模块 |
| 可运行服务应用 | 19 个 | 16 个业务模块 + auth + gateway + monitor |
| 核心能力域 | 6 大类 | 发现推荐、交易履约、社交互动、内容治理、经营分析、基础设施 |
| 前端入口覆盖 | 3 类 | 用户端 App + 商家端 Web + 平台管理端 Web |
| 核心业务代码 | 30,000+ 行 | 以服务端业务逻辑为主 |
| 文档与图示资产 | 70+ 链路图 / 100+ 截图 | 当前文档站已沉淀 73 张链路图、102 张引用截图与 11 篇专题页 |
| Git 提交记录 | 200+ | 可回溯完整开发过程 |
5.2 项目开发时间线（按 Git 提交记录粗粒度归纳）
如果面试官追问“这个项目是不是一步步做起来的”，最容易讲清楚的方式不是背模块名，而是按阶段回看它是怎么长出来的。
| 阶段 | 时间 | 当时主要做了什么 | 现在可以怎么讲 |
|---|---|---|---|
| 第 1 阶段 | 2025.10 | 初始化仓库，先把登录、首页、地图、搜索、私信、AI 评论 / 下单雏形做起来 | 先证明项目不是只会 CRUD，而是从一开始就在做完整用户链路 |
| 第 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、补偿、文档站和可表达性”补齐。
5.5 这页最值得主动讲的 3 组数据
如果你要把这页当答辩开场页，我最推荐优先抛这 3 组：
- 规模数据：
16 个业务模块 / 19 个服务应用 / 53 张核心表
这组数据最能证明它不是课程级小项目，而是一个跨多个业务域的完整平台。 - 协同密度：
18 个 FeignClient / 30 个 RabbitMQ 监听器 / 26 个 @XxlJob 处理器
这组数据最能证明项目不是“拆了服务名但没有真实协同”，而是确实有跨服务调用、消息驱动和定时补偿。 - 文档与展示资产：
73 张链路图 / 102 张截图 / 11 篇专题页
这组数据最能证明这个项目不是只写代码，还能完整表达架构、业务闭环和设计判断。
如果你需要一句更像面试回答的话，可以直接说：
我这个项目最核心的不是“服务拆得多”，而是三件事一起成立：业务闭环完整、服务协同真实存在、文档和链路图可以直接验证。
5.8 如果面试官只让我讲 1 分钟
你可以直接按下面这个版本讲：
SmartLive 是我独立完成的一个本地生活微服务平台，覆盖用户端、商家端和平台管理端三类入口。
后端这边我拆了 16 个业务模块、19 个可运行服务，把交易、搜索、社交、审核、IM、支付、积分、热榜和 AI/RAG 放进同一套系统里。
工程上我重点做了 Redis 分层缓存、RabbitMQ 异步解耦、秒杀链路、订单支付退款补偿、Feed 推送、搜索同步和商家 AI 助手这些能力。
这个项目我不仅把代码跑起来了，还补了完整的页面导览、链路图和专题文档，所以它既能讲实现，也能讲架构判断和工程表达。
如果想再压缩成更短的 30 秒版本，可以这样说：
这是一个覆盖用户端、商家端和平台管理端的本地生活微服务平台。我独立完成了 16 个业务模块、19 个服务的后端设计和实现，重点做了交易、缓存、MQ、搜索、社交、审核和 AI 能力，并且把页面、链路和专题文档都沉淀成了在线文档站。
6. 统计口径说明
| 指标 | 统计口径 |
|---|---|
| 业务模块 | 统计 smartLive-modules 下的实际业务服务，不包含 api / common / visual / sentinel / seata-server 等支撑工程 |
| 服务应用 | 业务模块 + smartLive-auth + smartLive-gateway + smartLive-monitor，按可独立运行的服务口径计算 |
| 代码量 | README 保留“核心业务代码 3万+”口径；网站首页卡片展示仓库当前 Java 总量 7万+，两者分别用于强调业务密度与工程总体量 |
| 页面截图 | 统计 docs/screenshots 中当前被在线文档实际引用的截图，不包含 legacy 归档图 |
| 链路图 | 分开展示版 SVG 与详细版 SVG 两套数量，均以 docs/diagrams 当前可访问文件为准 |
| XXL-JOB 任务 | 对外展示继续沿用调度后台截图中的 28 个任务口径；如果按代码内 @XxlJob 处理器统计，当前为 26 个 |
6.5 还能从代码里直接读出的工程密度
这些数据不一定适合放到首页大卡片里，但很适合在面试或项目介绍时证明这不是“几个页面 + 几个接口”的轻量 Demo。
| 维度 | 当前数据 | 说明 |
|---|---|---|
| API 契约模块 | 10 个 | smartLive-api 下拆分了 AI、博客、聊天、互动、订单、积分、商品、店铺、系统、用户 10 组接口契约 |
| 通用基础组件 | 11 个 | smartLive-common 下沉淀了 Redis、RabbitMQ、XXL-JOB、安全、日志、敏感词、多数据源等基础能力 |
| Java 文件数 | 831 个 | 反映的是工程总体体量，不等同于“核心业务代码 3万+”的表达口径 |
| Controller 数量 | 71 个 | 能直观看出这个项目不是单一业务，而是多域协同的完整平台 |
| FeignClient 数量 | 18 个 | 体现服务间接口调用的拆分密度与边界设计 |
| RabbitMQ 监听器 | 30 个 | 说明你项目里消息驱动与最终一致性不是停留在概念层 |
| 文档专题页 | 11 篇 | site-pages 已形成系统架构、数据模型、性能、选型、FAQ、Roadmap 等专题材料 |
7. 为什么值得继续往下看
- 不是只做“登录 + CRUD”的展示型项目，而是真正把多业务域和多中间件串成闭环。
- 同时覆盖 ToC 用户体验、ToB 商家经营、平台审核治理 三条线，项目视角更完整。
- 文档里已经补齐 业务链路、缓存设计、调度体系、页面导览，第一次阅读也能快速建立全局认知。
8. 继续往下看什么
如果你已经看完这页，下一步建议这样接：
- 看 项目级能力亮点，先把“项目整体强在哪”讲清楚。
- 看 我的核心设计与实现，再把“我具体做了什么”讲清楚。
- 看 性能指标与结果，把性能与工程表现补齐。
- 看 数据建模与表关系怎么讲，把交易、资产和互动的建模思路讲清楚。
- 再回到 技术选型理由、难点踩坑与解决方案 和 核心架构拷问 FAQ，把“为什么这样做”和“怎么回答追问”补齐。