前端面试题怎么准备？围绕浏览器与用户体验

前端面试的直接准备框架

例如回答“页面为什么卡”，应区分网络下载、JavaScript解析执行、主线程长任务、布局绘制和内存问题，再结合Performance面板、真实用户指标或最小复现验证。MDN指出，Web性能既包括客观加载与运行指标，也包括用户感知；优化不能只看打包体积。

重点知识地图

事件循环应该怎样回答？

JavaScript引擎执行语言代码，浏览器等宿主提供DOM、网络和计时器。一个事件循环依次处理任务，并在适当时机处理微任务和渲染。Promise回调进入微任务队列；计时器回调在达到条件后进入任务队列，不保证精确时刻立即执行。

MDN对执行模型的说明强调，每个任务会运行到完成。若一个任务长期占用主线程，用户输入和渲染都无法及时处理。优化可以拆分长任务、减少同步计算、避免微任务无限增长，或把适合的计算转移到Worker；但DOM更新仍需在正确线程协调。

常见追问

• 为什么Promise通常先于setTimeout回调？
• 微任务不断追加会发生什么？
• async/await怎样转换为异步控制流？
• 网络请求异步为什么仍可能让页面卡顿？

从输入URL到页面可用，应该讲哪些阶段？

1. DNS、连接与安全协商建立网络通道。
2. 请求、缓存与服务端响应决定首批字节到达。
3. 浏览器解析HTML，发现CSS、脚本、字体和图片等资源。
4. 样式与DOM参与布局和绘制，脚本执行可能阻塞或改变流程。
5. 页面显示后仍要处理交互响应、异步数据、错误和布局稳定。

回答时无需机械背完整浏览器实现，而应结合问题定位瓶颈。首屏慢先看响应、资源优先级与LCP元素；点击慢看事件处理和主线程；跳动看尺寸占位与动态插入；滚动卡看绘制、合成和高频事件。

状态管理如何体现工程判断？

状态应放在能够表达其生命周期和共享范围的最小位置：局部交互留在组件内，跨页面业务状态进入明确的数据层，服务端数据需要缓存与失效策略，URL适合可分享的导航状态。不要因为使用某框架就把所有数据放进全局仓库。

性能与可访问性怎么一起回答？

性能应同时关注加载、交互与视觉稳定，并使用真实设备和网络条件。优化顺序通常从测量开始：确定关键用户路径和基线，定位最大瓶颈，做单变量改动，再防止回退。图片、字体、JavaScript和第三方脚本应按实际影响排序。

可访问性不是上线前加ARIA。优先使用语义HTML，保证键盘操作、焦点、标签、对比度、错误提示和动态状态可感知。自定义控件必须补齐原生控件已有的交互语义。可以结合自动检查，但仍需键盘和读屏器人工验证。

平台边界：浏览器、框架和性能指标会演进。本文聚焦稳定机制；具体API支持、Core Web Vitals阈值和框架行为应以当前官方文档和项目目标为准，不代表特定公司的题库。

项目经历怎样讲清前端价值？

不要只说“用了React/Vue”。按项目经历方法说明用户问题、原始表现、你负责的链路、候选方案、测量方法、上线风险和结果。性能结果要注明设备、网络、样本与分位数；体验改进要说明如何验证，而不是只用“更流畅”。

复杂交互可以从状态模型讲起：有哪些状态、事件怎样改变状态、异步失败如何恢复、移动端与键盘如何操作、测试覆盖哪些边界。这样能同时体现技术和产品判断。

常见问题

框架原理需要讲多深？

至少能解释组件更新、状态与副作用、列表标识和性能问题如何产生。具体内部实现应声明版本，不确定时回到官方文档或可复现实验。

为什么不要滥用memo？

记忆化本身有比较与维护成本，也可能掩盖状态设计问题。先用测量确认瓶颈，再对稳定、昂贵且高频的计算或渲染优化。

前端安全常问什么？

常见方向包括XSS、CSRF、CSP、跨域、依赖风险和敏感数据处理。回答应区分浏览器约束与服务端鉴权，前端隐藏按钮不能替代权限控制。

没有大型项目怎么办？

用真实小项目说明可验证的设计、测试与改进过程。规模不能虚构，清晰推理比夸大流量更有价值。