大厂 Java 面试实录：从音视频内容社区到 AI RAG 的全链路技术设计

场景：互联网大厂音视频 + 内容社区业务线 Java 面试。主角：严肃的面试官 & 搞笑又有点水的候选人------小 Y。

一、第一轮：基础业务与整体架构设计

业务背景：做一个类似「短视频 + 图文内容社区」的 App，支持推荐流、关注流、评论、点赞、收藏、搜索等，后续还要接入 AIGC 自动生成内容。

Q1：整体系统架构如何设计？用到哪些 Java 技术栈？

面试官： 我们先从整体出发。如果让你设计一个短视频 + 图文的内容社区系统，你会怎么做整体架构？重点说说你会用什么 Java 技术栈，以及为什么这么选。

小 Y： 这个...整体上肯定是微服务嘛，用 Spring Boot 和 Spring Cloud 搭一套就行了。前面放个网关，用 OpenFeign 调服务，注册中心用 Eureka 或者 Nacos，负载均衡嘛...反正 Spring Cloud 全家桶都可以。数据库就 MySQL，缓存用 Redis，MQ 用 Kafka。日志就 Logback 吧，监控可以上 Prometheus 和 Grafana。大概就这样。

面试官： 微服务 + Spring Cloud 的方向还可以，但你说得太「云」了，业务拆分和关键组件选型都没展开，下次回答的时候要把「系统划分 + 组件职能」说清楚。这个问题先往下，我们后面再细抠。

Q2：你会怎么划分微服务？和业务功能怎么对应？

面试官： 那具体到业务，你会怎么拆服务？比如用户、内容、推荐、搜索、互动这些，你打算怎么拆，为什么这么拆？

小 Y： 这个...就按业务名拆嘛。用户服务、内容服务、评论服务、点赞服务、搜索服务、推荐服务、支付服务、通知服务......然后再搞个网关服务，呃，还有...嗯，差不多就这些。

面试官： 按业务名拆是一种直觉，但你要体现出职责边界 和数据边界 ，以及访问路径。你刚才只是列了个清单。等会儿我们会在答案里详细给出一个拆分示例，你回去要多练习「从入口 → 业务流程 → 服务调用」这条线。

Q3：短视频上传和播放链路你会怎么设计？涉及到哪些组件？

面试官： 我们聚焦到「音视频」场景：用户上传一个短视频，到其他用户可以流畅播放，中间会经过哪些步骤、涉及哪些服务？你可以简单说一下链路。

小 Y： 呃...用户上传视频到后端，后端存一下，然后...再给个播放地址。中间可能会转码吧，用个任务队列，转码完了就可以播放了。组件的话，就 Spring Boot 写个上传接口，Kafka 发个消息，然后有个转码服务消费消息，处理完后写数据库...具体嘛，我实习的时候看过类似的。

面试官： 有点印象，但是漏了不少关键点，比如存储选型、CDN、元数据管理等。没关系，后面答案会展开，让你有一个比较完整的音视频链路概念。

Q4：在高并发下，如何保证内容详情页的性能？

面试官： 热门视频/图文内容详情页如果被高频访问，你会怎么优化性能？会用到哪些缓存方案？

小 Y： 这个我知道，用 Redis 缓存！可以用 Spring Cache 或者直接用 RedisTemplate，把内容缓存到 Redis 里，然后加上过期时间...呃，还可以用本地缓存，比如 Caffeine 做个二级缓存，减少 Redis 压力。热点数据就多缓存一下。

面试官： 这个回答就比较具体了，提到 Redis + Caffeine 的多级缓存就不错，也知道 Spring Cache。后面我们会在答案里帮你补充缓存穿透、击穿、雪崩的一些手段。

Q5：接口如何对外暴露？REST API 怎么管理？

面试官： 那这些服务对外的接口你打算怎么管理？比如版本、文档、测试联调？

小 Y： 一般就是写 REST 接口，用 Spring MVC 或 Spring WebFlux 做 Controller，然后用 Swagger...嗯，现在叫 OpenAPI 规范，自动生成接口文档。对外可以统一从网关暴露，像 Spring Cloud Gateway 或者 Nginx 也行。版本的话，在 URL 里加 /v1 /v2，或者用 Header 搞一下。

面试官： 这个还可以，基本点都算答到了。

二、第二轮：可靠性、监控与消息队列

业务继续：系统用户量上来了，活动期间有大流量，要求高可用、可观测、可回溯。

Q6：微服务之间调用失败怎么处理？如何做熔断限流？

面试官： 微服务之间总会有失败，你会怎么保证整体的稳定？比如推荐服务依赖用户画像服务，如果用户画像挂了怎么办？

小 Y： 这个用...以前 Netflix OSS 里的 Hystrix，现在不太用了，可以用 Resilience4j 做熔断和限流。比如服务调用失败到一定阈值，就打开断路器，走降级逻辑。限流的话，可以在网关做，也可以用令牌桶之类的算法。整体就这些吧。

面试官： 方向对，能说出 Resilience4j 已经不错。不过你没提到具体降级策略，比如推荐可以退化成通用热门榜。等会儿在答案里我们帮你补全一个比较完整的思路。

Q7：你会怎么设计消息队列在系统中的作用？Kafka 怎么用？

面试官： 刚才你说短视频转码用 Kafka。整个内容社区系统中，你还会在哪些场景用消息队列？Kafka、RabbitMQ、Redis Pub/Sub 你会怎么选？

小 Y： 消息队列的话...呃，像点赞、收藏这些可以异步写统计，用 Kafka 发消息给统计服务。通知推送也可以用 MQ。Kafka 适合高吞吐日志、行为埋点那种；RabbitMQ 适合业务消息比较复杂的确认和路由；Redis Pub/Sub 就简单通知用用。我之前项目里主要用 Kafka，其他就...了解。

面试官： 对 Kafka 的定位算是说到了，但和业务场景的结合还是略泛。后面我们会给出一个「内容社区里的 MQ 使用清单」，让你更有画面感。

Q8：监控与日志怎么做？如何定位线上问题？

面试官： 大厂很看重可观测性。如果你的系统线上出现接口超时、报错，你会用哪些工具去排查？你会怎么埋点和打日志？

小 Y： 监控的话，可以用 Micrometer 把指标暴露给 Prometheus，然后在 Grafana 上画看板。日志就用 Logback 结合 SLF4J，输出到 ELK（Elasticsearch + Logstash + Kibana）里，方便检索。链路追踪可以用 Zipkin 或 Jaeger，通过 traceId 关联请求链路。排查问题就看错误日志、慢查询、接口耗时分布之类。

面试官： 这个回答比较完整，工具链也成体系了，说明你对观测这块有一定了解。

Q9：数据库层如何保证高可用与数据一致性？

面试官： 我们说说数据库：内容数据、用户数据、互动数据非常多，你会用什么方案保证高可用和数据一致性？顺便说说你对 ORM 和连接池的选型。

小 Y： 数据库高可用可以用主从、读写分离，再加上分库分表之类... 一致性嘛，重要操作尽量用事务...比如 Spring 事务 + JPA 或 MyBatis，隔离级别就...默认就行吧。连接池可以用 HikariCP，比 C3P0 快。ORM 就 Hibernate、JPA、MyBatis，看项目情况选。

面试官： 你显然对这块没太深入思考。事务的隔离级别、分布式事务、热点库表这些都没提到。不过至少你知道 HikariCP、JPA、MyBatis，说明用过。详细的设计我们在文末答案里展开，你回去好好看。

Q10：如何做接口灰度发布与回滚？

面试官： 系统迭代很快，你怎么做灰度发布？比如新版本推荐算法上线，只让 5% 的用户先用，出问题能快速回滚？

小 Y： 灰度的话，可以通过 Kubernetes 滚动发布，用 Jenkins 或 GitLab CI 做 CI/CD，然后在网关按用户 ID 或标签做流量分配...呃，或者用 Nginx 做。回滚就...把 Deployment 回滚到上一个版本，或者重新部署旧版本镜像。配置可以用 Spring Cloud Config 或 Nacos 管理。

面试官： 思路还算 OK，但缺少细化，比如灰度标识、埋点指标、回滚策略。待会儿答案里会有一个「灰度发布小模板」，可以直接记下来。

三、第三轮：接入 AIGC & RAG 能力

业务升级：内容社区要引入 AI 能力。包括：

帮创作者生成标题、文案、标签（AIGC）

为用户提供智能问答和搜索（RAG + 语义检索）

对内容进行风控审查（AI+规则引擎）

Q11：如何为内容社区接入 AIGC 生成功能？

面试官： 产品经理说，创作者上传视频后，希望自动生成标题、文案、标签，辅助创作。你会怎么从后端架构上设计这一块？可以涉及到 Spring AI、RAG、向量库等。

小 Y： 嗯...那就搞一个 AI 服务吧，单独一个微服务。然后...用 Spring AI 调 OpenAI 或者其他模型接口，拿到结果。传进去视频的字幕或者文案，模型输出标题和标签。向量库的话也可以用，比如 Redis 或者 Milvus，存一些东西...大概这样。

面试官： 你知道要抽象出 AI 服务，这个方向对。但你提到 RAG 和向量库的时候明显有点虚。RAG 怎么和「创作辅助」挂上关系，你没讲明白。后面答案会给一个典型的接入流程。

Q12：什么是 RAG？在内容社区里怎么用？

面试官： 那你说说 RAG 是什么？在我们这个内容社区场景里，有哪些具体可落地的玩法？

小 Y： RAG...是检索增强生成，Retrieval-Augmented Generation。先检索文档再让大模型回答。内容社区的话...可以让用户问问题，然后从内容库里检索相关视频和文章，再让模型生成回答，就类似智能搜索吧。呃，具体的话...可以用向量数据库做语义检索，用 Embedding 模型，比如 OpenAI 的，或者本地 Ollama，那种...

面试官： 这次说得还不错，基本定义和大致玩法都有了。后面我们会补充一个 RAG 流程图（文字描述版），你可以记下来用在别的面试上。

Q13：如何实现语义搜索和向量化？技术链路如何？

面试官： 如果要做「视频 / 图文内容的语义搜索」，不只是关键词匹配，你会怎么设计向量化和检索的链路？

小 Y： 这个...就是把内容文本用 Embedding 模型向量化，存到 Milvus 或者 Chroma、Redis 里。搜索的时候，把用户的查询也向量化，然后去算相似度，取 TopK 结果，再返回给用户。后端流程就差不多。怎么落地嘛...可以写个服务，呃，用 Spring Boot 写。

面试官： 核心步骤你说到了，就是有点「只会背公式」。文末我们会给一个更贴近工程实践的设计，包括数据更新、增量向量化等。

Q14：Agentic RAG 和普通 RAG 有什么区别？在复杂工作流怎么用？

面试官： 我们这条业务线最近在做「智能客服系统」，需要支持复杂工作流，比如：先根据用户问题检索文档，再调用内部工具查询订单，最后帮用户发起退款申请。你理解的 Agent 或 Agentic RAG 是怎么回事？怎么和工具调用结合？

小 Y： Agent...就是让模型更智能一点，它可以自己决定下一步干嘛。Agentic RAG...就是在 RAG 的基础上，再加上工具调用吧。比如模型可以先检索知识库，再决定要不要调用查询订单的接口，然后再生成回答。工具调用有 MCP、还有...Google 的什么东西...我有点忘了，反正就是标准化模型和工具的交互。

面试官： 虽然有点含糊，但至少知道「RAG + 工具调用 + 决策」这几个关键词，也知道 MCP 这种模型上下文协议。具体工程化落地你还不太清楚，文末会有一节专门讲。

Q15：如何减少 AI 幻觉（Hallucination），保证回答可靠？

面试官： 在企业文档问答、客服、医疗类问答里，AI 幻觉是个大问题。你觉得后端在设计时，可以从哪些方面降低幻觉风险？

小 Y： 呃...这个...可以用 RAG 嘛，让模型有文档可参考就不乱编了。然后...可以在提示词里强调不要乱编...还有可以在回答里加引用来源。要是很重要的场景，可以让人审核一下，或者给出多个备选。具体怎么设计...

面试官： 你知道几个关键手段，比如 RAG、提示词约束、引用来源、人工审核，但没形成体系。最后的答案部分会给你一套「降低幻觉的清单」，你照着背也能应付大多数面试。

四、面试结束话术

面试官： 今天先面到这里。整体看，你的基础还可以，但在系统设计和 AI 落地这块还比较泛，很多点只停留在「听说过」。我们会综合评估一下，你先回去等通知吧。

小 Y（心里 OS）： 完了完了，又是「回去等通知」...

五、详细解析：从零拆解业务场景与技术点

下面是对上面问题的系统化答案与延展说明，按模块整理，方便小白学习和有经验的人查漏补缺。

1. 整体架构设计与微服务拆分（对应 Q1、Q2、Q3、Q5）

1.1 业务场景

类似抖音 / 小红书的短视频 + 图文内容社区
场景包括：
- 视频上传、转码、审核、发布、播放
- 内容流（推荐流 / 关注流）、评论、点赞、收藏
- 搜索与话题、标签体系
- 后续接入 AIGC（标题/文案生成）与智能搜索（RAG）

1.2 技术栈总览

核心：Java 17 + Spring Boot 3.x
Web：Spring MVC（主接口），少量高并发场景可用 Spring WebFlux
微服务：Spring Cloud Alibaba / Spring Cloud + OpenFeign + Gateway
注册 / 配置：Eureka / Consul / Nacos + Spring Cloud Config
构建：Maven（主）、Gradle（部分服务也可）
数据：
- 业务数据：MySQL / PostgreSQL + MyBatis / Spring Data JPA
- 内容索引：Elasticsearch
- 时序数据 & 监控：Prometheus
缓存：Redis + Caffeine（本地二级缓存）
MQ：Kafka（行为、日志、转码任务）、RabbitMQ（关键业务消息）
CI/CD & 部署：GitLab CI 或 GitHub Actions + Jenkins + Docker + Kubernetes

1.3 微服务拆分示例

以「职责 + 数据边界」拆分，例如：

API Gateway 服务
- 基于 Spring Cloud Gateway 或 Nginx
- 功能：统一入口、鉴权、灰度、限流、路由
用户服务
- 用户注册、登录、资料、关系（关注/粉丝）
- 数据库：user_db
内容服务（Content Service）
- 视频/图文的元数据：标题、描述、封面、标签、作者等
- 内容发布、下架、编辑
- 数据库：content_db
媒体服务（Media Service）
- 视频上传、转码、截图、存储
- 对接对象存储（S3、OSS、COS）与 CDN
- 使用 MQ（Kafka）接收转码任务
互动服务（Interaction Service）
- 点赞、收藏、评论、转发等
- 用 Redis 记录计数 & 排行，落盘到 DB 做最终一致
推荐服务（Recommend Service）
- 推荐流生成，调用用户画像、内容特征
- 使用 Kafka 消费行为日志
搜索服务（Search Service）
- 构建 Elasticsearch 索引
- 提供关键字搜索与基础语义搜索接口
通知服务（Notification Service）
- 站内信、Push、短信、邮箱等
- 消费 MQ 里的事件消息（如有人评论你的视频）
AI 服务（AI Service）
- AIGC：标题、文案、标签生成
- RAG：语义搜索、企业文档问答
- 封装 Spring AI / HTTP 调用外部大模型
风控与审计服务（Risk Service）
- 内容审核（涉黄、涉暴、敏感词）
- 账号行为风控（刷量、黑产）

业务流程一般形式：

App → API Gateway → 各业务服务 → DB/缓存/MQ → 监控/日志

1.4 短视频上传与播放链路（Q3）

上传
- 客户端：分片上传至上传网关（可直接上传到对象存储，后端只收回调）
- 网关：鉴权、限流、简单校验
媒体服务处理
- 将上传完成事件写入 DB（视频元数据），设置状态为 UPLOADING / PROCESSING
- 往 Kafka 发送转码任务消息 topic=video-transcode
转码服务
- 消费 video-transcode 主题
- 使用 FFmpeg 等工具转码多码率（1080p/720p/480p）
- 转码完成后上传至对象存储，生成不同清晰度的播放地址
- 更新内容服务中的视频状态为 READY
CDN 分发
- 播放链接指向 CDN 域名，对象存储作为源站
- 客户端根据网络情况自适应选择码率（HLS/DASH）
播放
- 前端请求内容服务获取视频详情（包含播放 URL 列表）
- 播放器根据网络 & 缓冲策略进行播放

技术点：

Spring MVC / WebFlux 接口
Kafka 可靠消息投递
对象存储 + CDN
状态机（UPLOADING → PROCESSING → READY → BLOCKED）

1.5 接口管理与 OpenAPI（Q5）

使用 Spring Boot + Spring MVC 编写 REST API
使用 springdoc-openapi 或 Swagger 自动生成接口文档
为每个服务提供 /v1/**、/v2/** 等版本前缀
在 API Gateway 层做统一路由、限流、鉴权

2. 高并发与可靠性设计（对应 Q4、Q6、Q7、Q9、Q10）

2.1 内容详情页性能优化（Q4）

目标：热门内容详情页的 QPS 非常高，需要低延迟、高稳定。

常见手段：

多级缓存
- 本地缓存：Caffeine
- 分布式缓存：Redis
缓存模式
- Cache Aside（旁路缓存）：
  - 读：先查缓存 → 缓存 miss → 查 DB → 写缓存
  - 写：更新 DB → 删除缓存
热点内容预热
- 活动前预热热门内容到 Redis
- 定时任务 + Kafka 行为日志分析
避免缓存问题
- 穿透：对不存在的数据加空值缓存 + 布隆过滤器
- 击穿：热点 Key 使用互斥锁 / 分布式锁
- 雪崩：过期时间增加随机值，错开集中失效

2.2 微服务容错：熔断、限流、降级（Q6）

使用 Resilience4j 实现：
- 熔断（Circuit Breaker）
- 限流（Rate Limiter）
- Bulkhead（舱壁隔离）

示例场景：

推荐服务调用用户画像服务超时过多 → 打开熔断 → 推荐服务执行降级逻辑：
- 返回通用热门内容
- 或者 fallback 到简单逻辑（根据全站点击率）

限流策略：

网关层：按用户、IP、接口级别限流
服务层：针对短时间内高频写操作（比如点赞、评论）做限流

2.3 消息队列在内容社区中的典型用法（Q7）

行为日志与埋点（Kafka）
- 用户浏览、点赞、分享等行为发送到 Kafka
- 推荐服务、统计服务消费
异步任务（Kafka / RabbitMQ）
- 视频转码、封面截图、审核请求
事件通知（RabbitMQ）
- 有人评论 / 点赞你的内容 → 通知服务消费 → 发送站内信/Push
缓存更新
- 重要数据更新后，通过 MQ 发布事件，各节点订阅并更新本地缓存

选型建议：

Kafka：行为日志、埋点、转码任务、流式计算
RabbitMQ：对可靠性和路由规则要求较高的业务事件
Redis Pub/Sub：轻量通知，不要求持久化

2.4 数据库高可用与一致性（Q9）

高可用
- 主从复制 + 自动故障转移
- 读写分离（内容详情读取量大）
- 分库分表：
  - 按用户 ID / 内容 ID 分片
ORM 与连接池
- MyBatis：写 SQL 灵活，适合复杂查询
- JPA/Hibernate：适合模型相对稳定的领域
- 连接池：首选 HikariCP（轻量高性能）
一致性策略
- 强一致：单库事务 + 合理设置事务隔离级别（一般 READ COMMITTED）
- 最终一致：通过 MQ + 重试机制
- 分布式事务：
  - 能避免就避免，多使用 TCC / 本地消息表方案

2.5 灰度发布与回滚（Q10）

CI/CD 流程
- Git → GitLab CI / GitHub Actions → Jenkins → Docker 镜像 → Kubernetes 部署
灰度机制
- 在网关层对用户打标签（AB 分组、地区、设备类型）
- 基于 Header / Cookie / 用户 ID 做路由规则
回滚策略
- Kubernetes：保留若干旧版本 Deployment，支持一键 rollback
- 配置变更：使用配置中心（Spring Cloud Config/Nacos），可快速回滚配置
灰度监控指标
- 接口错误率、响应时间、用户行为（留存、转化）
- 若超过阈值，自动或手动回滚

3. 监控、日志与可观测性（对应 Q8）

3.1 指标监控（Metrics）

使用 Micrometer 统一采集指标：
- QPS、响应时间、异常数
- JVM 指标：GC 次数、堆内存、线程数
Prometheus 抓取 /actuator/prometheus 指标
Grafana 进行可视化展示和告警

3.2 日志系统（Logging）

日志框架：Logback + SLF4J
日志输出到：
- 本地文件 + Logstash → Elasticsearch → Kibana
规范：
- 统一日志格式（JSON）
- 每个请求携带 traceId / spanId 方便串联

3.3 分布式链路追踪

使用 Zipkin 或 Jaeger
在网关注入 traceId，向下游透传
通过 UI 查看全链路调用耗时，快速定位慢点

4. AI 接入、RAG 与 Agent（对应 Q11--Q15）

4.1 AIGC 内容生成（Q11）

场景：创作者上传视频后，希望系统自动生成：

标题
摘要/文案
Tag/话题

基本流程：

数据准备
- 对视频进行 ASR（语音转文本），得到字幕稿
- 对图文内容直接使用正文
调用 AI 服务
- AI 服务封装 Spring AI 或 HTTP 调用大模型（OpenAI / 内部模型）
- Prompt 示例：
  - 「请根据以下字幕内容，生成 3 个适合短视频平台的中文标题，并为每个标题推荐 5 个标签。」
结果落地
- AI 返回候选标题 + 标签
- 写入内容服务的草稿字段，用户可编辑后发布
技术点
- Spring Boot + Spring AI
- 调用外部 LLM 接口，注意重试、限流、监控

4.2 RAG 基本概念与内容社区落地（Q12）

RAG（Retrieval-Augmented Generation）：

先「检索相关内容」，再「让大模型基于检索结果生成回答」，减小幻觉，提高专业度。

在内容社区的几个用法：

智能搜索 / 问答
- 用户问：「如何用 Spring Boot 实现视频上传？」
- 系统在内容库中检索相关视频与文章
- 将这些内容摘要 + 链接提供给模型，让模型给出答案 + 推荐内容链接
企业知识库问答
- 针对内部文档（产品说明、运营规程），为运营人员、客服提供问答接口

4.3 语义搜索与向量化链路设计（Q13）

向量化过程
- 对内容文本（标题 + 摘要 + 部分正文）调用 Embedding 模型
- 得到高维向量（例如 1536 维）
向量存储
- 使用向量数据库：Milvus、Chroma 或 Redis Vector
- 记录内容 ID、向量、元信息（tag、作者、时间）
检索流程
- 用户输入查询（自然语言）
- 将查询向量化
- 在向量库中基于余弦相似度 / 内积检索 TopK
- 返回结果列表，同时可联动 ES 做关键词过滤
增量更新
- 新内容发布 / 编辑 → 通过 MQ 通知向量服务
- 向量服务生成向量并写入向量库

4.4 Agent 与 Agentic RAG 实战思路（Q14）

Agentic RAG = RAG + 工具调用 + 决策能力。

在「智能客服系统」中的典型流程：

用户提问：
- 「我昨天买的会员没到账，帮我查一下。」
Agent 思考：
- 先检索文档，看有没有通用处理流程（RAG）
- 再调用「订单查询工具」获取用户最近订单
- 发现订单状态异常 → 再调用「补单工具」或「工单创建工具」
最终回答：
- 告诉用户处理结果（补发成功 / 已创建工单）
- 引用相关规则文档片段

技术点关键词：

工具调用框架：
- MCP（模型上下文协议，统一模型与工具的接口）
- 自研工具调用标准（JSON Schema 描述工具）
Agent 框架：
- 基于 Spring Boot 封装一层，定义工具集合、对话状态、记忆

4.5 降低 AI 幻觉的实践清单（Q15）

从后端工程角度：

使用 RAG
- 为每个回答提供相关文档片段
- 限制模型只能基于提供的文档回答
Prompt 设计
- 明确要求：
  - 「如果文档中没有答案，请直接回答『文档中没有明确说明』，不要推测。」
答案可追溯
- 在回答中附带引用文档标题、段落 ID、链接
多模型校验（高风险场景）
- 重要业务可使用两个模型交叉验证
人工审核
- 医疗、金融、风控类场景，对部分回答进行人工复审
日志与反馈
- 记录用户对回答的评分或反馈
- 将错误案例回流到训练 / Prompt 优化

六、小结

通过这场「大厂音视频 + 内容社区 Java 面试」的故事，我们串联了：

微服务拆分与 Spring Boot / Spring Cloud 选型
缓存、消息队列、数据库高可用、监控与日志体系
音视频上传、转码、播放的端到端链路
AIGC、RAG、Agentic RAG 在内容社区与智能客服中的落地方式

你可以把这篇当作一个「面试复盘 + 学习目录」，对照自己的项目经验，一个模块一个模块地补齐。下次如果再遇到类似场景，就不会像小 Y 那样「听过但说不全」了。