从内容社区 UGC 到 RAG 智能助手：一场 Java 大厂面试的全栈拆解

Devin~Y

339人浏览 · 2026-03-21 21:01:00

Devin~Y · 2026-03-21 21:01:00 发布

面试官怒怼水货程序员：从 Spring Boot 到 AI RAG 的内容社区实战面试全拆解

场景：互联网大厂内容社区 + UGC + AIGC 业务线 Java 后端面试

人物：

面试官：T10 技术大佬，严肃、专业、不苟言笑

小Y：略懂皮毛的“水货”Java 程序员，碰到简单问题还能发挥，复杂一点就开始胡诌

一、开场：内容社区与 UGC 场景简介

公司主营业务：

做类似「图文 + 短视频 + AI 生成内容」的内容社区
用户可以发布图文、视频（UGC），也可以一键让 AI 帮忙写文案、生成封面图（AIGC）
后端采用 Java 技术栈：Spring Boot + Spring Cloud 微服务，MySQL + Redis + Kafka + Elasticsearch，Docker + Kubernetes 部署
同时在尝试基于 RAG（检索增强生成）构建「智能内容助手」和「企业知识问答」的 AI 增强功能

面试官要评估：

小Y 能不能扛得住核心业务请求
对微服务、缓存、消息队列、搜索、监控这些是不是只会喊名字
对 AI / RAG / 向量数据库有没有基本概念

二、第一轮：从用户发帖到基础架构

第一轮问题聚焦：Java 基础、Spring Boot、数据库与缓存、简单性能优化

Q1.1 面试官：

我们这条业务线是内容社区 + UGC。用户发一篇图文帖子，后端大致的技术流程你会怎么设计？

小Y：

这个很简单啊。肯定是 Spring Boot 起一个接口嘛，比如 /api/post/publish。

用户点发布，我就：

用 Spring MVC 写个 @RestController 接住请求
用 MyBatis 插入一条数据到 MySQL 的 post 表
成功就 return success，失败就 return fail。

差不多就这样吧，很简单的业务。

面试官：

嗯……基础流程说到了，但你忽略了关键点：

UGC 场景高并发怎么扛？
发帖之后，要不要写缓存、要不要异步化？

等会儿详细问。

Q1.2 面试官：

发帖之后，帖子要展示在首页 feed 流，还要支持用户点进去看详情。你会怎么用缓存？用什么缓存技术？

小Y：

缓存嘛，肯定是 Redis 呀。这不是面试八股嘛。

用户看帖子详情，就先查 Redis
查不到再查 MySQL
查完再放 Redis

然后设置个过期时间，比如 1 小时。

嗯……就这么搞了。

面试官：

只说了「查 Redis 查不到再查 MySQL」，没讲：

缓存穿透、击穿、雪崩怎么应对
写多读多场景下缓存的更新策略

一会儿接着挖。

Q1.3 面试官：

我们发帖接口可能会有高并发，比如双 11 活动、热榜投稿。你会从 连接池、线程池、数据库优化 这些方面做哪些基础优化？

小Y：

呃，这个……

连接池的话，我知道有 HikariCP，它挺快的，我在 application.yml 里把最大连接数改大一点，比如 maxPoolSize: 100。
线程池的话，用 @Async，然后 Spring 会给我搞个线程池……好像默认就可以了吧。
数据库优化嘛，就给 post_id 建个索引，再加个自增主键就行了。

大概就这些？

面试官：

你只记住了 HikariCP 的名字。等会儿我会问具体参数的含义，以及线程池的拒绝策略、核心参数。你现在的回答，能看出实战经验偏少。

Q1.4 面试官：

我们的项目要同时兼容 Java 8 和 Java 17，你知道 JVM 和 Java 版本升级有什么坑点吗？比如在 Docker + Kubernetes 环境下。

小Y：

JVM 啊……那就是换成 Java 17 更快嘛。然后用 G1 垃圾回收就好了。

Docker 和 K8s……我记得要给容器配内存限制，不然 JVM 会 OOM。

具体怎么配，我……我得查一下文档。

面试官：

至少你知道要关注容器内存限制，这是个好开始。但实际实践里还有更多参数问题。一会儿在答案部分我们再系统讲。

Q1.5 面试官：

最后一个简单的：整个发帖流程写单元测试和集成测试，你会用什么框架？基本思路说一下。

小Y：

这个我熟：

单元测试：用 JUnit 5，配合 Mockito 做 Mock
集成测试：用 Spring Boot Test 起一个 @SpringBootTest，然后用 MockMvc 调接口
如果有些需要 UI 的，就可以用 Selenium，不过我一般不用

写法就是 @Test 然后 assertEquals 一顿断言。

面试官：

OK，这部分至少是实际写过测试的。

三、第二轮：微服务、消息队列与搜索

第二轮问题聚焦：Spring Cloud 微服务、Kafka、Redis、Elasticsearch、监控

假设发帖已经拆成多个服务：

user-service：用户中心
post-service：发帖/帖子管理
feed-service：首页推荐 / feed 流
search-service：搜索服务（ES）

Q2.1 面试官：

发帖后，我们要：

把帖子写到 MySQL
异步推给搜索服务写入 Elasticsearch
同时通知 feed 服务做冷启动曝光

你会怎么设计服务之间的通信？用到哪些框架或组件？

小Y：

这个就微服务嘛。

服务之间我可以用 OpenFeign 调用 HTTP 接口，比如 post-service 调 search-service 的 /index 接口
也可以用 Kafka，把发帖消息投到 Kafka Topic，比如 post_created，然后 search-service 和 feed-service 都订阅

我感觉 OpenFeign 比较简单，所以我就先用它。

面试官：

在这个场景里你更推荐用哪种？

小Y：

呃……那就 OpenFeign 吧，直接 RPC 很直接。

面试官：

这里暴露出一个问题：你没考虑系统解耦和削峰。这个场景下 Kafka 更合适，一会儿我详细拆解。

Q2.2 面试官：

假设我们用 Kafka 做发帖事件总线：

post-service 生产 post_created 事件
search-service 消费后写 ES
feed-service 消费后做冷启动推荐

我们在 Java 侧会用哪些技术栈来接入 Kafka？如何保证消息“不丢、不重、不乱”？

小Y：

Kafka 我只知道两个：

用 Spring Kafka
或者直接用原生 Kafka Client

不丢嘛，我们可以设置 acks=all，然后多副本。

不重……就，写入的时候先查一下是不是已经处理过？

不乱……Kafka 不是有分区吗？我……记得可以按用户 ID 做分区键，这样就有序了。

面试官：

思路还行，不过回答比较散，缺乏系统性。这个可以给你 60 分。

Q2.3 面试官：

搜索这块我们用 Elasticsearch。你会怎么设计帖子索引的字段？比如标题、内容、标签、作者、发布时间、热度等。分词、排序和高亮你会考虑什么？

小Y：

ES 我一般就是：

title: text
content: text
tags: keyword
authorId: long
createdAt: date

分词用默认的 standard 分词器，高亮就用 ES 自带的高亮……

热度排序的话，就加个 hotScore 字段，用 sort 排一下。

至于中文分词，我记得可以装个 ik 分词器？具体 mapping 我、我不太记得了。

面试官：

至少知道 text/keyword 区别，也知道 ik。还可以。

Q2.4 面试官：

我们的线上会用到 ELK + Prometheus + Grafana + Micrometer。你会怎么在 Spring Boot 里打点和打印日志，以支持：

接口耗时监控
QPS / 错误率
分布式调用链追踪（比如 Zipkin/Jaeger）

小Y：

监控的话：

Spring Boot Actuator + Micrometer 可以导出很多指标，比如 http.server.requests
然后 Prometheus 去拉这些指标，Grafana 就可以画图

日志的话，用 SLF4J + Logback，配置日志格式带 traceId 之类的，然后通过 logstash 推到 Elasticsearch 里。

分布式链路……我只用过一次 Spring Cloud Sleuth，它会自动给我生成 traceId、spanId，然后 Zipkin 可以看到调用链。

面试官：

说明你至少接触过生产环境监控，算加分项。

Q2.5 面试官：

如果 search-service 的 Elasticsearch 节点故障，写入延迟变高甚至超时，你会怎么在 Java 侧做降级和熔断？用哪些库？

小Y：

这个我知道有 Resilience4j：

可以配置熔断器、限流、重试
比如 ES 调用超时次数多了就熔断，直接失败

降级的话，我可以直接把搜索接口返回一个“系统繁忙，请稍后重试”。

至于具体注解怎么写，@CircuitBreaker、@Retry 之类的，我得看下文档才能写全。

面试官：

OK，名字都喊得挺顺溜，但还需要多实操。

四、第三轮：AIGC、RAG 与向量数据库

第三轮问题聚焦：AIGC、RAG、向量数据库、Agent、AI 幻觉、安全与风控

公司正在做一个「智能创作助手」：

用户写帖子时，可点击「AI 辅助写作」按钮
后端会根据用户已经写的内容、历史浏览记录，为他补全标题、摘要，甚至生成图片描述
同时正在试点「企业知识问答」：基于内部知识库做 RAG 问答

Q3.1 面试官：

你理解下，什么是 RAG（检索增强生成）？在我们内容社区场景下，RAG 可以怎么玩？

小Y：

RAG 啊，就是……一边检索，一边生成嘛。

具体就是：先从数据库里查一下相关文档，再把这些结果喂给大模型，让它回答问题，这样就不容易乱编。

在内容社区里，可以……比如：

用户问“帮我写一篇 Java 面试经验”，我们先搜一下社区里类似的文章
再把这些文章的内容给大模型，让它综合一下写一篇新的

呃，大概就这样。

面试官：

整体概念没错，但你没提到向量化、语义检索、向量数据库这些关键点。

Q3.2 面试官：

说到 RAG，就绕不过向量化和向量数据库。你知道：

向量化、语义检索的基本原理吗？
向量数据库我们可以选哪些？比如 Milvus/Chroma/Redis？
Java 侧会怎么对接？

小Y：

向量化……就是把文本变成一串数字，向量，长度可能是 768 之类的。

语义检索就是，用这个向量去算相似度，比如余弦相似度，对吧？

向量数据库，呃，我听说过 Milvus，好像很专业。Redis 也有个向量索引。我没真正用过，只是看过文章。

Java 对接的话，反正就是：

调 Embedding 接口，比如 OpenAI 的
拿到向量，用他们的 Java SDK 写进向量库

具体代码的话……我可能需要现查。

面试官：

OK，至少没瞎说。算你有基础概念。

Q3.3 面试官：

我们会尝试用 Spring AI + RAG 搭建一个「企业文档问答」服务：

文档通过文档加载器切块
通过向量化存入 Milvus
查询时用语义检索 + 大模型生成

你能说一下大致的组件和流程吗？

小Y：

Spring AI……我知道这是 Spring 提供的一个 AI 集成框架，支持 OpenAI、Ollama 这些。

企业文档问答流程，大概是：

用文档加载器读取 PDF、Markdown、DOCX
切成小段，比如每段几百字
把每段文本发给 Embedding 模型，拿到向量
存到向量数据库，比如 Milvus
用户提问题时，也用 Embedding 模型把问题变向量
用向量数据库做相似度搜索，找出最相关的几段
把这些段落当成 context，连同问题一起发给大模型
大模型生成答案

具体 Spring AI 怎么写，我……印象中有 ChatClient 之类的东西。

面试官：

流程讲得还不错，勉强能打个 POC。

Q3.4 面试官：

那你知道 AI 幻觉（Hallucination）是什么吗？在企业问答或智能客服里，我们怎么尽量减轻幻觉的影响？

小Y：

幻觉就是模型乱编呗，胡说八道，还说得特别自信那种。

减轻的话，可以：

用 RAG，让模型多参考真实文档
提示词里告诉它“如果不知道就说不知道”

我看有人做“答案引用文档来源”，让用户自己判断。

面试官：

回答方向对，但还不够系统，也没谈到安全和风控。

Q3.5 面试官：

最后一个，综合一点：

我们要在内容社区里做一个「AI 智能客服 + 风控系统」，涉及：

聊天会话内存
工具执行框架 / 工具调用标准化
Agent / Agentic RAG
安全与风控（比如敏感词、诈骗检测）

你能大致描述一个高层架构吗？可以随便说说你听过的东西。

小Y：

这个……有点复杂。

我理解：

Agent 就是一个智能体，可以根据用户问题自己决定调用哪些工具，比如查订单、查帖子、查支付记录
工具调用标准化，就是把这些能力都封装成统一的接口描述，让大模型根据描述来选用
会话内存就是记住用户之前说过的话，可能通过把历史聊天拼在一起，或者用某种“记忆”机制

风控的话，可以：

在模型前后加一层敏感词过滤
或者加一个独立的规则引擎/模型，去判断有没有风险

Agentic RAG……我猜是 Agent + RAG？让 Agent 决定什么时候用 RAG 检索知识库。

呃，我大概就知道这些名词，还没有真正搭起来过。

面试官：

行，今天就到这吧。

你整体基础还行，但在实际落地、参数调优、工程细节上还欠火候。回去之后可以针对这些方向多做一些小项目实战。

我们后续会综合评估面试结果，回去等通知。

五、答案与知识点详解（小白友好版）

下面系统拆解一下每个问题背后的业务场景和技术点，方便你像看教程一样学习。

1. UGC 发帖基础架构

1.1 发帖接口的基础设计

典型技术栈：

核心：Java 8/11/17 + Spring Boot + Spring MVC
ORM：MyBatis / JPA / Spring Data JDBC
数据库连接池：HikariCP

基础流程：

前端调用 POST /api/post/publish
后端 Controller：

@RestController
@RequestMapping("/api/post")
public class PostController {

    @PostMapping("/publish")
    public PostPublishResponse publish(@RequestBody PostPublishRequest request) {
        // 参数校验、鉴权
        // 调用 Service
    }
}

Service 层：业务逻辑（鉴权、敏感词、风控、异步消息）
DAO 层：MyBatis Mapper 执行 INSERT 到 post 表

表结构示例：

CREATE TABLE post (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  title VARCHAR(255) NOT NULL,
  content TEXT NOT NULL,
  tags VARCHAR(255),
  status TINYINT NOT NULL DEFAULT 1,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  INDEX idx_user_created (user_id, created_at)
);

1.2 Redis 缓存：帖子详情 + 热门列表

常用缓存技术：

Redis（主）
Ehcache/Caffeine（本地缓存，可结合 Spring Cache）

典型缓存模式：

缓存读写策略：
- 读：Cache-Aside 模式
  - 先读 Redis
  - 没有则读 MySQL，并写入 Redis
- 写：
  - 写数据库 + 删除 Redis 对应 Key（让下次读回源）
防止缓存问题：
- 缓存穿透：恶意请求不存在的 ID
  - 解决：对不存在的数据缓存一个短 TTL 的空值
- 缓存击穿：热点 Key 过期瞬间大量请求落 DB
  - 解决：
    - 热点 Key 不设置 TTL 或逻辑过期 + 异步刷新
    - 或者加互斥锁（Redis 分布式锁）
- 缓存雪崩：大量 Key 同时过期
  - 解决：TTL 加随机值（打散） + 多级缓存 + 限流
Spring Cache 示例：

@Cacheable(cacheNames = "post", key = "#postId")
public PostDTO getPostDetail(Long postId) {
    return postMapper.selectById(postId);
}

1.3 HikariCP + 线程池 + SQL 优化

HikariCP 核心配置：
- maximumPoolSize：最大连接数
- minimumIdle：最小空闲连接数
- connectionTimeout：获取连接超时时间
- idleTimeout：空闲连接存活时间

经验：

连接数不是越大越好，要综合：
- DB 实例最大连接数
- 应用实例数
- 平均并发

简易估算：

总连接数 ≈ DB 可承载连接数 * 0.8

单实例连接数 ≈ 总连接数 / 实例数

线程池（ThreadPoolTaskExecutor）：

@Bean
public ThreadPoolTaskExecutor taskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(8);
    executor.setMaxPoolSize(32);
    executor.setQueueCapacity(200);
    executor.setKeepAliveSeconds(60);
    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
    return executor;
}

关键点：

拒绝策略：CallerRunsPolicy / AbortPolicy 等
避免使用无界队列（容易 OOM）

SQL 优化：

基本：合理索引（主键、联合索引）
避免：全表扫描、大量 SELECT *、LIKE '%xxx'
分页：limit offset 大偏移可优化为“基于 last_id 翻页”

1.4 JVM 与 Docker/K8s 的坑

在 Docker + Kubernetes 环境：

必须关注容器的 memory limit：
- Java 8u191+ / 11+ 才能比较好地识别 cgroup 限制
- 否则 JVM 会认为自己有很多内存，导致 OOMKilled
常见配置思路：

JAVA_OPTS="-Xms512m -Xmx512m -XX:MaxMetaspaceSize=256m -XX:+UseG1GC"

监控：

使用 Micrometer + Prometheus 监控 JVM 内存、GC 次数、Pause 时间

2. 微服务、Kafka、Elasticsearch、监控

2.1 同步 RPC vs 异步消息（OpenFeign vs Kafka）

发帖后需要触发多个下游：

写 ES（search-service）
更新 feed（feed-service）

同步 RPC（OpenFeign）的问题：

发帖接口变成“分布式大事务”：任何一个服务挂了，发帖就失败
高并发下，调用链变长，整体延迟升高

更推荐：Kafka 作为事件总线：

post-service：
- 本地事务写 MySQL 成功后
- 往 Kafka Topic post_created 写一条事件
search-service & feed-service：
- 订阅 post_created
- 自己按需处理

优点：

解耦：服务之间不直接强依赖
削峰：Kafka 自带缓冲
容错：下游挂了重启后还能继续消费

2.2 Kafka：不丢、不重、不乱

不丢：

生产者：
- acks=all，retries 大于 0
Broker：
- 副本数 replication.factor >= 3
- min.insync.replicas >= 2
消费者：
- 手动提交 offset（enable.auto.commit=false）
- 先处理消息，再 commit

不重：

实际上很难做到完全“不重”，一般是 业务幂等：
- 消费端维护幂等表：processed_message(idempotent_key)
- 或根据 postId + eventType 做幂等

有序：

按用户维度有序：
- partitionKey = userId，保证同一用户消息落在同一分区
- 分区内有序

Java 接入：

使用 Spring Kafka：@KafkaListener 监听消息

2.3 Elasticsearch 索引设计

核心字段：

{
  "mappings": {
    "properties": {
      "id": {"type": "keyword"},
      "title": {"type": "text", "analyzer": "ik_max_word"},
      "content": {"type": "text", "analyzer": "ik_max_word"},
      "tags": {"type": "keyword"},
      "authorId": {"type": "long"},
      "createdAt": {"type": "date"},
      "hotScore": {"type": "float"}
    }
  }
}

关键点：

中文分词：使用 ik 分词器
精确匹配：标签/ID 用 keyword
排序：基于 hotScore + createdAt 结合
高亮：搜索接口中开启 ES 高亮配置

2.4 监控与日志：Micrometer + Prometheus + ELK

Spring Boot Actuator + Micrometer：

自动暴露：
- http.server.requests（接口耗时、状态码）
- JVM 指标
Prometheus 通过 /actuator/prometheus 拉取

Grafana：

使用 PromQL 写查询
常见看板：
- QPS
- P95/P99 延迟
- 错误率

日志链路：

应用：SLF4J + Logback / Log4j2
日志格式加入 traceId：
- Spring Cloud Sleuth / Micrometer Tracing
ELK：
- Filebeat/Logstash -> Elasticsearch -> Kibana

2.5 降级与熔断：Resilience4j

典型场景：Elasticsearch 故障或抖动

使用 Resilience4j：

熔断：
- 超时/失败比例过高 -> 打开熔断器
降级：
- 返回兜底数据（如：简单搜索、热门推荐）

示例：

@CircuitBreaker(name = "esSearch", fallbackMethod = "searchFallback")
public SearchResult search(String keyword) {
    // 调用 ES 搜索
}

public SearchResult searchFallback(String keyword, Throwable t) {
    // 返回默认结果
}

3. AIGC、RAG、向量数据库与 Agent

3.1 什么是 RAG（检索增强生成）

RAG 核心思想：

不直接让大模型“凭空瞎想”
先从 知识库 检索相关文档（检索）
再让模型基于这些文档来生成答案（生成）

在内容社区中的玩法：

AI 辅助写作：先检索相似主题的优质文章，提供给模型作为写作素材
智能搜索问答：问题 -> 检索社区内容 -> 汇总回答
企业内部知识问答：检索内部 Wiki、文档、工单

3.2 向量化、语义检索、向量数据库

向量化（Embedding）：

把一句话或一段文本变成一个高维向量（例如 768 维）
相似语义 -> 向量距离接近

语义检索流程：

文档阶段：
- 文本 -> Embedding -> 存入向量数据库
查询阶段：
- 用户问题 -> Embedding
- 用相似度搜索（余弦相似度 / 内积）找最近向量

向量数据库选择：

专业型：Milvus、Faiss（库）、Qdrant 等
轻量级：Chroma（多为 Python 生态）
通用存储 + 索引：Redis Vector Similarity（Redis 7+）、Elasticsearch 的向量字段

Java 对接方式：

使用对应 SDK / REST API
步骤：
- 调用 Embedding 模型（OpenAI / Ollama / 本地模型）
- 构造 VectorRecord：{ id, vector: float[], metadata }
- 调用向量库的 insert/search 接口

3.3 用 Spring AI 搭建企业文档问答（RAG）

组件：

文档加载：
- 可用 Spring AI 的文档支持或自写解析（Apache POI 读 Word/Excel）
文本切块：
- 按段落 / 按固定长度切片
Embedding 模型：
- OpenAI Embedding
- 或本地 Ollama 模型
向量存储：
- Milvus / Redis Vector / Elasticsearch
对话：
- Spring AI 的 ChatClient / OpenAiChatModel

大致流程：

离线构建：
- 加载文档 -> 切块 -> Embedding -> 向量库
在线问答：
- 用户问题 -> Embedding
- 向量库检索 topK 文档片段
- 拼接成 prompt：系统提示 + 文档片段 + 用户问题
- 调用大模型生成答案

3.4 AI 幻觉与缓解策略

幻觉（Hallucination）：

模型编造事实、胡说八道、一本正经输出错误信息

缓解方式：

RAG：
- 让模型尽量从真实文档中抽取/总结，而不是凭空生成
提示工程（Prompting）：
- 明确要求：
如果你在文档中找不到答案，请明确回答“我不知道”或“文档中没有相关信息”。
引用来源：

在回答中附带引用的文档标题、ID、链接

边界控制：

不让模型回答法律、医疗、金融建议（或加强人工审核）

风控 & 审核：

对模型输出二次过滤：
- 敏感词、色情、暴力、政治
- 诈骗/钓鱼信息识别

3.5 Agent、工具调用、Agentic RAG、会话内存

Agent（智能体）：

不是简单的“问答模型”，而是可以：
- 解析用户意图
- 自主决定调用哪些工具
- 规划执行顺序

工具调用标准化：

每个工具（如“查订单”、“查帖子”、“查支付记录”）用统一 schema 描述：
- 名称
- 入参/出参
- 功能说明
模型根据 schema 选择工具并构造参数

Agentic RAG：

把“是否做检索”“检索哪些库”“如何组合结果”的决策交给 Agent
Agent 可以在多个知识库之间游走：
- 公共 FAQ
- 业务文档
- 工单系统

会话内存（Chat Memory）：

让模型记住历史上下文的几种方式：
- 简单：把最近 N 轮对话拼在 prompt 中
- 稀疏记忆：只保留重要信息
- 向量化记忆：把历史对话向量化，按需召回

安全与风控集成：

在整体 Agent 工作流中增加：
- 请求前过滤（敏感问题拦截）
- 响应后过滤（输出内容整改）
- 风控模型：判断诈骗、异常行为（配合 Kafka + 实时流处理：Flink/Spark Streaming）

4. CI/CD、容器化与环境

虽然对话里没细问，但在大厂面试中，基础的 CI/CD 也很重要：

构建工具：Maven / Gradle
CI/CD：Jenkins / GitLab CI / GitHub Actions
容器：Docker
编排：Kubernetes

流水线一般包括：

代码提交到 Git -> 触发 CI
单元测试（JUnit 5、Mockito）、集成测试
打包 Docker 镜像
推送到镜像仓库
使用 Helm / K8s YAML 部署到测试/生产环境

监控 + 日志 + 告警全链路打通，是大厂后端工程师的必备技能。

六、小结：小Y 哪些地方能过关，哪些会被卡？

能过关的：
- Spring Boot 基础、MyBatis、Redis、Kafka、ES、监控等概念
- 知道主流技术名词：Spring Cloud、Resilience4j、Spring AI、RAG、向量数据库
容易被卡的：
- 参数级、实战级细节（HikariCP、线程池、Kafka 幂等 & 有序、ES mapping 优化）
- AI 相关的工程化：Agent 设计、向量库具体选型与接入、安全和风控落地方案

如果你现在的水平和小Y差不多，可以参考本文的答案部分，一条条补：