钉子的生活日记
文章目录

腾讯前端暑期二战一面整理笔记（三十一）

1. 什么是闭包，什么时候会用到

答案

闭包（Closure）指：函数在创建时“捕获”其词法作用域中的变量，即使外层函数已经执行完毕，这些变量仍然能被内部函数访问。

常见使用场景：

  1. 封装私有状态：用函数返回函数，把内部变量作为“私有成员”（模块化、计数器、缓存）。
  2. 函数工厂/柯里化：预先固化部分参数，生成特定功能的函数。
  3. 回调与事件处理：在异步回调里保留当时的上下文数据（比如循环里的索引要用 let 或 IIFE 处理）。
  4. 防抖/节流：把 timer/上次时间戳保存在闭包里复用。

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

答案

FCP 是 First Contentful Paint，表示页面首次绘制出有意义内容的时间。

要把 FCP 从 3.3s 拉到 1.8s，一般要同时压缩 TTFB + 渲染阻塞资源 + 首屏渲染负载：

  1. 服务端与网络：CDN、开启 gzip/brotli、HTTP2/3、减少重定向；优化接口/SSR TTFB（缓存、并行、降级）。
  2. 关键 CSS：首屏关键 CSS 内联或按路由拆分；非关键 CSS 延后加载，避免 CSS 阻塞渲染。
  3. 首屏 JS 降负载：路由级拆包、按需引入（组件库/图表）、移除无用 polyfill；第三方脚本延后（defer/动态加载）。
  4. 首屏资源优先级：对 hero 图/首屏字体用 preload；图片用 AVIF/WebP + 合理尺寸；非首屏图片 loading=lazy。
  5. 渲染策略：有条件上 SSR/预渲染（电商活动页、详情页常见）；至少保证 skeleton/首屏骨架尽快渲染。
  6. 验证：用 RUM/Lighthouse 对比 P50/P90，确认是“更快开始绘制”而不是只优化了后续加载。

3. WebP 与 PNG、JPG 图片格式区别

答案

三者核心区别：压缩方式（有损/无损）、透明与动画、体积与解码开销、兼容性。

  1. JPG 适合照片，压缩率高，但不支持透明。
  2. PNG 支持透明，适合图标和边缘要求高的图片，但通常更大。
  3. WebP 同时支持有损/无损、透明、动画，很多场景体积更小；但要注意老设备/部分环境兼容性与解码性能。

4. SSE 跟 WebSocket 的区别

答案

SSE 和 WebSocket 的核心区别是通信方向和适用场景。

  1. SSE：基于 HTTP 的单向推送（text/event-stream），浏览器原生支持自动重连；适合通知、日志、大模型文本流。
  2. WebSocket：一次握手后升级为长连接全双工；更适合双向高频交互（聊天、协作、游戏）。
  3. 工程取舍：
    • SSE 更易接入现有网关/鉴权/代理（还是 HTTP），但只能单向、消息格式偏文本。
    • WebSocket 功能更强，但需要心跳、重连、鉴权续期、限流与网关支持，治理成本更高。

5. 流式对话中响应中断如何处理

答案

流式对话中断一般要前后端一起处理。

  1. 前端用 AbortController 或取消标记停止继续读取流。
  2. 服务端要监听连接断开（SSE 的 client close / fetch abort）并向下游传播取消（例如把 AbortSignal 传给模型调用/检索/工具链）。
  3. UI 层把消息标记为“已中断/已停止”，并能继续发下一条（避免把中断当成失败）。
  4. 需要兜底：超时、重试、幂等（同一轮请求有 requestId，避免重复扣费/重复写库）。

6. Agent 中 react 模式是怎样的

答案

这里的 “ReAct” 通常指 Reason + Act（不是 React 框架）：让模型在推理过程中穿插工具调用，通过观察（observation）不断修正计划。

  1. 典型循环：Think（规划）→ Act（调用工具/函数）→ Observe（读取结果）→ Replan（必要时重规划）。
  2. 为什么需要：纯生成容易幻觉；工具调用可把关键步骤变成“可验证的事实”（查库、搜文档、跑代码、读文件）。
  3. 工程落地要点：结构化 tool schema、参数校验、权限控制、失败重试与停止条件（步数/成本/超时）。

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

答案

可以按“能力封装层级”来讲：

  1. CLI（Command Line Interface）：最底层执行入口（跑脚本/命令）。优点是通用、可组合；缺点是对模型不友好（参数/输出不结构化）、安全风险高（需要沙箱/权限）。
  2. MCP（模型上下文/工具协议）：把外部工具与上下文以统一协议暴露给模型（可结构化调用与返回）。优点是标准化接入、可控性更强；缺点是需要服务化与权限治理。
  3. Skills（能力包/工作流封装）：把一组步骤（提示词 + 工具调用 +格式要求）封装成可复用能力。优点是复用与一致性；缺点是维护成本（版本、适配不同项目）。

8. 什么是状态机，语音输入为什么要用状态机

答案

状态机适合处理“状态明确、状态切换受规则约束”的场景。

  1. 它会把系统状态和转移条件写清楚，减少分支混乱。
  2. 在语音输入里，常见状态有待机、录音中、识别中、确认中、结束、异常。
  3. 语音链路常见竞态（开始/停止按钮、权限弹窗、网络抖动、识别回调乱序），状态机能把“允许发生的事件”约束住，避免重复 start/stop、重复提交等问题。

9. 封装组件需要遵循哪些原则

答案

组件封装一般遵循四个原则：

  1. 职责单一，边界清晰。
  2. API 稳定，props / events / slots 命名统一。
  3. 可复用但不过度抽象，不要为少量特殊需求把组件做得过重。
  4. 兼顾可访问性（键盘/读屏）、主题能力（tokens/className）、受控/非受控两种用法（可选）、以及测试友好性（稳定选择器、可注入依赖）。

10. AI 聊天对话框如何实现，怎么承接 SSE 流式返回

答案

AI 聊天对话框一般由输入区、消息区、状态区组成，流式返回的关键是“边收边渲染”。

  1. 发送消息后先插入一条 assistant 占位消息。
  2. 通过 SSE（EventSource）或 fetch streaming 持续接收增量内容（delta）。
  3. 把 delta 追加到同一条消息里（按 messageId 聚合），并做节流刷新（避免每个 token 都触发重排）。
  4. 处理关键交互：停止生成（abort）、失败重试、滚动跟随/用户上滑暂停跟随、长列表虚拟化。
  5. 安全：Markdown/富文本渲染要防 XSS（白名单渲染或严格转义）。

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

答案

核心是把“消息内容”抽象成 parts（片段），而不是单一字符串。

  1. 每个片段带上 type，例如 text、image、pdf、markdown、component。
  2. 前端实现一个渲染器注册表（type → renderer），并保持向后兼容（未知 type 用降级渲染）。
  3. 文本类支持增量 patch；资源类（图片/PDF）先渲染占位（loading），等拿到 URL/元数据后替换。
  4. 交互组件建议走“受控组件协议”（componentId + props + event 回传），并明确权限边界（不让模型随意注入任意脚本）。

12. 用户个人知识库搭建与完整使用流程

答案

可以按“写入链路 + 查询链路”回答更清晰：

  1. 写入链路：上传（含权限/归属）→ 解析（PDF/Doc/网页）→ 清洗去噪 → 分块（按标题/段落，控制 token）→ embedding → 入库（向量 + 元数据）。
  2. 查询链路：用户问题 → query rewrite（可选）→ 多路召回（向量/BM25/过滤）→ rerank → 拼上下文（去重、限长）→ 生成回答 → 引用与反馈（点赞/纠错用于迭代）。
  3. 工程关键：权限隔离（租户/用户）、增量更新与删除、可观测（命中率/延迟/成本）、以及评测集与 A/B。

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

答案

更偏实现细节时，可以把关键点补全：

  1. 解析：抽取文本 + 保留结构信息（标题层级、表格、页码）；对 OCR 文档先识别再清洗。
  2. 分块：按结构切分 + overlap，落到可检索的最小语义单元；写入元数据（文档、章节、时间、权限）。
  3. 入库：向量索引（HNSW/IVF 等）+ 元数据索引（便于过滤）；支持增量写入与删除同步。
  4. 检索：过滤（权限/范围）→ 召回 topK → rerank → 上下文拼装（避免重复与无关噪声）→ 生成与引用。

14. 自研知识库和普通桌面 AI 上传文档问答区别、项目初衷

答案

建议从“控制力/可集成/可治理”角度回答：

  1. 数据与权限：自研能做租户隔离、细粒度权限、审计；桌面 AI 往往偏个人使用，企业合规约束不足。
  2. 检索质量可控：自研可以定制分块策略、召回/重排、评测集与线上 A/B；桌面 AI 通常黑盒，难定位“答错原因”。
  3. 业务集成：自研能接入企业系统（工单、IM、代码库、知识平台），把回答变成流程动作；桌面 AI 多停留在问答。
  4. 初衷：把企业/团队知识“可检索、可更新、可评测、可治理”地服务业务，而不仅是临时问答。

15. Monorepo 大仓与传统单层单体架构优缺点对比

答案

Monorepo 是把多个相关包放在同一个仓库管理。

  1. 优点：依赖与规范统一、跨包重构容易（原子提交）、复用更自然、CI 可统一治理。
  2. 缺点：权限与边界需要治理（owner、review 规则）、构建与测试要做增量（affected）、工具链复杂度更高。
  3. 单体仓库（单层单体）优点是简单直接；但当多人多模块时，复用与协作成本会上升（复制代码、版本碎片化）。

16. Monorepo 和微前端是不是同一个东西，区别是什么

答案

不是一个东西，分别解决不同层面的拆分：

  1. Monorepo：仓库与依赖治理（开发协作/代码共享/版本策略）。
  2. 微前端：运行时拆分与独立部署（不同子应用可独立发布、隔离与通信）。
  3. 组合关系：可以 Monorepo + 微前端（同仓开发、多应用独立部署），也可以各自单独使用。

17. 业界主流大仓、模块化工程方案有哪些

答案

常见的大仓和模块化工程方案包括 Monorepo、微前端、包管理工作区和构建层统一。

  1. Monorepo：pnpm workspace + Nx/Turborepo/Rush（增量构建、任务编排、缓存）。
  2. 多包发布：Changesets/Lerna（更偏包版本发布治理）。
  3. 运行时模块化：Module Federation（共享依赖与远程模块加载）。
  4. 微前端框架：qiankun、无界、MicroApp（隔离、通信、接入方式不同）。

18. 为什么需要微前端，解决什么痛点

答案

微前端主要解决“大团队、多系统、强独立部署”的问题。

  1. 多团队协作时，单体应用发版互相掣肘；微前端让子系统独立发布、互不阻塞。
  2. 组织边界清晰：按业务域拆分 ownership，降低冲突与沟通成本。
  3. 允许渐进式迁移：老系统不推倒重来，新系统以子应用方式接入。

19. 常见微前端框架及各自特点

答案

常见微前端方案包括 qiankun、无界、MicroApp、Module Federation。

  1. qiankun：基于 single-spa 思路，生态成熟；需要处理样式/JS 隔离与性能治理。
  2. 无界/MicroApp：更强调隔离与接入体验（实现细节不同），适合多子应用快速接入。
  3. Module Federation：偏“模块共享/远程加载”，不等于完整微前端治理（路由、隔离、通信仍需配套）。

20. 微前端适用场景与优缺点

答案

微前端适合大型平台、多团队协作、子系统相对独立的场景。

  1. 优点是拆分清晰、独立部署、团队边界明确。
  2. 缺点是接入复杂、调试成本高、运行时通信和隔离治理更重。
  3. 典型坑：子应用多导致首屏变慢、共享依赖版本冲突、样式污染、路由与权限一致性难做；小团队/小项目通常不值得上。

21. 对 Harness Engineering 的理解

答案

Harness Engineering 可以理解为“让复杂系统可测试、可复现、可观测、可回放”的工程能力建设（类似测试桩/仿真环境/执行沙箱/回放工具）。

  1. 目标：把线上问题“搬回”到可控环境稳定复现；把链路拆开做可验证的单元与集成测试。
  2. 关键能力：数据录制与回放、依赖注入/Mock、可控的时间/随机数、沙箱隔离、trace/日志/指标聚合。
  3. 价值：提升定位效率与回归质量，让研发能更快、更确定地修复问题。

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

答案

这题重点讲“可控的交互闭环”：

  1. Agent 输出不是直接执行高风险动作，而是先输出可审阅的计划/表单（要点、参数、影响范围）。
  2. 系统进入 WAIT_USER_CONFIRM 状态：前端渲染表单/确认卡片，用户确认后才允许执行工具调用。
  3. 执行后把结果（成功/失败/副作用）作为 observation 回灌，更新状态并给出下一步建议。
  4. 约束：权限校验、审计日志、幂等 requestId、超时与撤销（可回滚则回滚）。

23. Harness 工程是否有项目落地实践

答案

回答思路：用 1~2 个真实落地案例讲清“问题→方案→收益→指标”。

  1. 例：为某条关键链路做“录制-回放”能力：线上采样请求与关键依赖返回，脱敏后落盘；本地一键回放复现，定位时间从小时级降到分钟级。
  2. 例：为 Agent/工具链做“可回放 trace”：每次 tool call 记录输入/输出/耗时/错误码，可重放并做回归对比（质量与成本指标可见）。
  3. 指标：复现成功率、平均定位时长、回归缺陷率、线上事故率、单次执行成本。

24. 面试回答流畅是提前准备还是真实项目积累

答案

这类问题可以诚实回答成“两部分都有”。

  1. 一部分来自提前整理和有意识复盘。
  2. 另一部分来自真实项目里真的做过、踩过坑、解决过问题。
  3. 最好的状态不是背稿，而是把做过的事总结成稳定表达。