模拟面试回答稿 - 书面版

使用方法：

书面版用于“投递材料/复盘整理/背诵结构”。

口语版用于“现场表达/语气自然/信息密度适中”。

代码相关内容单独放在 ASK_CODE_EXAMPLES。

A. 书面版（结构化答题稿）

0）固定结构（背诵用）

项目（3 段） 1）项目角色（背景） 2）做了什么事（关键动作/方法/协作） 3）价值（指标/成本/质量/稳定性）

问题（3 段） 1）先把问题说清楚（影响是什么） 2）结合项目背景（为什么在你这个场景更难） 3）解决方案（定位 → 策略 → 落地 → 验证闭环）

1）自我介绍（60-90 秒）

面试官：请做一个自我介绍。

你好，我叫彭聪，江西财经大学计算机应用技术专业，2016 年开始做前端，2019 年开始承担前端负责人工作。

我这几年主要做三类事情： 1）复杂系统重构与长期治理（用户中心入口、售后工单 RMS）； 2）工程化与质量体系（TypeScript/ESLint/CI、组件沉淀与物料化、低代码提效）； 3）跨系统能力与全栈交付（公告插件 SDK、DevOps 平台、NestJS 报表与定时任务）。

我可以先从“用户中心重构：如何在高风险入口做增量演进 + 性能链路治理”开始讲。

2）项目一：大疆用户中心重构（2022.02-2022.09）

用户中心：项目三段式

面试官：介绍一下用户中心重构。

1）项目角色（背景）

角色：项目前端负责人。
背景：核心登录入口，1000W+ 注册用户，日均登录 120W+。
难点：PC/移动两套代码长期分裂；老工程依赖/构建链路历史包袱重；登录链路“首屏即转化”，必须可灰度、可回滚。
选型原则：稳定优先、增量演进、可度量；保留 Vue2 + webpack 主体，引入 TypeScript 与工程约束。

2）做了什么事（关键动作）

1）多端统一：用响应式融合把 PC/移动两套实现收敛为一套代码（布局、组件、资源策略统一）。 2）性能链路治理：围绕“资源体积、关键资源优先级、主线程任务、弱网兜底”做专项；建立从定位到验证的闭环（产物 diff + 线上 RUM/埋点看板）。 3）工程治理：拆包与长缓存、构建产物分析、字体/图片/第三方脚本治理，保证“可回滚 + 风险可控”。

3）价值（结果）

维护成本：PC/移动统一后维护成本下降约 50%。
业务指标：登录转化率提升 18%，客诉率下降 12%。
性能体验：首屏关键指标显著改善（口径：线上 RUM 采样；如需可展开具体指标与采样方式）。

技术点 1：打包优化怎么实现的？（问题三段式）

面试官：你提到打包优化，具体怎么做的？

1）突出问题

老项目容易出现“包体积膨胀 + 缓存命中差 + 解析执行慢”，直接拖慢首屏下载与主线程执行；登录页对转化敏感，这类问题必须优先治理。

2）结合项目背景

用户中心是入口页，历史包袱集中在 polyfill/重复依赖/字体图片/首屏不需要模块。我的做法是先把“体积从哪来、改动会影响什么”做可视化（bundle analyzer + 产物 diff），再按风险与收益排序。

3）解决方案（定位 → 策略 → 落地 → 验证）

1）polyfill：用 browserslist 固定兼容矩阵，Babel 按需注入（避免“过度兼容”）；定期复查 core-js/polyfill 引入来源。
2）拆包与缓存：splitChunks 拆稳定依赖与公共业务；runtimeChunk: 'single' 稳定 runtime；路由/功能动态 import() 降低首屏负担；JS/CSS 用 contenthash 保证长缓存可用。
3）CSS 与副作用：CSS 提取与压缩，明确 sideEffects 保留样式类副作用文件，避免 Tree Shaking 误删样式。
4）静态资源：字体 woff2 + 子集化；图片压缩/格式升级；图标 SVG sprite；统一 CDN 缓存策略。
5）验证闭环：每次改动都做“产物体积 diff + 线上 RUM 对比”，确保优化体积能真实转化为体验收益。

（代码示例在 ASK_CODE_EXAMPLES 的 Webpack/产物分析小节。）

技术点 2：更快的加载怎么实现的？（问题三段式）

我一般先分型：到底是连接/握手慢，还是关键资源没优先级，还是脚本卡住主线程。

对应策略，我按“每一招解决什么问题”来落地，并说明背后的决策理由：

1）网络侧协同

✅ 推动运维开启 HTTP/2 + TLS 1.3，减少握手 RTT
→ 为什么？
用户中心是登录入口，首屏资源多（JS/CSS/字体/图片），HTTP/1.1 下浏览器对同一域名并发连接数有限（通常 6 个），会排队等待。HTTP/2 的多路复用能在一个 TCP 连接上并行传输多个资源，显著减少队头阻塞（HOL）。
同时，TLS 1.3 将握手从 2-RTT 降到 1-RTT（甚至 0-RTT 恢复），在弱网或高延迟场景下，能节省 100~300ms，直接改善 TTFB 和 LCP。
✅ 复用连接和会话，避免重复慢启动
→ 为什么？
TCP 慢启动机制会让新连接初始带宽很低，逐步探测可用带宽。如果每次请求都新建连接，首屏关键资源会因“慢启动”而延迟。通过复用已建连（Connection: keep-alive）和 TLS 会话恢复（Session Resumption），能跳过握手和慢启动，让后续请求“跑在高速通道上”。

2）关键资源优先级

✅ 用 preconnect 提前建连 CDN
→ 为什么？
首屏关键资源（如字体、主 JS）往往来自 CDN 域名。浏览器首次访问该域名时，需经历 DNS 查询 → TCP 握手 → TLS 握手，耗时 100~500ms。<link rel="preconnect"> 能在 HTML 解析早期就提前完成这三步，等真正请求资源时直接发送，消除“隐性等待”。
✅ 用 preload 拉关键字体和 chunk
→ 为什么？
浏览器默认按 HTML/CSS/JS 依赖关系发现资源，但字体可能在 CSS 中引用，主 JS 可能在 `<script> 中加载，导致发现时机晚。<link rel="preload"> 能在 HTML 头部就声明“这个资源很重要”，让浏览器高优先级提前下载，避免 LCP 元素因字体未加载而延迟渲染。
✅ prefetch 只给下一跳资源，不抢首屏带宽
→ 为什么？
prefetch 是低优先级后台预加载，适合“用户下一步可能访问”的页面资源（如登录后首页）。如果滥用在首屏，会抢占关键资源带宽，反而拖慢 LCP。所以严格限制它只用于非关键路径，确保首屏资源独占网络。

当然可以！以下是对你原有回答的 逐条补充理由说明，每项策略后都标注了 “为什么这么做”，既体现技术深度，也突出你在用户中心这类高风险入口项目中的工程判断力和权衡意识。

技术点 3：JS 加载顺序怎么实现的？（问题三段式）

面试官：JS 加载顺序怎么管？

加载层面：

✅ 业务主包用 defer，不阻塞解析，还能保证顺序
→ 为什么？
<script> 默认会阻塞 HTML 解析，导致 DOM 构建延迟，进而推迟 FCP/LCP。而 defer 脚本会在 HTML 解析完成后、DOMContentLoaded 事件前按顺序执行，既不阻塞渲染，又能保证多个业务模块的初始化顺序（比如先加载工具库，再加载业务逻辑），非常适合登录页这类对执行顺序敏感的场景。
✅ 三方脚本用 async 或延后加载，加超时和 fallback，避免拖住首屏
→ 为什么？
第三方 SDK（如埋点、风控、A/B 测试）通常不可控：可能加载慢、执行时间长、甚至抛错。如果同步加载，会直接卡住主线程，导致用户点击无响应。
- async 让其并行下载、下载完立即执行（不保证顺序），适合完全独立的脚本；
- 更安全的做法是在 window.onload 后动态插入，确保首屏渲染和交互完成后再加载；
- 加超时（如 2s）和降级（失败就跳过）是为了防止“一个第三方脚本拖垮整个登录流程”，这是入口页的底线思维。
✅ 非首屏模块全部动态 import()，减少初始负担
→ 为什么？
登录页只需展示核心表单，帮助中心、协议弹窗、多语言切换等属于“后续交互”。如果全打包进主 bundle，会增加首屏 JS 体积，延长下载、解析、编译时间。
通过 import('./HelpModal') 动态加载，只在用户点击时才加载对应代码，显著降低首屏 TTI（Time to Interactive）。

执行层面：

✅ 用 async/await 把初始化流程显式化：关键依赖 await，可并行的用 Promise.allSettled
→ 为什么？
传统回调或 .then 链容易造成“回调地狱”或执行顺序混乱。用 async/await 能让异步流程像同步代码一样可读、可控。
- 对强依赖（如用户信息必须先拉取才能渲染头像），用 await 保证顺序；
- 对弱依赖（如同时拉取公告 + 配置），用 Promise.allSettled 并发请求，避免串行等待拖慢整体启动速度。
✅ 三方 SDK 初始化加 timeout，失败就降级，绝不卡住交互
→ 为什么？
第三方服务 SLA 不可控，网络抖动或服务异常可能导致 SDK 初始化卡住数秒。如果主线程被阻塞，用户点击“登录”按钮将无响应，直接导致转化流失。
通过 Promise.race([initSDK(), timeout(2000)]) 包裹，2 秒内未完成就视为失败，跳过该功能但保留核心流程，确保“可用性 > 完整性”。

3）渲染阻塞治理

✅ CSS 关键路径靠前，字体配 font-display: swap 避免白屏
→ 为什么？
浏览器会阻塞渲染直到所有 CSS 加载完成。如果关键样式（如布局、LCP 元素样式）被放在底部或异步加载，会导致白屏或布局抖动。我们把关键 CSS 内联或放 <head> 顶部，确保快速构建渲染树。
同时，自定义字体默认会阻塞文本显示（FOIT），font-display: swap 让浏览器先用系统字体显示文字，再异步替换，保证“内容始终可见”，提升感知性能。
✅ 业务脚本用 defer，三方脚本延后加载 + 超时降级
→ 为什么？
<script> 默认会阻塞 HTML 解析，导致 DOM 构建延迟。defer 脚本会在 HTML 解析完成后、DOMContentLoaded 前执行，不阻塞解析，且保持顺序，适合业务主逻辑。
而三方脚本（如埋点、风控）不可控，若同步加载可能卡住主线程。我们将其移至 load 事件后加载，并加 2 秒超时 + 降级策略（失败也不阻塞交互），确保“核心体验不受第三方影响”。

技术点 4：WebP 怎么做兜底处理？（问题三段式）

面试官：WebP 升级怎么做兼容？

WebP 收益很大——同等画质下体积比 JPEG 小 30%~50%，对首屏加载速度帮助明显。
但用户中心是登录入口，不能为了性能牺牲可用性。一旦图片加载失败，用户可能看到空白 Banner 或缺失验证码，直接导致转化流失。

所以我做了三层兜底，每层都有明确目的：

✅ 1）前端用 `<picture>` 优先 WebP，自动 fallback 到 jpg

→ 为什么这么做？
<picture> 是浏览器原生支持的响应式图片方案，能根据 type 自动选择首个支持的格式。

如果浏览器支持 WebP（现代 Chrome/Firefox/Safari），就加载 .webp；
如果不支持（如老版 WebView、部分国产浏览器），就自动 fallback 到 .jpg。
这比 JS 能力探测更可靠、更早生效——因为 HTML 解析阶段就能决定加载哪个资源，避免“先加载失败再重试”的额外 RTT。

✅ 2）构建侧同时产出双份资源，CDN 缓存策略保持稳定

→ 为什么这么做？
很多团队只生成 WebP，靠服务端内容协商（Content Negotiation）返回不同格式。但这种方式有风险：

CDN 可能缓存错版本（比如给不支持 WebP 的 UA 返回了 .webp）；
服务端逻辑复杂，容易出错。

我的做法是：构建时同时输出 banner.webp 和 banner.jpg，路径固定、缓存 key 独立。
这样无论用户用什么设备，CDN 都能命中正确资源，零依赖服务端逻辑，稳定性更高。

✅ 3）上线后监控图片失败率和 LCP 波动，异常能快速回滚

→ 为什么这么做？
技术方案再完美，也抵不过真实环境的碎片化（比如某款定制 ROM 的 WebView 有 Bug）。
所以我在 RUM 上报中加入了：

图片加载失败率（通过 onerror 监听）；
LCP 是否因图片加载变慢而恶化；
用户设备/UA 分布是否异常。

一旦发现 WebP 升级导致失败率上升或 LCP 恶化，可以 10 分钟内回滚到纯 JPG 版本，把风险控制在最小范围。

3）项目二：大疆售后 RMS 系统重构（2022.10-2024.04）

RMS：项目三段式

面试官：说说 RMS 系统重构。

1）项目角色（背景）

角色：项目前端负责人。
背景：全球售后工单系统，日均处理工单 1W+，页面 100+，权限链路复杂。
难点：历史代码风格与质量不统一，类型与边界不清，复杂度上升后“人肉 Review 守不住”。
选型：统一 React 18 + TypeScript + Umi + UI 体系，目标是把工程基础打牢，保证可协作与可持续。

2）做了什么事

1）工程基础 0-1：ESLint/TypeScript 规则体系、目录分层与模块边界、提交前与 CI 卡点。 2）复用体系：沉淀高可用业务组件（权限/空态/错误/加载/失败重试一致），逐步物料化。 3）低代码提效：贡献/接入可复用物料，在表单/配置类页面规模化落地；同步补齐 schema 版本化与迁移策略。

3）价值

协作效率：整体开发效率提升约 30%。
质量稳定：团队 Bug 率下降约 25%，UI/交互一致性明显提升。

技术点 1：ESLint 规范制定怎么实现的？（问题三段式）

面试官：你说制定 ESLint 规范，怎么落地的？

1）突出问题

在 RMS 这种 100+ 页面、多权限链路的复杂系统里，“风格不统一 + 缺少质量约束”会直接引发隐性 bug：比如未处理的 Promise 导致静默失败、any 泛滥让类型失去意义、变量遮蔽造成逻辑错乱、import 顺序混乱引发循环依赖。
系统越大，靠人肉 Code Review 越守不住——必须把规则变成工具，而不是文档。

2）结合项目背景

我接手时，团队已经出现“改一个页面要花半天理解上下文”的问题。所以我先做了一次历史问题归类：

变量/作用域问题（如 var 重声明）
类型失控（any、隐式 any）
异步处理缺失（Promise 不 await 或 .catch）
import 无序、跨层引用（页面直接调用底层 utils）
React Hooks 依赖缺失

然后我把规则分成三级：

error：会出错或劣化体验的（如未处理 Promise、Hooks 规则）
warn：影响可读性但不致命的（如 import 顺序）
暂缓：争议大或改造成本高的（如强制函数式组件）

这样既守住底线，又让团队能接受。

3）解决方案（含实际配置）

我从 0-1 搭建了一套可执行、可修复、可演进的 ESLint 体系：

✅ 1）规则体系：基于 TypeScript + 插件组合

// .eslintrc.cjs
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint', 'import', 'promise', 'react-hooks'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:promise/recommended',
    'plugin:import/recommended',
    'plugin:import/typescript',
    'prettier' // 确保与 Prettier 不冲突
  ],
  rules: {
    // 【质量卡点】必须 error
    '@typescript-eslint/no-floating-promises': 'error', // 未处理 Promise
    '@typescript-eslint/no-explicit-any': 'error', // 禁止 any
    'react-hooks/rules-of-hooks': 'error', // Hooks 基础规则
    'react-hooks/exhaustive-deps': 'warn', // 依赖建议完整

    // 【可读性】可自动修复
    'import/order': [
      'warn',
      {
        'newlines-between': 'always',
        groups: [
          'builtin',
          'external',
          'internal',
          'parent',
          'sibling',
          'index'
        ]
      }
    ],
    'import/no-cycle': 'error' // 防止循环依赖
  }
}

✅ 3）自动修复：Prettier + ESLint 分工明确

Prettier 只管格式（缩进、引号、分号）
ESLint 只管质量（逻辑、类型、依赖）

提交时自动修复：

// package.json
"lint-staged": {
  "*.{js,ts,tsx}": ["eslint --fix", "prettier --write"]
}

✅ 4）落地策略：不炸存量，渐进收紧

新增/修改文件：CI 强制 eslint --max-warnings=0，不过就阻断 MR
存量代码：按目录分批治理，先加 // eslint-disable-next-line 标记，再逐步清理
团队反馈：“现在写代码像有导航，不会突然掉坑里”

✅ 5）工程集成：规范成为流水线能力

提交前：lint-staged 自动修复
CI 阶段：全量 lint + type check
MR 流程：Sonar 扫描 + 人工 Review 聚焦业务逻辑，而非格式

💡 结果与价值

团队 Bug 率下降 25%（尤其异步错误、类型错误归零）
Code Review 争议减少 60%，大家更关注业务逻辑而非“要不要分号”
新人上手速度提升，因为代码“长得都一样”

这套体系后来被推广到 3 个其他项目，成为公司前端基建的一部分。

技术点 2：业务组件高可用怎么实现的？（并为低代码物料做铺垫｜问题三段式）

面试官：业务组件高可用你具体做了什么？

1）突出问题

复杂系统复用组件会遇到“边界条件爆炸”（权限/空数据/慢接口/失败重试/多语言）。只为单页写会变成大量 copy；直接复用又怕改崩别处，所以组件必须边界自洽、可观测、可扩展。

2）结合项目背景

RMS 模块多、权限多，组件要能在无权限/空数据/失败/慢接口等场景下保持一致体验与可控行为。

3）解决方案

1）边界三件套：loading/empty/error 统一；关键区域 Error Boundary 隔离，避免单点崩溃扩散。 2）契约化：Props 分层（必选/可选/默认值）；类型定义收口，避免 any 扩散；对外 API 稳定，扩展点用 render props/slot。 3）可观测与降级：关键失败上报 + 开关降级，做到“能发现、能止损”。 4）物料化：整理组件的配置项/默认值/校验/事件为物料描述，为后续 schema 驱动铺路。

技术点 3：低代码平台接入落地怎么实现的？（贡献组件 → 深度使用 → 提效｜问题三段式）

面试官：低代码平台你是怎么落地的？

1）突出问题

表单/配置页是“高重复 + 高变更”：字段/规则一改就要重新开发与回归，长期吞噬产能。要提效必须标准化组件 + schema 驱动，否则低代码会变成新的维护负担。

2）结合项目背景

RMS 大量页面是“字段差异 + 规则差异”，非常适合 schema；但也存在复杂交互页面，需要明确边界：哪些适合低代码，哪些必须手写。

3）解决方案

1）路径设计：先试点“结构稳定、收益可控”的页面；沉淀模板与规范后再规模化扩面。 2）物料- schema 对齐：每个物料组件都有配置面板 schema、默认值、校验规则、事件定义；schema 描述组件树 + props + 事件 + 校验 + 数据源绑定。 3）运行态渲染：递归渲染 + 表达式解析 + 事件分发；联动用依赖图/事件总线收敛复杂度。 4）版本与迁移：schema 版本化，结构演进提供 migration，确保历史页面可打开。 5）安全与权限：表达式能力白名单化（避免任意执行），运行态按权限裁剪组件/配置。 6）性能：虚拟滚动/按需渲染/批量更新；编辑器与运行态拆包，避免把编辑器代码带到线上运行包。

4）项目三：跨平台公告插件系统（2023.02-2023.03）

公告插件：项目三段式

面试官：跨平台公告插件你怎么做的？

1）项目角色（背景）

角色：独立开发者（方案设计 + SDK 交付）。
背景：多个内部系统都需要“紧急公告/发版公告”，如果各做一套会重复建设；而系统技术栈不一致，必须做到跨框架、低侵入、可快速接入。

2）做了什么事

1）统一接入协议与配置：SDK 侧只负责渲染与生命周期，策略由服务端配置（token/appId/投放策略）。 2）热插拔与隔离：提供 init/destroy；错误隔离、样式/资源隔离；保证“不影响宿主”。 3）多形态接入：CDN/UMD、ESM/NPM、Web Component；极端冲突场景预留 iframe 兜底。 4）体积与性能：Rollup Tree Shaking；Preact 轻内核 + 细粒度更新，控制 SDK 体积。

3）价值

产物体积 < 15KB。
单系统接入成本 < 0.5 人日。
跨 5 个系统标准化接入，紧急公告触达率 100%。

技术点 1：多模式植入方案怎么设计的？（问题三段式）

面试官：多模式植入你怎么设计？

1）突出问题

系统技术栈与构建方式不同，如果只提供一种接入形态，会导致接入成本高、改造风险大。

2）结合项目背景

需要同时覆盖“老系统不改构建链路”“现代系统走 npm”“紧急场景快速接入（CDN）”。

3）解决方案

1）CDN/UMD：最简单，适合快速接入与老系统。 2）ESM/NPM：适合现代工程体系，按需引入、可 Tree Shaking。 3）Web Component：框架无关，作为通用形态。 4）iframe 兜底（可选）：在强隔离场景（样式冲突严重/安全要求高）用 iframe，代价是通信与性能。

技术点 2：为什么选择 Preact？（问题三段式）

面试官：为什么不用 React，而用 Preact？

1）突出问题

SDK 的核心约束是“体积极小、无感接入、低冲突风险”。React 对 SDK 来说偏重，且宿主可能已有 React 版本，存在冲突风险。

2）结合项目背景

公告本质是轻量 UI + 拉取数据，不需要重型生态；更关键的是不能影响宿主性能与稳定性。

3）解决方案

1）体积：Preact 内核小，配合压缩与 Tree Shaking 更容易把 SDK 控制在 < 15KB。 2）性能与渲染：小组件渲染链路更短；必要时用 signal/细粒度更新减少重渲染。 3）兼容策略：输出多格式，避免强绑定宿主框架。

技术点 3：为什么选择 Rollup 打包？（问题三段式）

面试官：为什么选择 Rollup，而不是 Webpack？

1）突出问题

SDK 场景优先级是“产物体积与 Tree Shaking 效果”，而不是大型应用的复杂构建能力。

2）结合项目背景

公告 SDK 以 ESM 为主，依赖要极简，同时需要输出 UMD/ESM 以适配多种接入方式。

3）解决方案

1）Rollup 对库模式与 Tree Shaking 更友好，配置更聚焦。 2）多格式输出（UMD/ESM）更顺手，适配多接入方式。 3）配合 terser/压缩策略，更容易把体积压到目标范围。

5）项目四：大疆 DevOps 平台维护（2024.03-2025.04）

DevOps：项目三段式

面试官：DevOps 平台你做了什么？

1）项目角色（背景）

角色：核心开发者。
背景：内部 DevOps 平台支撑研发流程（权限/需求/自动化测试/文档等），需要持续迭代且稳定。

2）做了什么事

1）功能迭代：Jira 插件对接、Workspace 审批流、自定义流程等。 2）交付治理：把高风险重复劳动（部署）尽量流水线化，提升可追溯与可回滚能力。

3）价值

提升流程审批与部署效率，降低人工操作与出错概率，保障流水线稳定。

技术点：Docker 流水线自动化部署怎么实现的？（问题三段式）

面试官：Docker 流水线自动化部署你怎么做的？

1）突出问题

部署是典型“高风险重复劳动”：手工步骤多就会出错，出了问题难追溯；多环境下还容易配置漂移。把部署流水线化，本质是把交付从“人的经验”变成“系统能力”。

2）结合项目背景

平台服务多、依赖多，必须把部署过程标准化，做到可回滚、可审计、可追溯。

3）解决方案

1）镜像与依赖一致性：统一 Dockerfile、基础镜像与构建参数；版本以 commit sha/语义化版本打 tag。 2）流水线阶段化：build/test → image build → scan → deploy → verify；每一阶段产出可追溯记录。 3）配置治理：配置与密钥分离；环境差异通过配置中心/环境变量管理，避免镜像内写死。 4）发布与回滚：支持灰度/回滚；失败自动阻断并告警；验证阶段做健康检查与关键接口探活。

6）项目五：XDR 系统 - 魔方大屏 + 报表（2025.05-2025.12）

XDR：项目三段式

面试官：XDR 大屏和报表你做了什么？

1）项目角色（背景）

角色：核心开发者。
背景：安全运营相关的大数据可视化系统，需要高性能渲染与稳定数据链路；同时有“报表自动生成与分发”的自动化诉求。

2）做了什么事

1）大屏：Vue3 + ECharts 可视化组件与渲染链路优化，强调性能与交互。 2）全栈：NestJS 做数据聚合、定时任务、报表生成与邮件推送。 3）导出：支持 PDF/PPT/Excel 等多格式输出。

3）价值

万级数据快速渲染与交互；报表自动化提升运营效率，降低人工成本。

RTT（Round-Trip Time）：网络往返时延，影响握手与请求时延。
FCP（First Contentful Paint）：首次内容绘制。
LCP（Largest Contentful Paint）：最大内容绘制（通常是首屏主内容块/主图）。
CLS（Cumulative Layout Shift）：累积布局偏移。
RUM（Real User Monitoring）：真实用户监控数据（线上采样）。

模拟面试回答稿 - 书面版

On this page