从内容社区到AI智能客服：Spring Boot + Spring Cloud + Spring AI 全栈实战面试拆解

从内容社区到 AI 智能客服：一场互联网大厂 Java 面试全流程拆解

场景：某互联网大厂，业务是「内容社区 + UGC + AIGC」，正在招聘 Java 后端开发。

角色：

• 面试官：老王，十年老兵，风格严肃但不刻薄。
• 候选人：小Y，自称有 3 年经验，实际上项目经验比较水，但会背八股，临场经常嘴瓢。

本文通过 3 轮、共 12 个问题的面试对话，把一个内容社区 & AIGC 业务从单体到微服务、从基础 CRUD 到搜索推荐、再到 AI 智能客服系统串起来。最后附上详细答案与技术拆解，适合 Java 初中级同学系统学习。

---

一、第一轮：内容社区基础服务（Spring Boot + MyBatis + Redis）

业务场景：做一个「图文内容社区」，用户可以发帖子（UGC），点赞、评论、收藏。先从单体服务说起。

Q1：项目整体技术栈 & 架构

面试官： 你简单介绍下，你做的内容社区项目，整体架构和主要技术栈是什么？

小Y： 啊这个，我当时是核心开发......我们用的是 Spring Boot，然后配合 MyBatis，数据库是 MySQL。缓存就是 Redis 呗，然后用 Maven 管理依赖，日志嘛就 Logback+SLF4J。部署就是 Docker 打镜像，放在 Kubernetes 上跑。

面试官： 嗯，至少技术名词说得还挺顺。那整体是单体还是微服务？

小Y： 这个......一开始是单体，后来我们做成了......呃，算是微服务吧，反正模块拆开了。

面试官： "算是微服务"是个什么新物种？待会我们再聊拆分，先往下。

---

Q2：发帖接口设计（Spring MVC + JSR 规范）

面试官： 用户发一篇图文帖子，你的后端接口怎么设计？

至少说清楚：

1. 请求 URL 和 HTTP 方法
2. 请求体字段
3. 如何做参数校验（Java/Jakarta EE 规范）

小Y： 我们是 POST /api/posts 啊，然后请求体大概就是 title、content，还有 userId 吧。校验就 @NotNull 啦，@Size 啊那种，用 Spring Boot 自带的......呃，那个 jakarta.validation 吧，然后 Controller 上加 @Valid 就行。

面试官： 还行，说到点上了。那你会不会把 userId 放到请求体里？

小Y： 嗯......有 token 的话，好像可以从 token 里拿吧？那就不用放 body 了。

面试官： 对，有认证体系时 userId 通常从 JWT 或 Session 中获取，这样安全性更好。

---

Q3：点赞功能设计（幂等性 + Redis 缓存）

面试官： 点赞功能很常见：用户对一篇帖子点赞。

请你说说：

1. 接口怎么设计？
2. 点赞计数如何设计，既保数据一致性，又扛高并发？

小Y： 接口也是 POST 吧，/api/posts/{id}/like。 计数的话，我们是存在数据库里的，然后 Redis 里也放一个计数，用户点一次，我就 Redis 里 incr 一下，然后定时回写数据库。

幂等性的话，呃......我们就是按钮点一次就灰掉......

面试官： UI 灰掉不是后端幂等性方案。 按你说的设计，如果用户频繁点击，或者前端 bug，一秒钟发 10 个请求，你怎么保证不会重复点赞？

小Y： 这个......可以用 Redis set 存一下用户点过没？

面试官： 可以，用 SADD 用户集合，或者 key 用 like:postId:userId。说明你有接触过。只是要注意：幂等需要后端从"操作语义"上保证，而不是只靠前端按钮颜色。

---

Q4：MyBatis + 数据库表设计

面试官： 简单说一下帖子表 post 的表结构设计，以及你用 MyBatis 怎么写 Mapper？

小Y： 表结构就：

• id 主键 bigint
• user_id 发帖人
• title
• content
• like_count
• comment_count
• create_time
• update_time

MyBatis 就写一个 PostMapper.xml，里面 insert、selectById 那些，用 @Mapper 配合 XML 方式，我们也用过注解方式。

面试官： OK，这一块还算基础扎实。你把字段说清楚了也提到了计数字段。不过生产中还会加状态位、逻辑删除等，这些可以自己再补。

---

Q5：登录与权限（Spring Security + JWT）

面试官： 用户要发帖，必须是登录用户。你在项目中，登录和权限怎么做的？

小Y： 我们是用 Spring Security，然后登录的时候把用户名密码校验一下，成功后发一个 JWT 给前端，后面请求都带这个 token。过滤器里解析 token，放到 SecurityContext 里就行。

权限的话就是用 @PreAuthorize，比如 hasRole('USER')。

面试官： 嗯，对路。JWT 里一般存 userId、角色等信息，签名用 HS256 或 RS256，注意过期时间和刷新机制。你大体方向没跑偏。

---

二、第二轮：从单体到微服务（Spring Cloud + Kafka + Elasticsearch）

业务场景：内容社区用户量上来后，要支持推荐、搜索、消息通知。开始拆成多个微服务：内容服务、搜索服务、消息服务、用户服务等。

Q6：服务拆分与注册发现（Spring Cloud + Eureka/Consul）

面试官： 随着业务发展，你们把单体拆成了微服务。你怎么划分服务？用什么做服务发现？

小Y： 我们就按业务拆呗，像 content-service、user-service、search-service 这些，然后用 Eureka 注册中心。每个服务启动时注册到 Eureka，调用的时候用服务名就可以，不用写死 IP。

面试官： 还算经典的 Spring Cloud Netflix 组合。 拆分服务时需要考虑：

• 领域边界（DDD 概念）
• 数据库是否独立（每服务一个库）
• 调用关系是否会形成"蜘蛛网"

这些你后面可以多看看。继续往下。

---

Q7：帖子发布到搜索系统（Kafka + Elasticsearch）

面试官： 用户发帖后，希望 3 秒内能在搜索结果里搜到。

请你设计：

1. 内容服务如何把帖子数据同步到搜索服务？
2. 你会选什么技术栈？

小Y： 我们是发帖成功后，往 Kafka 发一条消息嘛，然后 search-service 去消费 Kafka，把数据写到 Elasticsearch 里。

内容服务就生产一个 JSON，topic 比如 post-created，里面有 postId、title、content 等。搜索服务消费后用 ES 的 RestHighLevelClient 去写索引。

面试官： 思路合理。那如果写 ES 失败了呢？

小Y： 啊......那就重试一下？

面试官： 可以，常见做法：

• Kafka 重试机制 / DLQ（死信队列）
• 本地落库（outbox）+ 定时补偿

你只提到"重试"，实现层面还比较泛。

---

Q8：接口幂等 + 分布式事务

面试官： 发帖流程中，现在有两个动作：

1. 写 MySQL（内容服务）
2. 通过 Kafka 通知搜索服务写 ES

如果写库成功、发 Kafka 失败，或者反过来，你如何保证整体一致？

小Y： 这个......分布式事务用 Seata？或者 TCC？

面试官： 你在项目里真用过吗？

小Y： 呃......看过......看过资料。

面试官： 听起来更像"看过"而不是"用过"。

这类场景一般用最终一致性：

• 内容服务本地事务写库；
• 把"待发送事件"写到本地 outbox 表；
• 由定时任务或 binlog 监听发 Kafka；
• Kafka 消费方也要设计幂等消费。

你可以回去查"事务消息""本地消息表"相关资料。

---

Q9：推荐系统 & 缓存设计（Redis + 热点数据）

面试官： 首页推荐流：

• 用户打开首页，看到一堆帖子推荐；
• 热帖被频繁访问；
• 我们需要既扛住流量，又保证数据不太旧。

你会怎么设计缓存？

小Y： 我们会用 Redis 啊，把首页列表缓存起来，比如 home:feed:userId，查一次之后，下次就直接从 Redis 里拿。设置个 TTL，比如 5 分钟。

热门帖子也可以放到 Redis 里，like_count 高的 posts 缓存起来，定时刷新。

面试官： OK，思路对，不过要考虑：

• 缓存击穿/雪崩/穿透；
• 分页数据一致性；
• 多终端多维度（推荐 vs 关注流）。

你现在的回答偏"口号"，细节可以再打磨。

---

Q10：日志与链路追踪（Logback + Sleuth + Zipkin/Jaeger）

面试官： 微服务之后，一个请求会经过多个服务。你们怎么排查线上问题？

说说日志框架和链路追踪方案。

小Y： 日志就是 Logback+SLF4J 啊，统一用 JSON 格式，输出到 ELK。链路追踪我们有挂 Spring Cloud Sleuth，然后对接 Zipkin，这样可以看到 traceId、spanId。

面试官： 挺好，至少你知道 traceId，在各个服务日志里串起来。生产上常用 Zipkin、Jaeger、SkyWalking 等。

---

三、第三轮：AI 智能客服 & RAG（Spring AI + 向量数据库）

业务场景：内容社区要做一个「智能客服 + 智能助手」，可以回答用户关于平台规则、创作收益、内容审核等问题，还能基于用户历史内容做智能推荐和问答。

Q11：AI 智能客服总体设计（RAG + Agent）

面试官： 现在公司要做一个智能客服：

• 用户在 App 里输入自然语言问题；
• 我们希望答案既精准又不乱编（减少幻觉）；
• 需要支持基于平台文档、公告、FAQ 来回答。

你会怎么设计这个系统？尽量从整体架构讲起。

小Y： 呃......我们可以用那个......RAG？就是检索增强生成？

就......先把文档弄到向量库里，比如 Chroma 啊 Milvus 啊；然后用户问问题，我们先用 Embedding 算向量，去向量数据库里搜，然后把相关文档片段丢给大模型，让它生成答案。中间可以用 Spring AI 做个封装。

至于那个......Agent 啊，就让它帮我们自动调用工具，比如查订单、查余额。

面试官： 方向没错，不过你描述比较泛。比如：

• 文档加载、切分；
• 向量化模型选型；
• 如何减少幻觉（比如加系统提示、引用来源）。

你只点了关键词，缺少落地细节。

---

Q12：Spring AI 调用 LLM + 向量检索

面试官： 具体一点：

• 使用 Spring AI 调用一个 LLM（比如 OpenAI 或自建）；
• 使用 Redis 或 Milvus 做向量数据库；
• 实现一个"企业文档问答"的 REST 接口。

你能描述一下关键的代码结构、调用流程吗？

小Y： 呃......我们会有一个 Controller，比如 /api/qa，POST 请求体里面有 question。然后 Service 里先用......那个......embeddingClient 去生成向量，然后调向量库的 search，拿到 topK 文档。

然后把这些文档拼到 prompt 里，调用 ChatClient......呃，就是 Spring AI 的那个接口，让模型生成答案。

结构上就 Controller -> Service -> VectorStore -> LLMClient，这样。

面试官： 还算说到了主干，但你没提到：

• 如何做聊天会话内存（多轮对话上下文）；
• 如何限制工具调用、避免乱查数据；
• 如何记录日志，方便审计。

你现在对 Spring AI、RAG 的理解还是"概念级"，实战深度不足。

---

Q13：AI 幻觉与安全控制

面试官： AI 经常"胡说八道"，也可能泄露敏感信息。

1. 你会从哪几方面减少 AI 幻觉？
2. 智能客服回答中，如何做权限和数据脱敏？

小Y： 减少幻觉的话......可以让它引用文档？然后在 prompt 里跟它说"如果不知道就说不知道"？

权限的话，就让后端先判断用户有没有权限，看完再给大模型？

面试官： 大方向正确，但还比较粗：

• 幻觉：限制知识来源、增加引用、RAG 检索阈值、答案中标明来源；
• 权限：先做业务侧鉴权，再给模型；
• 脱敏：对返回内容做二次过滤（敏感词、信息屏蔽），日志中对用户隐私脱敏。

---

Q14：复杂工作流与 Agentic RAG

面试官： 如果智能客服不仅要回答问题，还要：

• 查询数据库；
• 调用内部 HTTP API；
• 调用支付/订单服务；
• 甚至触发工作流，比如创建工单。

你会如何设计一个"工具调用框架"，允许 LLM 作为 Agent 去调这些工具？

小Y： 呃......我们可以给模型描述工具列表，然后......它自己选？

比如定义一堆 JSON Schema，让它输出调用参数，然后我们后端解析，然后调对应的服务。这个我看 OpenAI 文档里有类似的......工具调用？

面试官： 听起来你的理解还是停留在文档层面，没有真实落过地。你只说了"工具列表+JSON"，但是：

• 如何做工具的权限控制？
• 如何防止循环调用？
• 如何监控整个工作流？

这些都是 Agentic RAG、复杂工作流必须考虑的问题。

---

收尾：

面试官： 今天就聊到这。你基础 Java + Spring Boot + MyBatis 这块还不错，对微服务、消息、搜索也有一定了解。AI 这块概念知道不少，但动手深度明显不够。

接下来我们会综合评估，再和你联系，你回去可以多把你说过的概念真正做一遍 demo。回去等通知吧。

小Y： 好......好的，谢谢面试官......

---

四、面试题详细解析与技术拆解

下面是对上述问答进行系统梳理，让没有实战经验的小伙伴也能看懂。

1. 内容社区单体服务：Spring Boot + MyBatis + Redis

1.1 发帖接口设计（Q2）

业务场景： 用户发一篇图文帖子，需要校验标题、内容、登录状态。

技术点：

• Spring Boot + Spring MVC
• Jakarta Validation（JSR 380）
• Spring Security / JWT

典型接口设计：

POST /api/posts
Content-Type: application/json
Authorization: Bearer <JWT>

{
  "title": "今天天气真好",
  "content": "拍了几张照片，大家来看看",
  "images": ["https://..."],
  "tags": ["生活", "摄影"]
}

请求校验：

public class CreatePostRequest {

    @NotBlank
    @Size(max = 128)
    private String title;

    @NotBlank
    @Size(max = 5000)
    private String content;

    private List<@Size(max = 512) String> images;

    private List<@Size(max = 32) String> tags;
}

Controller 中：

@PostMapping("/api/posts")
public PostVO createPost(@Valid @RequestBody CreatePostRequest request,
                         @AuthenticationPrincipal UserDetail user) {
    Long userId = user.getId();
    return postService.createPost(userId, request);
}

• 使用 @Valid 启用参数校验；
• 使用 @AuthenticationPrincipal 从 Spring Security 中取当前登录用户，而不是让前端传 userId。

1.2 点赞幂等与 Redis 设计（Q3）

业务场景： 用户对帖子点赞，需要防止重复点赞、扛高并发。

技术点：

• 幂等性设计
• Redis Set / Key 设计
• 计数回写策略

典型设计：

• Redis Key：post:like:users:{postId}，Value 为 Set，元素是 userId；
• 再维护一个计数 Key：post:like:count:{postId}。

伪代码：

public boolean likePost(long postId, long userId) {
    String userSetKey = "post:like:users:" + postId;
    Long added = redisTemplate.opsForSet().add(userSetKey, userId);
    if (added == 1) {
        // 第一次点赞
        redisTemplate.opsForValue().increment("post:like:count:" + postId);
        // 可异步写入消息队列或数据库
        return true;
    } else {
        // 已点赞，幂等
        return false;
    }
}

要点：

• 幂等的核心：同一用户对同一资源的多次相同操作，结果一致；
• 不依赖前端 UI，而在后端通过 Redis Set 保证；
• 定期将 Redis 中的计数回写 MySQL，保证最终一致。

1.3 MyBatis 表设计（Q4）

简化表结构：

CREATE TABLE post (
  id           BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id      BIGINT       NOT NULL,
  title        VARCHAR(128) NOT NULL,
  content      TEXT         NOT NULL,
  like_count   INT          NOT NULL DEFAULT 0,
  comment_count INT         NOT NULL DEFAULT 0,
  status       TINYINT      NOT NULL DEFAULT 1, -- 1:正常, 0:删除
  create_time  DATETIME     NOT NULL,
  update_time  DATETIME     NOT NULL,
  INDEX idx_user_id(user_id),
  INDEX idx_create_time(create_time)
);

MyBatis Mapper 示例：

<select id="selectById" parameterType="long" resultType="Post">
  SELECT * FROM post WHERE id = #{id} AND status = 1
</select>

<insert id="insert" parameterType="Post" useGeneratedKeys="true" keyProperty="id">
  INSERT INTO post(user_id, title, content, like_count, comment_count, status, create_time, update_time)
  VALUES(#{userId}, #{title}, #{content}, 0, 0, 1, NOW(), NOW())
</insert>

---

2. 微服务化：Spring Cloud + Kafka + Elasticsearch（Q6--Q10）

2.1 服务拆分 & 注册发现（Q6）

典型拆分方式：

• user-service：用户注册、登录、关系链（关注等）；
• content-service：帖子、评论、点赞等；
• search-service：搜索与 ES 索引维护；
• notify-service：站内信、Push 推送；
• gateway-service：统一网关（Spring Cloud Gateway / Zuul）。

服务发现：

• 使用 Eureka 或 Consul；
• 各服务通过 spring.application.name 注册；
• 服务间调用用 OpenFeign 或 RestTemplate，通过服务名调用。

spring:
  application:
    name: content-service

  cloud:
    discovery:
      client:
        simple:
          instances:
            search-service:
              - uri: http://search-service:8080

2.2 通过 Kafka 同步到 Elasticsearch（Q7--Q8）

流程：

1. content-service 在本地事务中写 MySQL 帖子数据；
2. 写入本地 outbox 表一条"帖子创建"事件；
3. 定时任务或 binlog 监听程序，将 outbox 事件写入 Kafka（topic：post-created）；
4. search-service 消费 Kafka，写入 Elasticsearch 索引；
5. 若写 ES 失败，可重试或进入死信队列（DLQ）。

事件示例：

{
  "eventId": "uuid",
  "eventType": "POST_CREATED",
  "postId": 123,
  "userId": 456,
  "title": "...",
  "content": "...",
  "createdAt": "2026-08-16T10:00:00Z"
}

ES 索引 Mapping 示例：

{
  "mappings": {
    "properties": {
      "postId": {"type": "long"},
      "title": {"type": "text", "analyzer": "ik_max_word"},
      "content": {"type": "text", "analyzer": "ik_max_word"},
      "userId": {"type": "long"},
      "createdAt": {"type": "date"}
    }
  }
}

为什么用最终一致性而不是强一致分布式事务？

• 发帖写库是核心路径，必须快速、可靠；
• 搜索索引稍有延迟可以接受（秒级）；
• 使用本地消息表 + Kafka 可以在复杂生产环境中更稳定。

2.3 缓存与推荐（Q9）

业务场景：

• 首页推荐流对性能要求极高；
• 同一用户刷首页可能多次请求；
• 热门帖子被成千上万用户请求。

常见设计：

1. 推荐结果生成：离线 + 实时融合（Flink / Spark 计算候选集合）；
2. 将每个用户的候选帖子 ID 列表缓存到 Redis：
   • feed:candidate:userId -> list of postIds；
3. 前端分页时：
   • 从 Redis 中取 postId 列表，结合 Redis / DB 取详情；
4. 热帖详情缓存：
   • post:detail:postId；
   • 使用 TTL + 主动刷新机制。

防三大问题：

• 缓存击穿：热点数据加互斥锁；
• 缓存雪崩：TTL 加随机、热点预热；
• 缓存穿透：对不存在的 key 返回空并短期缓存。

2.4 日志与链路追踪（Q10）

技术栈：

• 日志：Logback + SLF4J，输出 JSON 日志到 ELK（Elasticsearch + Logstash + Kibana）；
• 链路追踪：Spring Cloud Sleuth + Zipkin / Jaeger；
• 指标监控：Micrometer + Prometheus + Grafana。

关键点：

• 在入口网关打 traceId；
• 每个服务在日志中打印 traceId、spanId；
• 结合 APM（如 New Relic）监控慢请求、错误率。

---

3. AI 智能客服系统：Spring AI + RAG + 向量数据库（Q11--Q14）

3.1 RAG 基础流程（Q11）

业务场景：

• 企业有大量文档：平台规则、UGC 审核规范、结算规则等；
• 用户问："为什么我的帖子被下架了？""收益怎么算？"

RAG（Retrieval Augmented Generation）流程：

1. 文档加载（Document Loading）：
   • 从 Markdown、PDF、数据库、知识库中加载文档；
2. 文本切分（Chunking）：
   • 将长文档拆成 500--1000 字的小片段；
3. 向量化（Embedding）：
   • 使用 Embedding 模型（OpenAI、Ollama 等）将每个 chunk 转为向量；
4. 存储（Vector Store）：
   • 存入 Milvus、Chroma、Redis 向量索引；
5. 查询时：
   • 用户问题 -> 向量；
   • 在向量库中做相似度检索（kNN）；
   • 拿到 TopK 文档片段；
6. 构造 Prompt：
   • 把检索到的片段 + 用户问题 + 系统提示，喂给 LLM；
7. LLM 输出答案，并附上引用来源。

3.2 Spring AI + 向量数据库（Q12）

基本组件：

• ChatClient / OpenAiClient：调用 LLM；
• EmbeddingClient：生成向量；
• VectorStore：封装 Milvus/Redis 等向量库；
• 控制层：REST Controller。

伪代码结构：

@RestController
@RequestMapping("/api/qa")
public class QaController {

    private final QaService qaService;

    @PostMapping
    public QaResponse ask(@RequestBody QaRequest request,
                          @AuthenticationPrincipal UserDetail user) {
        return qaService.answer(user.getId(), request.getQuestion());
    }
}

@Service
public class QaService {

    private final EmbeddingClient embeddingClient;
    private final VectorStore vectorStore;
    private final ChatClient chatClient;

    public QaResponse answer(Long userId, String question) {
        // 1. 鉴权、风控
        // 2. 向量化
        float[] queryVector = embeddingClient.embed(question);

        // 3. 相似度检索
        List<Document> docs = vectorStore.search(queryVector, 5);

        // 4. 构造 Prompt
        String prompt = buildPrompt(question, docs);

        // 5. 调 LLM
        String answer = chatClient.chat(prompt);

        // 6. 日志 & 审计
        return new QaResponse(answer, docs);
    }
}

向量库选择：

• Milvus：分布式向量数据库，适合大规模向量；
• Chroma：嵌入式/轻量级；
• Redis：Redis 7 支持向量索引；
• 关键是要支持：相似度检索、过滤（如按业务线、权限过滤）。

3.3 减少 AI 幻觉（Q13）

常见手段：

1. 严格控制知识来源：

   • 在系统提示中加入："只能根据提供的文档回答，不要编造"；
   • 检索不到相关文档时，返回统一模板："根据现有资料无法回答，请联系人工客服"。

2. 引用来源：

   • 模型回答中附上文档标题、段落 ID；
   • 例如："（依据《内容审核规范》第 3.2 条）"。

3. 检索阈值：

   • 若相似度低于阈值，不进行 RAG，直接返回"无法回答"；

4. 后处理：

   • 对答案进行规则校验：
     • 不允许输出内部系统名、敏感关键词；
     • 不允许给出与平台政策冲突的答案。

3.4 权限、脱敏与安全（Q13）

关键原则：

• 所有权限控制在 业务系统 做，而不是交给 LLM；
• 模型只能在授权后的"数据视图"上工作。

实践：

1. 请求进入系统时：
   • 先通过 Spring Security / OAuth2 / Keycloak 做认证；
   • 根据用户角色、租户等过滤可访问文档；
2. 向量检索时：
   • 仅在用户有权限的 doc 集合中搜索；
3. 输出时：
   • 对电话号码、身份证、邮箱等敏感信息做脱敏；
   • 对日志中的用户问题、答案做匿名化；
4. 审计：
   • 记录：用户ID、问题、引用文档、最终答案、时间。

3.5 Agent & 工具调用框架（Q14）

业务场景：

• 用户问："帮我查一下上个月的创作者收益，并且生成一份结算单。"
• 需要：
  • 调收益服务 API；
  • 写一条结算记录；
  • 返回一个结构化结果。

工具调用框架思路：

1. 定义工具（Tool）：
   • 一个可调用函数/HTTP 接口；
   • 有明确的输入 Schema 和输出 Schema；
2. 注册工具列表：
   • 给每个工具定义 name、description、schema；
3. 提供给 LLM 的"工具规范"：
   • 让 LLM 知道可以调哪些工具、用途是什么；
4. LLM 输出"工具调用指令"：
   • JSON 格式，指定 toolName 和参数；
5. 后端解析 & 调用：
   • 按照 toolName 找到具体实现，调用后返回；
6. 再次把工具结果交给 LLM，总结成自然语言。

需要考虑：

• 权限控制：某些工具只能被特定角色调用；
• 安全限制：工具执行次数、参数范围限制；
• 工作流可观测性：每一步调用记录日志、traceId；
• 防止无限循环：设置最大调用步数。

---

五、总结：从 CRUD 到 AI 的技术演进路径

1. 基础阶段：
   • Spring Boot + Spring MVC
   • MyBatis / JPA + MySQL
   • Redis 缓存、基本幂等
2. 扩展阶段（微服务）：
   • Spring Cloud（Eureka/Consul + OpenFeign + Gateway）
   • Kafka/RabbitMQ + Elasticsearch
   • 日志（Logback + ELK）、监控（Prometheus + Grafana）
3. AI 阶段：
   • Spring AI + 向量数据库（Milvus/Chroma/Redis）
   • RAG、Agent、工具调用框架
   • 权限控制、脱敏、安全审计

面试官考察的不只是你会背哪些框架名字，而是：

• 知道在什么业务场景下用什么技术；
• 能说清楚数据流、调用链、异常场景；
• 能从"一个小接口"上升到"一个系统"的视角。

建议你在本地自己实现一个 mini 项目，把本文出现的关键点（发帖、点赞、Kafka+ES 同步、RAG 问答）都做一遍，比看十篇面经更有用。