性能优化全面补全：从前端通用到工程化
一、前端通用性能优化（补充）
1. 预渲染 / SSR / SSG / ISR 的区别与适用场景（必问）
答：
CSR（客户端渲染）：JS 下载 → 执行 → 渲染 → 可交互。首屏慢，SEO 差。
SSR（服务端渲染）：服务端生成完整 HTML，首屏快、SEO 好。但服务压力大，成本高。
SSG（静态站点生成）：构建时生成 HTML，部署后不变。最快、最稳，适合内容站。
ISR（增量静态再生成）：静态 + 增量更新，适合内容频繁更新但不需要实时的场景。
预渲染（Prerender）：构建时为部分路由生成静态 HTML，轻量，适合中小型 SPA。
适用场景一句话总结：
博客/文档 → SSG
电商/内容站 → SSR / ISR
后台管理 → CSR + 预渲染
实时交互应用 → CSR + 性能优化
2. 关键渲染路径（Critical Rendering Path）优化（必问）
答：
关键渲染路径 = HTML → CSSOM → Render Tree → Layout → Paint
优化手段：
减少关键资源数量（减少 JS/CSS 请求）
减少关键资源大小（压缩、Tree Shaking）
缩短关键路径长度（内联关键 CSS、异步非关键 CSS、 defer/async JS）
3. 资源优先级（Resource Hints）完整体系（容易漏）
答：
dns-prefetch：提前 DNS 解析preconnect：提前建立 TCP 连接prefetch：预测加载下一页资源（低优先级）preload：当前页关键资源（高优先级）modulepreload：预加载 ES 模块prerender：预渲染整个页面（最耗资源，慎用）
4. 渲染阻塞问题：CSS/JS 为什么阻塞？如何解决？
答：
- CSS 阻塞渲染：浏览器必须等 CSSOM 构建完成才渲染，避免无样式闪烁。
解决：内联关键 CSS、非关键 CSS 异步加载（media="print" + 动态改 media）。
- JS 阻塞 HTML 解析与渲染：JS 可修改 DOM/CSSOM，浏览器必须停下解析。
解决：defer（顺序执行，DOMContentLoaded 前）、async（无序，下载完立即执行）、动态创建 script。
5. 回流重绘的“强制同步布局”（Forced Synchronous Layout）
答：
连续“读布局属性 → 写样式 → 读布局属性”会让浏览器强制立即重排，造成卡顿。
避免：读写分离，先批量读，再批量写。
6. 合成层（Compositing Layers）与层爆炸（Layer Explosion）
答：
合成层可以提升动画性能，但过多层会占用大量内存，导致卡顿甚至崩溃。
避免：
不要滥用
will-change/transform造层用 DevTools Layers 面板检查层数
动画元素尽量少、尽量小
7. 内存泄漏的进阶排查手段（大厂爱问）
答：
DevTools Memory 面板：
堆快照（Heap snapshot）：看对象引用链
分配时间线（Allocation instrumentation）：看哪里频繁创建对象
分配采样（Allocation sampling）：轻量排查
常见进阶泄漏：
全局事件监听未移除（
addEventListener+ 未removeEventListener）第三方库内部泄漏（图表库、地图库）
缓存无上限（需 LRU）
闭包 + DOM 引用形成无法回收的子树
8. 主线程压力：微任务/宏任务队列阻塞问题
答：
微任务（Promise、MutationObserver）会在宏任务之间清空队列。
大量微任务会阻塞渲染，造成卡顿。
优化：
分批执行微任务
用
requestIdleCallback/setTimeout让出主线程
二、React 性能优化（补充）
9. React 合成事件（SyntheticEvent）与原生事件性能差异
答：
React 事件是委托到 document，减少事件监听器数量，提升性能。
但频繁触发的事件（scroll/mousemove）仍需防抖/节流。
注意：合成事件是复用对象，异步中需
event.persist()。
10. React 状态设计对性能的影响（容易忽略）
答：
状态越靠近叶子组件，重渲染范围越小。
避免把所有状态放根组件/Context，会导致全树重渲染。
状态拆分原则：谁使用谁管理，最小作用域。
11. React 中 Context 性能陷阱与优化（高频）
答：
Context value 是对象/函数时，每次渲染都会创建新引用 → 所有消费组件重渲染。
优化：
拆分 Context（按功能拆）
useMemo缓存 value用
useContextSelector（或第三方库）只订阅需要的字段
12. React 服务端组件（RSC）对性能的提升（新热点）
答：
RSC 在服务端执行，不发送 JS 到客户端，减少包体积、提升首屏。
客户端组件（Client Component）只保留交互逻辑。
适合：内容密集型、交互少的页面。
13. React 并发渲染（Concurrent Mode）的底层思想
答：
可中断、可恢复、可优先级调度的渲染。
避免长任务阻塞交互。
核心：把渲染拆成小任务，在浏览器空闲时间执行。
三、Vue 性能优化（补充）
14. Vue2 / Vue3 响应式性能差异（必问）
答：
Vue2：
defineProperty递归劫持所有属性，初始化慢，无法监听新增/删除。Vue3：
Proxy懒代理，只劫持访问过的属性，性能大幅提升，支持 Map/Set。
15. Vue3 中 shallowRef / shallowReactive / markRaw 的性能意义
答：
跳过深层响应式，减少代理开销。
适合：大型不可变数据、第三方库实例（如 ECharts/Mapbox）。
16. Vue 中 v-once / v-memo 的使用场景
答：
v-once：只渲染一次，适合静态内容。v-memo：条件缓存渲染，适合列表/复杂组件，减少不必要更新。
17. Vue 编译优化：函数式组件、无状态组件的性能收益
答：
无状态组件没有实例、没有响应式系统，渲染更快。
Vue3 函数式组件性能接近原生函数。
四、工程化 / 构建优化（补充）
18. 模块规范对性能的影响：ESM vs CJS
答：
ESM 静态分析 → Tree Shaking 有效。
CJS 动态 require → Tree Shaking 失效，打包体积更大。
优化：尽量使用 ESM，避免混合使用。
19. 代码分割的进阶策略（路由分割 + 组件分割 + 逻辑分割）
答：
路由分割：基础。
组件分割：弹窗、Tab、折叠面板等懒加载。
逻辑分割：大计算/三方库动态 import。
20. 依赖预构建（Vite esbuild / Webpack DLL）原理
答：
提前把第三方依赖打包，避免每次构建重新解析/编译。
Vite 开发模式速度快的核心原因之一。
21. 产物分析工具使用（webpack-bundle-analyzer / source-map-explorer）
答：
必须会用：看哪些包体积大、是否重复打包、是否引入冗余。
常见问题：
多版本 lodash/moment
全量引入 UI 库
开发依赖被打入生产包
五、网络 / 安全 / 体验（补充）
22. 弱网/低端机性能优化（大厂高频）
答：
降级策略：
低网速：减少资源、简化 UI、关闭动画
低配置：关闭复杂计算、虚拟列表、减少 DOM
核心：感知性能 > 实际性能，骨架屏、加载状态、渐进式展示。
23. 移动端性能特有问题：
触控延迟（300ms）→
viewport+touch-action: manipulation滚动卡顿 →
overflow-scrolling: touch+ 避免滚动中重排内存限制严格 → 更要注意内存泄漏、大图、长列表
24. 跨域与性能：CORS 预检请求（OPTIONS）优化
答：
预检请求会增加一次网络往返。
优化：
简单请求（GET/HEAD/POST + 简单头）避免预检
服务端设置
Access-Control-Max-Age缓存预检结果
25. 服务端性能对前端的影响（TTFB 优化）
答：
TTFB 高 → 首屏慢。
前端可做：
接口缓存
接口合并
预请求
骨架屏兜底
六、监控与排查体系（补充，非常加分）
26. 性能预算（Performance Budget）
答：
给项目设置硬性指标：
包体积 < 200KB gzip
LCP < 2.5s
CLS < 0.1
长任务 < 50ms
构建时检查、CI 拦截，防止性能退化。
27. 性能回归测试（Performance Regression Testing）
答：
用 Lighthouse CI / WebPageTest 自动化跑性能指标。
不允许 PR 导致指标明显下降。
28. 真实用户性能（RUM） vs 实验室性能（Lab）
答：
实验室：可控、可复现、适合调试。
RUM：真实设备/网络，反映真实体验，必须做。
七、Electron 性能优化（补充）
29. Chromium 命令行开关（Chromium Flags）性能调优
答：
禁用不必要功能：
--disable-gpu-vsync--disable-renderer-backgrounding--disable-dev-shm-usage（Linux 内存问题）
开启硬件加速、渲染优化。
30. Electron 渲染进程与主进程通信性能瓶颈
答：
频繁大数据 IPC → 阻塞、卡顿。
优化：
批量发送
二进制数据（ArrayBuffer）替代 JSON
共享内存（
sharedArrayBuffer）避免同步 IPC（
sendSync）
31. Electron 内存管理：Chromium 多进程内存占用
答：
每个渲染进程都有 V8 实例，内存占用高。
优化：
限制窗口数量
及时销毁隐藏窗口
大文件/数据用流，避免一次性加载
八、面试“加分项”：性能优化体系化思维（面试官最爱）
32. 性能优化的完整方法论（你必须会说）
答：
度量：确定指标（LCP/CLS/FID/包体积）
分析：定位瓶颈（网络/渲染/JS/内存）
优化：按优先级实施
验证：复测指标
监控：长期 RUM 监控，防止回归
33. 性能优化优先级原则（面试必说）
答：
网络 > 渲染 > JS 执行 > 内存
加载性能 > 运行性能 > 包体积
用户感知 > 理论指标
九、你可以直接背的“性能优化万能模板”（面试通用）
如果面试官问：“你做过哪些性能优化？”
你可以按这个结构回答，非常稳：
指标：LCP 从 3.8s → 1.6s，FID 从 220ms → 60ms，包体积减少 40%。
分析：Lighthouse + Performance + 产物分析，定位图片大、长任务、重复渲染。
优化：
图片 WebP + 懒加载 + 骨架屏
关键 CSS 内联，非关键异步
路由/组件懒加载 + Tree Shaking
防抖节流 + 长任务拆分 + Web Worker
React.memo/useCallback/useMemo 避免重渲染
HTTP 缓存 + CDN + 预连接
结果：首屏速度提升 60%，卡顿率下降 70%，用户留存提升。
最后给你一个结论
上面这些内容 + 你之前的题集 = 前端性能优化面试全覆盖。
如果你把这些都掌握，性能优化这块你在面试里基本属于“降维打击”。
如果你愿意，我可以再给你做一份：
“性能优化面试 20 题终极押题（含标准答案）”
或者
“7 天性能优化突击计划（每天 30 分钟）”
你想要哪个？
（注：文档部分内容可能由 AI 生成）