前端八股文面经大全：腾讯PCG前端暑期二战一面·深度解析（2026-04-22）·面经深度解析

前言

大家好，我是木斯佳。

相信很多人都感受到了，在AI浪潮的席卷之下，前端领域的门槛在变高，纯粹的"增删改查"岗位正在肉眼可见地减少。曾经热闹非凡的面经分享，如今也沉寂了许多。但我们都知道，市场的潮水退去，留下的才是真正在踏实准备、努力沉淀的人。学习的需求，从未消失，只是变得更加务实和深入。

这个专栏的初衷很简单：拒绝过时的、流水线式的PDF引流贴，专注于收集和整理当下最新、最真实的前端面试资料。我会在每一份面经和八股文的基础上，尝试从面试官的角度去拆解问题背后的逻辑，而不仅仅是提供一份静态的背诵答案。无论你是校招还是社招，目标是中大厂还是新兴团队，只要是真实发生、有价值的面试经历，我都会在这个专栏里为你沉淀下来。专栏快速地址

温馨提示：市面上的面经鱼龙混杂，甄别真伪、把握时效，是我们对抗内卷最有效的武器。

面经原文内容

📍面试公司：腾讯PCG-腾讯视频

🕐面试时间：近期

💻面试岗位：前端暑期二战一面

❓面试问题：

什么是闭包，什么时候会用到
电商项目中，如何将FCP从3.3优化到1.8
WebP与PNG、JPG图片格式区别
SSE跟WebSocket的区别
流式对话中响应中断如何处理
Agent中react模式是怎样的
Skills、MCP、CLI三者区别与优缺点
什么是状态机，语音输入为什么要用状态机
封装组件需要遵循哪些原则
AI聊天对话框如何实现，怎么承接SSE流式返回
AI流式输出图片、PDF、富文本、Markdown、交互组件如何统一渲染
用户个人知识库搭建与完整使用流程
文档上传后解析、分块、向量化、入库、检索全流程
自研知识库和普通桌面AI上传文档问答区别、项目初衷
Monorepo大仓与传统单层单体架构优缺点对比
Monorepo和微前端是不是同一个东西，区别是什么
业界主流大仓、模块化工程方案有哪些
为什么需要微前端，解决什么痛点
常见微前端框架及各自特点
微前端适用场景与优缺点
对Harness Engineering的理解
Agent人机等待、表单确认、对话交互闭环实现深度

来源：牛客网暑期实习必拿offer

💡 木木有话说（刷前先看）

腾讯PCG这场二面，是一份"AI应用+工程化"深度结合的面经。问题覆盖：性能优化（FCP从3.3到1.8）、AI对话（SSE中断、Agent ReAct模式、Skills/MCP/CLI）、知识库RAG全流程、Monorepo与微前端对比、组件封装原则......每一题都是生产级AI应用的实战问题。面试官显然对AI工程化落地 有很深的理解，这份面经适合已经有一定AI项目经验、准备冲击大厂AI方向的同学反复研读。

📝 腾讯PCG前端暑期二战一面·深度解析

🎯 面试整体画像

维度	特征
面试风格	AI工程化深挖型 + 实战落地型 + 架构对比型
难度评级	⭐⭐⭐⭐（四-五星，AI+RAG+微前端+工程化全面覆盖）
考察重心	AI对话（SSE/中断/统一渲染）、知识库RAG、Agent模式、工程化（Monorepo/微前端）
特殊之处	问题高度集成，每道题都是生产级AI应用的真实场景

🔍 逐题深度解析

二、电商项目中，如何将FCP从3.3优化到1.8

回答思路：FCP（First Contentful Paint）是首屏内容绘制时间，优化需从资源加载、渲染路径入手。

具体优化措施：

优化方向	具体手段	预期收益
关键CSS内联	首屏CSS内联到`<head>`，非关键CSS异步加载	减少1次RTT
资源预加载	`<link rel="preload">`预加载关键字体、图片	提前加载
图片优化	WebP格式、响应式图片、懒加载	减少传输体积
字体优化	`font-display: swap`，避免字体闪烁	提升感知速度
减少阻塞	`async`/`defer`加载JS，避免阻塞渲染	加快首次绘制
CDN加速	静态资源走CDN，就近访问	减少延迟

html 复制代码

<!-- 关键优化示例 -->
<head>
  <!-- 内联关键CSS -->
  <style>/* 首屏样式 */</style>
  <!-- 预加载关键资源 -->
  <link rel="preload" href="/font.woff2" as="font" crossorigin>
  <!-- 非关键JS异步加载 -->
  <script src="non-critical.js" async></script>
</head>

三、WebP与PNG、JPG图片格式区别

格式	特点	适用场景	压缩类型	透明度	动画
JPG/JPEG	有损压缩，体积小	照片、复杂图像	有损	❌	❌
PNG	无损压缩，支持透明	Logo、截图、需要透明的图	无损	✅	❌
WebP	有损/无损可选，体积比JPG小25-35%	现代Web通用	两者兼有	✅	✅

选型建议：

照片/大图 → WebP（兼容性降级JPG）
Logo/图标 → PNG或WebP
需要动画 → WebP或GIF

html 复制代码

<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="fallback">
</picture>

六、Agent中ReAct模式是怎样的

回答思路 ：ReAct = Reasoning + Acting，是Agent的核心推理模式。

工作流程：

Thought（思考）：模型分析当前状态，推理下一步做什么
Action（行动）：执行具体操作（调用工具、搜索、计算）
Observation（观察）：获取行动结果
循环：将Observation纳入上下文，重复Thought→Action→Observation，直到任务完成

python 复制代码

# ReAct伪代码
while not task_complete:
    thought = llm.think(state)      # 思考
    action = execute_tool(thought)  # 行动
    state = observe(action)         # 观察

示例：问"今天北京天气"

Thought：需要查询天气，调用天气API
Action：get_weather(city='北京')
Observation：返回"25°C，晴"
最终回答："今天北京25°C，晴朗"

七、Skills、MCP、CLI三者区别与优缺点

概念	定义	优点	缺点
Skill	预定义能力单元，封装特定任务的Prompt+工具	开箱即用、易组合	灵活性低、需预先开发
MCP	模型上下文协议，标准化Agent与工具交互	跨平台、可扩展	相对较新、生态待完善
CLI	命令行工具，Agent可通过shell执行命令	功能强大、系统级操作	安全风险高、输出需解析

适用场景：

Skill：固定任务（代码审查、生成测试）
MCP：需要工具生态集成的场景
CLI：服务器运维、文件处理

八、什么是状态机，语音输入为什么要用状态机

定义：状态机由状态、事件、转换组成，在特定状态下接收事件，执行动作并迁移到新状态。

语音输入中的应用：

状态定义：空闲、录音中、识别中、识别完成
事件：用户点击、语音开始、语音结束、超时
避免竞态：录音中再次点击停止，需根据当前状态决定行为

javascript 复制代码

// 语音输入状态机示例
const states = {
  idle: { onStart: () => toListening },
  listening: { 
    onStop: () => toRecognizing,
    onTimeout: () => toIdle 
  },
  recognizing: { onComplete: (text) => toIdle, onError: () => toIdle }
}

九、封装组件需要遵循哪些原则

回答思路：参考之前面经的组件设计原则。

核心原则：

单一职责：一个组件只做一件事
开闭原则：对扩展开放，对修改关闭（使用props/插槽）
组合优于继承：通过组合构建复杂组件
高内聚低耦合：组件内部紧密，组件间独立
可测试性：依赖可注入，便于单元测试
命名清晰：组件名、props名语义明确

十一、AI流式输出图片、PDF、富文本、Markdown、交互组件如何统一渲染

回答思路 ：核心是消息类型系统 + 自定义渲染器。

设计方案：

消息结构 ：定义统一的消息格式，包含type和content

javascript 复制代码

// 消息类型枚举
const MessageType = {
  TEXT: 'text',
  MARKDOWN: 'markdown',
  IMAGE: 'image',
  PDF: 'pdf',
  COMPONENT: 'component'  // 交互组件
}

// 消息结构
{
  id: 'msg_123',
  type: MessageType.MARKDOWN,
  content: '# 标题\n内容...',
  metadata: { language: 'zh' }
}

流式接收 ：通过SSE接收chunk，根据type路由到不同渲染器
渲染器注册表：

javascript 复制代码

const renderers = {
  [MessageType.TEXT]: TextRenderer,
  [MessageType.MARKDOWN]: MarkdownRenderer,
  [MessageType.IMAGE]: ImageRenderer,
  [MessageType.PDF]: PDFRenderer,
  [MessageType.COMPONENT]: ComponentRenderer
}

function MessageRenderer({ message }) {
  const Renderer = renderers[message.type]
  return <Renderer content={message.content} />
}

增量渲染：Markdown需处理代码块截断问题，图片需显示加载进度

十二、用户个人知识库搭建与完整使用流程

回答思路：从数据采集到检索生成的全链路。

完整流程：

文档上传：用户上传PDF、Word、Markdown等
文档解析：提取文本内容（pdf.js、mammoth）
智能分块：按语义/段落切分，保留重叠
向量化：调用Embedding模型生成向量
存储：向量存入向量数据库（Pinecone、Milvus），原文存入对象存储
查询检索：用户提问 → 向量化 → 相似度检索 → 召回Top-K文档
上下文构建：将召回文档与问题组合成Prompt
生成回答：LLM生成答案，附上引用来源

十三、文档上传后解析、分块、向量化、入库、检索全流程

回答思路：这是RAG系统的核心链路。

详细流程：

阶段	动作	技术方案
解析	提取文本内容	pdf.js、mammoth、unstructured
分块	语义/固定大小切分	按段落、标题、500字符+50重叠
向量化	文本→向量	OpenAI Embedding、BGE、text2vec
入库	存储向量+元数据	Pinecone、Milvus、Qdrant
检索	相似度搜索	余弦相似度、HNSW索引

python 复制代码

# 伪代码
def process_document(file):
    # 1. 解析
    text = parse_document(file)
    # 2. 分块
    chunks = chunk_text(text, size=500, overlap=50)
    # 3. 向量化
    vectors = embed(chunks)
    # 4. 入库
    vector_db.insert(vectors, metadata=chunks)

十五、Monorepo大仓与传统单层单体架构优缺点对比

维度	Monorepo	单仓单体
代码复用	容易（本地软链接）	困难（需npm发布）
依赖管理	统一版本，减少冲突	各自管理，版本碎片化
构建效率	增量构建，只构建变更	全量构建
权限管理	较难（需CODEOWNERS）	独立仓库，权限清晰
工具链	统一配置	各自维护
CI/CD	智能选择受影响项目	全量流水线

十六、Monorepo和微前端是不是同一个东西，区别是什么

答案：不是同一个东西。

维度	Monorepo	微前端
解决维度	代码仓库管理	应用架构
关注点	依赖管理、构建优化	多团队独立部署、技术栈无关
运行时	无影响	运行时加载子应用
典型工具	pnpm、Turborepo、Nx	qiankun、Micro-App、Module Federation

关系：Monorepo是开发时 的代码组织方式，微前端是运行时的应用架构。两者可以结合使用：用Monorepo管理微前端的多个子应用。

十七、业界主流大仓、模块化工程方案

工具	特点	适用场景
pnpm workspace	硬链接，节省磁盘	中小型Monorepo
Turborepo	智能缓存、增量构建	大型Monorepo
Nx	依赖图可视化、插件生态	企业级
Lerna	版本管理、发布流程	npm包管理
Rush	微软出品，严格规范	超大型项目

十八、为什么需要微前端，解决什么痛点

痛点：

巨石应用：代码臃肿，构建慢，难以维护
多团队协作：技术栈冲突，部署互相影响
遗留系统迁移：无法一次性重写

微前端解决的痛点：

技术栈无关：各子应用可用不同框架
独立开发部署：子应用独立发布，互不影响
增量升级：遗留系统逐步替换
团队自治：各团队负责自己的子应用

十九、常见微前端框架及各自特点

框架	特点	适用场景
qiankun	基于single-spa，JS沙箱、样式隔离	主流选择，蚂蚁出品
Micro-App	京东出品，Web Component方案	技术栈无关
Module Federation	Webpack 5原生支持，运行时共享模块	Webpack项目
无界	腾讯出品，WebComponent+iframe	极致隔离

二十、微前端适用场景与优缺点

适用场景：

大型B端应用（多个子系统）
遗留系统渐进式重构
多团队独立交付

优点：

技术栈灵活
独立部署，故障隔离
团队自治

缺点：

运行时开销（加载子应用）
样式全局污染风险
公共依赖重复加载
调试复杂度增加

二十一、对Harness Engineering的理解

回答思路 ：Harness Engineering（"驾驭式工程"或"制动工程"）指在快速迭代中控制风险、保证稳定性的工程实践。

核心内涵：

渐进式发布：灰度、金丝雀、A/B测试
可观测性：监控、告警、链路追踪
混沌工程：主动注入故障，验证系统韧性
安全护栏：权限控制、审计日志、变更管控

在前端的体现：

灰度发布（按用户/地域）
实时监控（错误率、性能指标）
快速回滚机制
特性开关（Feature Flag）

二十二、Agent人机等待、表单确认、对话交互闭环实现深度

回答思路 ：Agent在需要用户确认或输入信息时，需设计人机协作的交互闭环。

实现要点：

等待态：Agent主动询问，展示等待UI（进度指示）
表单确认：Agent返回结构化要求，前端渲染动态表单
交互闭环：用户确认 → 数据回传Agent → Agent继续执行 → 返回结果

javascript 复制代码

// 表单确认示例
const agentResponse = {
  type: 'confirm',
  fields: [
    { name: 'amount', type: 'number', label: '金额' },
    { name: 'reason', type: 'text', label: '理由' }
  ],
  prompt: '请确认以下信息'
}
// 前端渲染表单 → 用户提交 → 继续对话

深度设计：

支持多轮确认
中断后可恢复
超时处理

📚 知识点速查表

知识点	核心要点
FCP优化	内联CSS、预加载、WebP、CDN、减少阻塞
WebP vs PNG/JPG	WebP体积小25-35%，支持透明/动画
ReAct模式	Thought→Action→Observation循环
Skills/MCP/CLI	Skill预定义、MCP协议、CLI命令行
状态机	状态+事件+转换，语音输入避免竞态
组件封装原则	单一职责、开闭、组合、高内聚低耦合
统一渲染	消息类型系统+渲染器注册表
知识库RAG	解析→分块→向量化→入库→检索→生成
Monorepo vs 微前端	开发时/运行时，不同维度
微前端	技术栈无关、独立部署、渐进迁移
Harness Engineering	风险控制、渐进发布、可观测性
Agent交互闭环	等待态、动态表单、确认回传

📌 最后一句：

腾讯PCG这场二面，是一场"AI工程化"的深度对话。从ReAct模式、Skills/MCP/CLI，到知识库RAG全流程、Monorepo与微前端对比，再到Agent交互闭环。能从容应对这套题，说明你已经具备了AI应用开发的工程架构能力，这正是当前前端领域最稀缺的技能之一。