模拟面试回答稿 - 口语版

使用方法：

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

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

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

LCP（Largest Contentful Paint）：最大内容绘制时间（首屏关键内容）
FCP（First Contentful Paint）：首次内容绘制
CLS（Cumulative Layout Shift）：累积布局偏移（稳定性）
INP（Interaction to Next Paint）：交互响应延迟（新版替代 FID）
TTFB（Time to First Byte）：首字节时间（服务端+网络）

B. 口语版（面试现场口播）

口语版原则：不“总结优势”，只讲事实与决策过程，让面试官从你的表达里感受到能力。

结构记忆：

项目：角色（背景）→ 做了什么 → 价值

问题：问题是什么 → 为什么在这个场景更难 → 我怎么解决并验证

1）自我介绍（口语）

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

面试官你好，我叫彭聪，彭于晏的彭，王思聪的聪，毕业于江西财经大学计算机应用技术专业。
我从 2016 年开始做前端，2019 年起担任前端负责人，2021 年加入大疆。

在近几年的工作中：

主导过千万级用户入口的大疆用户中心的重构以及性能优化工作，
有负责大疆售后 crm 维修管理系统的重构开发，
- 带着团队将项目从第一个模块开始，逐步完善，为这个系统建立起了完善的前端工程体系，
- 通过 eslint 以及低代码等手段提升了开发效率和代码质量
- 抽离了大量通用组件，提升了系统一致性和可维护性
还独立设计交付过跨系统公告插件
参与过大疆前端 DevOps 建设
近期也主导公司的报表设计与开发

这些项目在公司都得到了不错的反馈。

您想先听哪个？我可以从用户中心这个入口项目讲起。

2）用户中心重构（口语）

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

我先按三段讲。

第一段，背景和角色：
用户中心是大疆的 C 端登录系统，有着千万级的用户，日均百万登录请求。所以当时重构最大的问题不是技术的选型，而是追求风险最低。

当时的核心问题点是：

PC 和移动两套代码，维护成本高；
界面老旧，登录转化率有提升空间；
首屏性能有待提升，影响用户体验。

第二段，我做了什么：
所以，我没有推倒重来，没有使用公司已有的技术栈，也没有用当时比较火的 vue3，而是走增量演进：
1）把 PC/移动两套代码通过响应式融合成一套，先把维护成本收敛；
2）围绕性能链路做专项治理——包体积、关键资源优先级、主线程长任务、弱网兜底，逐项定位、逐项解决；
3）项目打包上，做了拆包和缓存优化(Service Worker 强缓存)，三方脚本管控，JS 加载和执行顺序优化，图片升级 WebP 并做好兜底。

第三段，结果：
多端统一后，维护成本下降；登录转化提升，首屏指标也有明显改善。并且在公司内部获得了不错的成绩。

如果您想追问，我可以展开：拆包和缓存怎么做、三方脚本怎么管、以及我们怎么用 RUM 做验证闭环。

面试官：打包优化是怎么做的？

我把问题先说清楚：
登录页的包一旦变大，下载、解析、执行都会变慢，弱网下会直接影响转化。

在用户中心这个场景，历史包袱主要来自 polyfill、重复依赖、字体/图片、以及首屏不需要的业务模块。

我的做法是：先做产物分析和 diff，把大头定位出来，再按优先级落地：

polyfill 按需引入，避免过度兼容；
用 splitChunks 拆稳定依赖，runtimeChunk 单独抽离，保证缓存命中；
路由和非首屏功能全部动态 import()；
字体子集化、图片升级 WebP、图标用 SVG sprite。

最关键的是，每次改动我都用“体积 diff + RUM 指标对比”验收，避免只把体积做小，但体验没变好。

面试官：更快的加载是怎么做的？

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

对应策略，我按“每一招解决什么问题”来落地：

1）网络侧协同：

推动运维开启 HTTP/2 + TLS 1.3，减少握手 RTT；
复用连接和会话，避免重复慢启动。

2）关键资源优先级：

用 preconnect 提前建连 CDN；
用 preload 拉关键字体和 chunk；
prefetch 只给下一跳资源，不抢首屏带宽。

3）渲染阻塞治理：

CSS 关键路径靠前，字体配 font-display: swap 避免白屏；
业务脚本用 defer，三方脚本延后加载 + 超时降级。

最后还是回到验证：上线看 RUM 的 LCP、错误率、失败率波动，确保收益稳定。

面试官：JS 顺序怎么管？

我的做法是“先分层，再控序”。

加载层面：

业务主包用 defer，不阻塞解析，还能保证顺序；
三方脚本用 async 或延后加载，加超时和 fallback，避免拖住首屏；
非首屏模块全部动态 import()，减少初始负担。

执行层面：

用 async/await 把初始化流程显式化：关键依赖 await，可并行的用 Promise.allSettled；
三方 SDK 初始化加 timeout，失败就降级，绝不卡住交互。

目标就两个：首屏别被脚本卡住，交互别被长任务卡住。

面试官：WebP 怎么兜底？

WebP 收益很大，但入口页不能为性能牺牲可用性。

我做了三层兜底：
1）前端用 <picture> 优先 WebP，自动 fallback 到 jpg；
2）构建侧同时产出双份资源，CDN 缓存策略保持稳定；
3）上线后监控图片失败率和 LCP 波动，异常能快速回滚。

这背后是我对“渐进增强”的坚持：新技术要上，但用户不能承担风险。

3）RMS 重构（口语）

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

我也按三段讲。

第一段背景：
RMS 是全球售后工单系统，日均处理工单 1W+，页面 100+，权限链路复杂。我是前端负责人。痛点是：复杂度上来后，风格和质量不统一会让交付波动很大。

第二段我做了什么：
我按“先稳工程 → 再做复用 → 最后提效”推进：
1）从零搭建 TypeScript + ESLint + CI 质量体系，把易错点工具化卡住；
2）把 loading/empty/error 这些边界收敛成高可用组件，并逐步物料化；
3）在表单/配置类页面试点低代码，再规模化扩面。

第三段结果：
整体开发效率提升约 30%，团队 Bug 率下降 25%，体验一致性更稳定。

面试官：ESLint 为什么要从 0-1 做？是怎么做的？

因为系统一大，靠人肉 Review 是守不住的，最后会变成线上 bug 或长期维护成本。并且当时团队对代码规范的认知也不统一。

我的做法是：

先把问题分类（变量遮蔽、未处理 Promise、import 混乱等），再把规则分级（必须 error / 建议 warn）；
工程上用 lint-staged 做提交前自动修复，CI 强制卡点；
存量代码不一刀切：新增必过，存量按目录逐步收紧。

这样团队能接受，也能持续推进。

面试官：组件高可用是怎么做的？

我把“高可用”理解成三件事：边界一致、契约稳定、可观测可止损。

落地时：

loading/empty/error 统一 UI 和行为；
关键区域用 Error Boundary 隔离，避免局部崩溃扩散；
组件 Props 严格 TS 类型，对外 API 稳定；
失败自动上报 Sentry，带上下文（用户 ID、工单状态）。

最后，我把每个组件的配置项、默认值、事件整理成物料描述，为后续低代码打基础。

面试官：低代码怎么落地？

我没一上来推全量低代码，而是先选“高重复、结构稳定”的表单页试点。

关键是我做了三件事：
1）物料标准化：每个组件都有配置 schema、默认值、校验和事件；
2）运行态渲染：递归渲染 + 表达式解析 + 事件分发，把联动收敛；
3）治理机制：schema 版本化、表达式白名单、权限裁剪。

目标很明确：提效的同时，不降稳定性。

4）公告插件 / DevOps / XDR（口语简版）

公告插件：
我独立设计并交付。目标是跨系统低成本接入。我提供 CDN/ESM/Web Component 多形态，SDK 支持 init/destroy 热插拔，做了错误/样式隔离和监控；产物体积控制在 15KB 以内，接入成本压到半天左右。

DevOps：
我参与微前端架构和流水线设计，核心是把部署这类高风险重复劳动流水线化，围绕镜像一致性、分阶段流水线、安全扫描、健康检查和回滚，提升可追溯与稳定性。

XDR：
报表定时本质是异步任务系统。我关注的是幂等与锁、任务状态持久化、队列 worker、并发控制与监控告警，保证按时生成、失败可追溯可补跑。