一份某大厂外包前端二面的面试题清单

前端大大大
199 阅读17分钟

前言

大家好！我是【前端大大大】。金三银四，秋招春招，前端面试的“战火”似乎从未停歇。面对日益激烈的竞争，面试官们的问题也越来越深入，不仅考察候选人的知识广度，更注重底层原理和实践经验的深度。

一份某大厂外包二面的面试题清单，涵盖了从跨端框架、性能优化、框架原理、工程化到网络协议、后端选型等方方面面。

（注：本文将挑选部分问题进行详细解答，其余问题简要提及或给出思考方向。）

跨端框架：uni-app 与 Taro 的抉择 (Q1 & Q2)

面试官常常关心候选人对不同技术选型的理解和权衡能力。uni-app 和 Taro 作为国内流行的跨端框架，它们的核心原理和差异是常见考点。

1. uni-app 实现跨多端的原理 (Q1)

uni-app 的核心理念是 "一套代码，多端发行"。它主要通过以下方式实现：

  • 编译时转换：开发者编写 Vue.js 语法（或选择性使用 nvue 进行原生渲染），uni-app 的编译器会将这份代码根据目标平台（如微信小程序、支付宝小程序、App(iOS/Android)、H5、快应用等）转换成对应平台的代码。
    • 对于小程序端：编译成对应小程序平台的 WXML、WXSS (或 AXML/ACSS 等)、JS。
    • 对于 App 端：提供了基于 Weex (nvue) 或 WebView (vue) 的渲染方案。nvue 模式性能更好，更接近原生体验；vue 模式则更侧重 H5 生态兼容性。
    • 对于 H5 端：编译成标准的 HTML、CSS、JS。
  • 运行时适配：uni-app 提供了一套跨端的组件库和 API，在运行时进行封装和适配，抹平各端差异。开发者调用 uni.request，在不同平台会被适配成 wx.request、my.request 或 fetch 等。

2. uni-app 与 Taro 的核心差异对比 (Q2)

两者都是优秀的跨端解决方案，但设计哲学和实现路径有所不同：

特性uni-appTaro
核心框架Vue.js (主推)React (主推), Vue, Nerv
实现原理编译时为主，运行时为辅编译、运行时结合，更侧重运行时适配
转换目标源码 -> 各平台代码源码 -> 各平台代码 (小程序、H5、RN 等)
组件/API遵循小程序规范，自成体系，对 Web 生态兼容更接近 React/Web 开发体验，引入小程序组件/API
App 端方案Weex (nvue) / WebView (vue)React Native
生态DCloud 生态闭环较强，插件市场活跃社区驱动，与 React 生态结合更紧密
学习曲线对熟悉 Vue 和小程序开发的友好对熟悉 React 开发的更友好

总结：选择哪个框架取决于团队技术栈、目标平台侧重以及对生态的需求。熟悉 Vue 选 uni-app 可能更快上手，熟悉 React 则 Taro 更自然。

PDF.js 与前端性能优化 (Q3, Q4, Q5)

PDF.js 是一个广泛使用的在浏览器端渲染 PDF 的库。面试官可能会借此考察你对大型文件处理、浏览器渲染机制和性能优化的理解。

3. PDF.js 相关问题 (Q3.1 - Q3.3)

  • 协议与解析 (Q3.1)：PDF.js 实现了 PDF 文件格式规范（基于 PostScript），它通过 JavaScript 解析 PDF 文件的二进制数据，理解其内部结构（对象、流、字体、图像等），然后使用 Canvas 或 SVG 将页面内容绘制出来。
  • Lazy Loading (Q3.2)：PDF 文件通常很大。如果一次性加载并渲染所有页面，会消耗大量内存和 CPU，导致页面卡顿甚至崩溃。PDF.js 实现 lazy loading 的核心思想是按需渲染：
    1. 只加载可视区域页面：只请求和解析当前可见或即将可见（预加载）的页面数据。
    2. 分块渲染：即使是单页内容，也可以分块（tile-based）渲染，优先渲染可视部分。
    3. 后台解析：利用 Web Workers 在后台线程解析 PDF 数据，避免阻塞主线程。
    • 为什么启用后能解决卡顿？ 因为它显著减少了单次处理的数据量和渲染任务，将庞大的任务分解成小块，分布在时间或后台线程上执行，从而保持主线程的响应性。
  • 不借助 Lazy 实现卡顿优化 (Q3.3)：如果不使用 PDF.js 内建的 lazy loading，要自己实现优化，思路类似：
    1. 手动分页加载：只请求和渲染用户请求的特定页面。
    2. Web Workers：将 PDF 解析和复杂绘制计算放到 Worker 中。
    3. 虚拟滚动 (Virtual Scrolling)：只渲染可视区域内的页面 DOM 结构（或 Canvas），滚动时动态更新。
    4. 渲染优先级控制：优先渲染文本内容，图片等资源延迟加载或降低初始渲染质量。
    5. 使用 requestIdleCallback：将非关键的解析、渲染任务放到浏览器空闲时执行。

4. 前端页面渲染低于多少帧会觉得卡顿？ (Q4)

  • 理论：人眼能感知连续运动的最低帧率大约是 24 FPS (电影常用)。
  • 流畅体验：对于 UI 交互，普遍认为 60 FPS 是流畅的标准。这意味着浏览器需要在每帧大约 16.7ms (1000ms / 60) 内完成所有工作（JavaScript 执行、样式计算、布局、绘制、合成）。
  • 卡顿感知：低于 50-60 FPS，用户就可能开始感觉到不连贯或卡顿，尤其是在动画或滚动时。如果长时间低于 30 FPS，卡顿感会非常明显。

5. 如何解决 Web 上一些频繁计算导致的渲染阻塞问题？ (Q5)

渲染阻塞通常是因为 JavaScript 长时间占用了主线程。解决方法核心是避免阻塞主线程：

  • Web Workers：最有效的方法。将耗时的纯计算任务（如大数据处理、复杂算法）放到 Worker 线程执行，完成后通过 postMessage 将结果传回主线程。主线程只负责 UI 更新。
  • 任务分块 (Chunking/Time Slicing)：将一个大任务分解成多个小任务，使用 setTimeout, requestAnimationFrame, 或 requestIdleCallback 将它们分散到事件循环的不同轮次中执行，给浏览器渲染留出时间。
    • setTimeout：简单易用，但不精确，可能仍在关键渲染路径上执行。
    • requestAnimationFrame：在下一帧绘制前执行，适合动画更新，但如果任务过长仍会阻塞。
    • requestIdleCallback：利用浏览器空闲时间执行低优先级任务，是较好的选择，但要注意兼容性和回调执行不保证。
  • 异步化：对于可以异步处理的逻辑（如数据转换），尽量使用 Promise 或 async/await，但注意这只是推迟执行，如果 CPU 密集计算本身很长，仍会阻塞后续的某个事件循环。
  • 算法优化：从根本上减少计算量或复杂度。
  • 节流 (Throttling) / 防抖 (Debouncing)：对于频繁触发的事件（如resize, scroll, input）回调中的计算，使用节流或防抖来减少执行频率。

Vue 生态：原理、演进与实践 (Q6 - Q8)

Vue.js 作为主流框架，其内部原理和版本迭代差异是必考题。

6. Vue 2 vs Vue 3 原理及框架变更 (Q6)

方面Vue 2Vue 3变更说明
响应式系统Object.definePropertyProxyProxy 能代理整个对象，解决了动态添加/删除属性无法监听的问题，性能也更好。
API 风格Options APIComposition API (主推), Options API (兼容)Composition API 更好地组织逻辑、复用代码，对 TypeScript 更友好。
TypeScript 支持有限，需要 vue-class-component 等辅助原生支持，类型推导更完善TS 成为一等公民，开发体验和健壮性提升。
性能VDOM diff (全量)VDOM diff (静态标记 + Patch Flags), 静态提升, 事件缓存编译时优化更多，运行时 diff 更高效，内存占用更少。
打包体积相对固定通过 Tree-shaking 更容易实现按需引入，核心库体积更小框架设计更模块化。
新特性主要基于 Options APIFragments, Teleport, Suspense 等提供了更多高级特性，增强了灵活性。
源码FlowTypeScript源码本身更易维护和贡献。

7. 实现简易 SPA 路由 (Q7)

实现 SPA (Single Page Application) 路由的关键在于：监听 URL 变化，但不引起页面刷新，然后根据 URL 动态更新页面内容。 两种主流模式：

  • Hash 模式：
    • 原理：监听 URL 中 # (hash) 部分的变化 (window.onhashchange 事件)。
    • 优点：兼容性好，不需要服务端配置。
    • 缺点：URL 中带 #，不太美观。
    • 实现： 
      // 监听 hash 变化
window.addEventListener('hashchange', () => {
  const path = window.location.hash.slice(1) || '/'; // 获取 # 后面的路径
  renderContent(path); // 根据路径渲染对应组件/内容
});
// 初始化
renderContent(window.location.hash.slice(1) || '/');
  • History 模式：
    • 原理：使用 HTML5 History API (pushState, replaceState) 修改 URL，监听 popstate 事件（浏览器前进/后退触发）。
    • 优点：URL 更美观，符合常规 URL 格式。
    • 缺点：需要服务端配置支持。对于任意路径的请求，都应返回主 index.html 文件，否则刷新页面或直接访问子路径会 404。
    • 实现： 
      // 劫持 a 标签点击，阻止默认跳转，使用 pushState
document.body.addEventListener('click', e => {
  if (e.target.tagName === 'A' && e.target.href) {
    e.preventDefault();
    const url = new URL(e.target.href);
    window.history.pushState(null, '', url.pathname);
    renderContent(url.pathname);
  }
});
// 监听前进/后退
window.addEventListener('popstate', () => {
  renderContent(window.location.pathname);
});
// 初始化
renderContent(window.location.pathname);

8. 详细说说 Vue 3 的 diff 算法 (Q8)

Vue 3 的 diff 算法相较于 Vue 2 做了显著优化，核心在于最大化利用编译时信息，减少运行时比较开销：

  1. 静态标记 (Patch Flags)：编译器在生成 VNode 时，会分析模板中的动态内容，并给 VNode 添加 patchFlag。这个标记表明了该节点哪些部分是可能变化的（如文本内容、class、style、属性等）。在 diff 时，只需要对比带有 patchFlag 的节点及其标记的对应部分，大大减少了比较范围。例如，一个只有文本内容会变的节点，diff 时就只对比文本。
  2. 静态提升 (Static Hoisting)：对于完全静态的节点或子树（内容和属性永不改变），编译器会将其提升到 render 函数外部，每次渲染直接复用。这意味着这些静态部分完全跳过了 diff 过程。
  3. 事件监听缓存 (Cache Handlers)：默认情况下，如果 render 函数内联了事件处理器（如 @click="handler"），每次渲染都会生成新的函数实例。Vue 3 会缓存内联事件处理器，除非其依赖发生变化，否则直接复用，避免了不必要的 VNode 更新。
  4. Fragment / Block (Tree Flattening)：当一个组件根节点包含多个平级的动态节点时（如 v-for），Vue 3 会将它们组织在一个 "Block" 结构中。Block 内部的动态节点会被收集到一个扁平数组里。Diff 时，只需遍历这个扁平数组进行比较，而不需要递归遍历整个树结构。

核心思想：从“运行时尽力 diff” 变为 “编译时精准分析 + 运行时按需 diff”。

工程化与构建工具：Vite 的快与原理 (Q9 - Q11)

Vite 作为新一代构建工具，其“快”是面试高频题。

9. Vite 为什么比 Webpack 快？ (Q9)

Vite 的快主要体现在 开发服务器 (dev server) 阶段：

  • Webpack Dev Server：启动时需要先遍历整个项目依赖，进行打包构建，然后才提供服务。文件修改后，通常也需要重新打包（虽然有 HMR，但冷启动和大型项目修改仍可能慢）。
  • Vite Dev Server：
    • 冷启动快：利用浏览器原生支持 ES Module (ESM)，启动时无需打包。服务器按需编译（转换 TS/JSX、处理 CSS 等）浏览器请求的模块。只编译当前屏幕所需的代码，速度极快。
    • 热更新 (HMR) 快：当修改一个文件时，Vite 只需精确地让相关联的模块失效，浏览器重新请求这些模块即可。更新范围小，速度快，且 HMR 性能不随应用规模增大而显著下降。
    • 使用 esbuild 预构建依赖：首次启动或依赖变更时，Vite 使用 Go 编写的 esbuild 对 npm 依赖进行预构建（将 CommonJS/UMD 转为 ESM，合并大量小文件）。esbuild 比 JavaScript 编写的打包器快 10-100 倍。

生产环境构建 (build)：Vite 默认使用 Rollup 进行打包（也可以配置为 esbuild，但默认 Rollup 对应用打包优化更成熟），这方面与 Webpack 相比各有优劣，不一定绝对更快，但通常也表现优异。

10. Vite 首次启动慢怎么解决？ (Q10)

Vite 首次启动（或依赖更新后）的“慢”主要是依赖预构建 (Dependency Pre-bundling) 过程。这是使用 esbuild 完成的，虽然 esbuild 极快，但如果项目依赖非常庞大，这个过程还是需要时间的。

  • 理解本质：这个“慢”是一次性的。预构建结果会被缓存 (node_modules/.vite)，后续启动会非常快。
  • 优化手段：
    • 清理缓存：有时缓存出问题反而导致慢，可以尝试删除 node_modules/.vite 目录后重启。
    • 合理管理依赖：避免引入不必要的、过大的依赖。
    • optimizeDeps.include / exclude 配置：精确控制哪些依赖需要预构建，哪些不需要。对于某些动态 import() 的依赖，可能需要手动 include。
    • 耐心等待：对于大型项目，首次预构建需要时间是正常的。

11. Vite 预构建的实际底层原理是什么？ (Q11)

预构建（esbuild 执行）主要做两件事：

  1. CommonJS / UMD 兼容性：浏览器原生 ESM 不支持 CommonJS 或 UMD 模块。预构建将这些格式的依赖转换为 ESM 格式，使其能在浏览器中被 import。
  2. 性能优化 (减少 HTTP 请求)：许多 npm 包内部包含大量细小的模块文件（例如 lodash-es）。如果每个小文件都通过单独的 HTTP 请求加载，会导致浏览器网络拥堵，页面加载缓慢。预构建将这些包内部的多个模块合并 (bundle) 成一个或少数几个较大的 ESM 模块。这样浏览器只需要发起更少的 HTTP 请求即可加载依赖。

底层流程：Vite 启动时会扫描源码中的 import 语句，找出用到的 npm 依赖。然后调用 esbuild 对这些依赖进行：

  • 查找与解析：找到依赖入口文件。
  • 转换：将 CJS/UMD 转为 ESM。
  • 打包：将一个包内的多个文件尽可能打包成单文件 ESM。
  • 输出：将结果写入 node_modules/.vite 缓存目录。 之后，Vite Dev Server 会拦截浏览器对这些依赖的请求，直接返回缓存目录中预构建好的 ESM 文件。

网络与性能指标 (Q13 & Q14)

网络协议和性能指标是前端工程师必备的基础知识。

13. HTTP/2 对比 HTTP/1.x 的提升与优化 (Q13)

特性HTTP/1.1HTTP/2提升与优化
连接方式文本协议, 请求-响应模式二进制协议, 多路复用 (Multiplexing)减少 TCP 连接数，避免队头阻塞 (Head-of-Line Blocking)，提高传输效率。
多路复用无 (或通过 Pipelining，但问题多，基本弃用)单个 TCP 连接上可并行传输多个请求/响应流解决了 HTTP/1.1 的队头阻塞问题，资源加载更快。
头部压缩无 (或依赖通用压缩如 Gzip，效果有限)HPACK 算法 (Header Compression)维护头部字典，增量更新，显著减少请求/响应头大小，降低带宽消耗。
服务器推送 (Server Push)无服务器可主动向客户端推送资源 (如 CSS, JS)减少客户端等待时间，提前获取所需资源。（实践中需谨慎使用，可能推送非必需资源）
流量控制基于 TCP 流量控制基于流 (Stream) 的流量控制更精细化地控制数据发送，防止单个流耗尽缓冲区。

总结：HTTP/2 通过二进制分帧、多路复用、头部压缩等核心机制，大幅提升了 Web 性能，尤其是在高延迟或需要加载大量小资源的场景下。

14. 首屏指标叫什么？ (Q14)

与首屏相关的性能指标有很多，面试官可能想听的是最核心的几个：

  • FCP (First Contentful Paint)：首次内容绘制。标记了浏览器渲染出第一个来自 DOM 的内容的时间点，这个内容可以是文本、图片（包括背景图）、非空白的 canvas 或 SVG。这是用户感知页面开始加载内容的重要标志。
  • LCP (Largest Contentful Paint)：最大内容绘制。标记了视口内可见的最大图像或文本块的渲染时间。LCP 是 Core Web Vitals 之一，能很好地反映用户感知的主要内容加载速度。
  • FP (First Paint)：首次绘制。标记了浏览器首次在屏幕上渲染任何像素的时间，可能只是一个背景色，不一定是 DOM 内容。通常 FCP 会稍晚于 FP。

面试中回答 FCP (首次内容绘制) 通常是比较准确和常见的答案，因为它直接关联到用户何时看到实际内容。也可以补充 LCP 作为更重要的用户体验指标。

其他重点问题简述

  • React Hooks (Q21, Q22)
    • 解决什么问题 (Q21)：解决了 class 组件的 this 指向困扰、逻辑复用困难（HOC/Render Props 带来的“嵌套地狱”）、组件难以拆分等问题。让函数组件也能拥有状态和生命周期等能力。
    • 不能出现在判断语句里 (Q22)：React 依赖 Hook 调用的稳定顺序来关联组件实例的状态和副作用。如果在条件语句中使用 Hook，每次渲染时 Hook 的调用顺序可能不同，导致 React 无法正确匹配状态，引发错误。Vue 3 的 Composition API 在 setup 函数内没有这个限制，因为它不依赖调用顺序来关联响应式状态。
  • Node.js 与高并发 (Q26)
    • JS 是单线程的：意味着同一时间只能执行一个任务。
    • Node 如何解决高并发：核心在于异步非阻塞 I/O + 事件循环。
      1. 当遇到 I/O 操作（如文件读写、网络请求）时，Node 不会等待结果，而是将操作交给底层（libuv 的线程池或操作系统内核）处理，并注册一个回调函数。
      2. 主线程继续执行后续代码，处理其他任务。
      3. 当 I/O 操作完成，结果和回调函数会被放入事件队列。
      4. 事件循环不断检查事件队列，当主线程空闲时，取出回调函数并执行。
      • 这样，Node 主线程大部分时间都在处理计算任务或调度 I/O，而不是空闲等待，从而能用单线程响应大量并发请求（主要是 I/O 密集型）。
    • 处理 CPU 密集型任务：可以使用 worker_threads 模块创建工作线程来执行耗时计算，避免阻塞主线程。
    • 利用多核 CPU：可以使用 cluster 模块创建多个 Node.js 进程，每个进程监听同一个端口（底层由主进程分发），实现负载均衡，充分利用多核 CPU 资源。

结语

这份面试题单确实覆盖了现代前端开发的诸多关键领域。通过深入理解这些问题背后的原理和实践，不仅能帮助我们应对面试，更能实实在在地提升我们的技术实力和解决问题的能力。

记住，面试不仅仅是考察你“知道什么”，更是考察你“理解多深”以及“如何应用”。希望本文的解析能为你带来启发。如果你对其他问题有疑问，或者有不同的见解，欢迎在评论区留言讨论！

avatar
文章
阅读
粉丝