阿里-盒马-校招 · 第 1 轮 · 一面

参考模版如下，一般3分钟以内即可。
面试官您好！我叫[姓名]，毕业于[毕业院校]，专业是[专业名称]。我有XX段前端开发实习经验，熟练掌握HTML、CSS、JavaScript等前端技术栈，主要的技术栈是React。在XX公司实习期间，主要参与过供应链管理系统和微信小程序开发，学习了前端相关专业技术，以及熟悉了项目的整体流程，同时积累了丰富的项目经验。

在探讨 React 虚拟 DOM（Virtual DOM）所解决的问题时，不能简单地将其归结为“性能更快”，这实际上是一个常见的误区。

从长期的工程实践和框架演进来看，虚拟 DOM 核心解决了以下几个维度的挑战：

1. 解决跨平台与抽象层的问题

虚拟 DOM 最本质的贡献在于建立了一层声明式的抽象。在传统的 Web 开发中，代码直接耦合在真实的 DOM 环境中。而虚拟 DOM 将复杂的 UI 转换成了一种轻量级的 JavaScript 对象结构（即 VNode）。

这种抽象层使得 React 脱离了浏览器的物理限制。因为 VNode 只是普通的 JS 对象，它不仅可以被渲染为浏览器的 DOM，也可以被渲染为移动端的原生控件（React Native）、服务端字符串（SSR）甚至是 Canvas 绘制指令。它解决了 UI 描述与底层渲染引擎之间的强耦合问题，实现了“一次学习，随处编写”的愿景。

2. 解决复杂 UI 状态下的开发效率

在原生 DOM 时代，开发者需要手动管理状态与 UI 的同步。当页面状态变得错综复杂时，命令式的 DOM 操作（如 appendChild 或 removeChild）会导致代码难以维护且极易出错。

虚拟 DOM 配合 Diff 算法，将“手动更新”转变为“自动收集并批量更新”。开发者只需要关注状态（State）的变化，React 会自动计算出新旧视图的差异并进行补丁式更新。这极大地降低了心智负担，解决了在大规模应用中如何保持代码整洁与状态一致性的难题。

3. 解决性能的下限与补丁式优化

虽然手动编写极致优化的原生 DOM 操作在性能上理论上永远优于框架，但在生产环境下，大部分开发者很难在每一处逻辑中都做到最优。虚拟 DOM 实际上是提供了一个性能下限的保障。

它通过 Diff 算法避免了频繁且大面积的真实 DOM 重排（Reflow）与重绘（Repaint）。当状态发生多次变化时，虚拟 DOM 会在内存中完成所有的计算和比对，最后只对真实 DOM 进行一次最小化的、批量的修改。它解决的是在不进行精细化手动优化的前提下，依然能让复杂的 Web 应用保持流畅运行的问题。

作为前端开发者，必须修正一个常见的认知偏误：虚拟 DOM 本身并不比原生 DOM 快。

事实上，没有任何框架的操作能比经过极致优化的原生 JS 操作更高效。

虚拟 DOM 真正的优势在于：在复杂应用和频繁状态变更的场景下，它能通过算法策略，规避开发者可能写出的低效代码，从而保证性能的“下限”。

以下是深度解析：

1. 减少昂贵的重排（Reflow）与重绘（Repaint）

真实 DOM 的属性极其沉重（包含成百上千个属性），且与浏览器的渲染引擎深度耦合。当我们频繁操作真实 DOM 时，每一步修改都可能触发浏览器的样式计算、布局（Layout）和绘制（Painting）。

在 DOM 结构复杂时，一次细微的节点变动可能会引发连锁反应，导致整棵渲染树的重新计算。虚拟 DOM 通过在内存中维护一个轻量级的 JS 对象，将所有的改动先在内存中进行计算，最终只将**差量（Delta）**一次性应用到真实 DOM 上，极大地减少了浏览器渲染管线的触发频率。

2. 批量处理与合并更新（Batching）

在复杂交互中，一个操作可能触发多个状态变更。如果直接操作真实 DOM，可能会连续触发多次渲染流程。

• 原生操作：修改 10 次 DOM，浏览器可能会尝试进行多次重绘。
• 虚拟 DOM：它具有“缓冲”作用。React 等框架会将短时间内的多次 setState 合并，在内存中完成 10 次虚拟 DOM 的构建和 Diff 比对，最后对真实 DOM 只执行 1 次 必要的更新。这种合并机制在复杂结构下能显著降低计算开销。

3. 差量更新（Diffing Algorithm）

当 DOM 树非常深且复杂时，手动寻找最精确的更新点是非常耗时的。如果开发者为了省事直接使用 innerHTML 替换父容器，会导致所有子节点被销毁并重新创建，这在性能上是灾难性的。

虚拟 DOM 的 Diff 算法通过同层比较、唯一标识（Key）等策略，能够精确识别出哪些节点是移动了、哪些是属性变了、哪些是真正需要删除的。它解决了**“全量替换”导致的资源浪费**。

4. 跨越“性能陷阱”的均值保证

在大型团队开发中，不同水平的开发者编写的代码质量参差不齐。虚拟 DOM 的意义在于提供了一个高性能的默认行为。它让一个普通开发者写出的代码，在处理复杂 DOM 结构时，也能拥有接近资深开发者手动优化后的性能表现。它解决的是工程化环境下的平均性能问题。

一、是什么

响应式网站设计（Responsive Web design）是一种网络页面设计布局，页面的设计与开发应当根据用户行为以及设备环境(系统平台、屏幕尺寸、屏幕定向等)进行相应的响应和调整

描述响应式界面最著名的一句话就是“Content is like water”

大白话便是“如果将屏幕看作容器，那么内容就像水一样”

响应式网站常见特点：

• 同时适配PC + 平板 + 手机等

• 标签导航在接近手持终端设备时改变为经典的抽屉式导航

• 网站的布局会根据视口来调整模块的大小和位置

二、实现方式

响应式设计的基本原理是通过媒体查询检测不同的设备屏幕尺寸做处理，为了处理移动端，页面头部必须有meta声明viewport

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no”>

属性对应如下：

• width=device-width: 是自适应手机屏幕的尺寸宽度

• maximum-scale:是缩放比例的最大值

• inital-scale:是缩放的初始化

• user-scalable:是用户的可以缩放的操作

实现响应式布局的方式有如下：

• 媒体查询
• 百分比
• vw/vh
• rem

媒体查询

CSS3 中的增加了更多的媒体查询，就像if条件表达式一样，我们可以设置不同类型的媒体条件，并根据对应的条件，给相应符合条件的媒体调用相对应的样式表

使用@Media查询，可以针对不同的媒体类型定义不同的样式，如：

@media screen and (max-width: 1920px) { ... }

当视口在375px - 600px之间，设置特定字体大小18px

@media screen (min-width: 375px) and (max-width: 600px) {
  body {
    font-size: 18px;
  }
}

通过媒体查询，可以通过给不同分辨率的设备编写不同的样式来实现响应式的布局，比如我们为不同分辨率的屏幕，设置不同的背景图片

比如给小屏幕手机设置@2x图，为大屏幕手机设置@3x图，通过媒体查询就能很方便的实现

百分比

通过百分比单位 " % " 来实现响应式的效果

比如当浏览器的宽度或者高度发生变化时，通过百分比单位，可以使得浏览器中的组件的宽和高随着浏览器的变化而变化，从而实现响应式的效果

height、width属性的百分比依托于父标签的宽高，但是其他盒子属性则不完全依赖父元素：

• 子元素的top/left和bottom/right如果设置百分比，则相对于直接非static定位(默认定位)的父元素的高度/宽度

• 子元素的padding如果设置百分比，不论是垂直方向或者是水平方向，都相对于直接父亲元素的width，而与父元素的height无关。

• 子元素的margin如果设置成百分比，不论是垂直方向还是水平方向，都相对于直接父元素的width

• border-radius不一样，如果设置border-radius为百分比，则是相对于自身的宽度

可以看到每个属性都使用百分比，会照成布局的复杂度，所以不建议使用百分比来实现响应式

vw/vh

vw表示相对于视图窗口的宽度，vh表示相对于视图窗口高度。 任意层级元素，在使用vw单位的情况下，1vw都等于视图宽度的百分之一

与百分比布局很相似，在以前文章提过与%的区别，这里就不再展开述说

rem

在以前也讲到，rem是相对于根元素html的font-size属性，默认情况下浏览器字体大小为16px，此时1rem = 16px

可以利用前面提到的媒体查询，针对不同设备分辨率改变font-size的值，如下：

@media screen and (max-width: 414px) {
  html {
    font-size: 18px
  }
}

@media screen and (max-width: 375px) {
  html {
    font-size: 16px
  }
}

@media screen and (max-width: 320px) {
  html {
    font-size: 12px
  }
}

为了更准确监听设备可视窗口变化，我们可以在css之前插入script标签，内容如下：

//动态为根元素设置字体大小
function init () {
    // 获取屏幕宽度
    var width = document.documentElement.clientWidth
    // 设置根元素字体大小。此时为宽的10等分
    document.documentElement.style.fontSize = width / 10 + 'px'
}

//首次加载应用，设置一次
init()
// 监听手机旋转的事件的时机，重新设置
window.addEventListener('orientationchange', init)
// 监听手机窗口变化，重新设置
window.addEventListener('resize', init)

无论设备可视窗口如何变化，始终设置rem为width的1/10，实现了百分比布局

除此之外，我们还可以利用主流UI框架，如：element ui、antd提供的栅格布局实现响应式

小结

响应式设计实现通常会从以下几方面思考：

• 弹性盒子（包括图片、表格、视频）和媒体查询等技术
• 使用百分比布局创建流式布局的弹性UI，同时使用媒体查询限制元素的尺寸和内容变更范围
• 使用相对单位使得内容自适应调节
• 选择断点，针对不同断点实现不同布局和内容展示

三、总结

响应式布局优点可以看到：

• 面对不同分辨率设备灵活性强
• 能够快捷解决多设备显示适应问题

缺点：

• 仅适用布局、信息、框架并不复杂的部门类型网站
• 兼容各种设备工作量大，效率低下
• 代码累赘，会出现隐藏无用的元素，加载时间加长
• 其实这是一种折中性质的设计解决方案，多方面因素影响而达不到最佳效果
• 一定程度上改变了网站原有的布局结构，会出现用户混淆的情况

优化rem计算可以通过以下方式实现：

1. 设置基准字体大小：在`html`标签上设置基准字体大小（如`html { font-size: 16px; }`），并根据屏幕宽度动态调整。<br>
2. 使用CSS预处理器：通过Sass或Less等工具定义变量，简化rem计算。<br>
3. 使用JavaScript动态计算：根据屏幕宽度动态调整`html`字体大小，从而实现更灵活的rem布局。

解决浏览器兼容性问题可以通过以下方式：

1. 使用CSS前缀：为CSS属性添加浏览器前缀（如`-webkit-`、`-moz-`等）。<br>
2. 使用Polyfills：为不支持某些特性的浏览器提供兼容性补丁。<br>
3. 使用Babel：将ES6+代码转换为兼容性更好的ES5代码。<br>
4. 测试：使用浏览器兼容性测试工具（如BrowserStack）进行多浏览器测试，及时修复兼容性问题。

微信小程序有自己的框架，主要是为了：

1. 性能优化：通过自定义的渲染引擎和组件体系，提升小程序的运行效率。<br>
2. 安全性和稳定性：严格限制外部代码的执行，确保小程序的安全性和稳定性。<br>
3. 用户体验：提供更流畅的交互体验，与微信生态深度集成。<br>
4. 开发规范：提供统一的开发规范和组件库，便于开发者快速开发和维护。

在微信生态中，小程序与 H5 网页虽然都使用前端技术栈（HTML/CSS/JS），但两者在性能表现和用户体验上存在显著差异。

从小程序底层的“双线程”架构到 H5 的传统 Web 运行机制，这种差异源于设计思路的根本不同。

1. 架构层面的区别：双线程 vs 单线程

这是导致性能差异的最根本原因。

• H5 网页（单线程机制）：运行在标准的 WebView 中，其 JS 逻辑执行和 UI 渲染都在同一个线程中。这意味着如果 JS 逻辑计算量过大，会直接阻塞页面的渲染或交互，造成明显的“卡顿”感。
• 微信小程序（双线程架构）：将运行环境拆分为渲染层（WebView）和逻辑层（AppService/JSCore）。
• 逻辑层：负责 JS 脚本运行，运行在独立的沙箱环境中，不涉及 DOM 操作。
• 渲染层：负责页面展现，使用 WebView 渲染。
• 优势：这种分离保证了即使逻辑层在处理复杂计算，渲染层依然能响应用户的滚动、触摸等交互。

2. 加载与启动性能：离线包 vs 实时加载

• H5 网页：本质上是远程 URL。用户每次打开 H5 都要经历 DNS 解析、TCP 连接、SSL 握手以及 HTML/JS/CSS 的下载和解析。即使有 HTTP 缓存，首屏加载受网络波动的影响依然非常大。
• 小程序：采用了**“离线包”机制**。当用户初次访问或有版本更新时，微信会下载整个代码包到本地。
• 预加载：微信会预先启动小程序的运行环境。
• 本地执行：打开页面时直接从本地磁盘读取静态资源，几乎抵消了网络加载的时间损耗。

3. 系统权限与原生组件的调用

• H5 网页：受限于浏览器安全沙箱，对系统权限（如蓝牙、传感器、复杂文件系统）的访问非常受限，且通常需要经过 JS-SDK 桥接，链路较长。
• 小程序：提供了大量原生组件（Native Components）。例如地图、视频播放、相机等。这些组件不是由 WebView 渲染，而是由微信客户端直接在页面上方叠加的原生视图。这种“混合渲染”模式让高负载组件的性能（如滑动流畅度、编解码效率）直接对标原生 App。

4. 渲染机制的约束与优化

• H5 网页：开发者可以随意操作 DOM。但在移动端，不规范的 DOM 操作极易引发全量重排（Reflow），导致性能崩溃。
• 小程序：严禁直接操作 DOM。所有 UI 变更必须通过 setData 触发。这种限制看似降低了灵活性，实则强制开发者遵循数据驱动的范式。微信底层会对 setData 的数据进行 Diff 和 Patch 优化，减少了不必要的渲染开销。

在处理字符串逆序的问题时，常规思路往往涉及字符串的分割与重新拼接。

但在面试场景下，考察的重点通常是如何在不依赖高级语言内置函数（如 split().reverse().join()）的情况下，利用底层指针操作实现极致的内存优化。

1. 基础方案：辅助空间法

最直观的方法是遍历字符串，利用空格识别每个单词，将其提取出来存入一个数组或栈中，最后再按逆序重新拼接。

• 逻辑：遍历一遍输入字符串 O(n) ，存储单词列表。
• 空间复杂度：由于需要创建一个新的数组来存储所有单词，或者最终生成一个新的结果字符串，其空间开销与原字符串长度成正比，即 O(n)。

2. 空间复杂度 O(1) 的优化方案

要实现原地（In-place）逆序，核心思路是利用**“局部逆序 + 整体逆序”**的数学特性。

算法步骤：

1. 整体反转：首先将整个字符串的首尾字符进行对调，彻底反转。此时，单词的位置已经排到了最后，但单词内部的字母顺序也是反的（例如：how old dlo woh）。
2. 局部反转：利用双指针遍历这个已经反转的字符串，找到每个空格的位置，从而锁定每个单词的边界。对每个单独的单词再次执行首尾对调反转。
3. 结果：经过两次反转，单词内部的顺序恢复正常，而单词在句子中的顺序实现了逆序（例如：dlo woh old how）。

代码逻辑实现：

function reverseWords(s) {
    // 假设 s 是字符数组，以便原地修改
    let n = s.length;

    // 1. 翻转整个字符串
    reverse(s, 0, n - 1);

    // 2. 翻转每个单词
    let start = 0;
    for (let end = 0; end < n; end++) {
        if (s[end] === ' ') {
            reverse(s, start, end - 1);
            start = end + 1;
        } else if (end === n - 1) {
            reverse(s, start, end);
        }
    }
    return s;
}

function reverse(arr, left, right) {
    while (left < right) {
        [arr[left], arr[right]] = [arr[right], arr[left]];
        left++;
        right--;
    }
}

3. 复杂度分析

• 时间复杂度：虽然进行了两次翻转，但本质上每个字符被访问的次数是常数级别的，因此时间复杂度依然是 O(n)。
• 空间复杂度：在翻转过程中，我们只使用了极少数的辅助变量（如指针 left, right, start），没有开辟与输入规模相关的额外空间。因此，空间复杂度达到了 O(1)。

ToB 业务：效率驱动与逻辑复杂性的治理

以供应链管理系统为代表的 toB 场景，其核心逻辑在于业务建模的精准度与长生命周期的可维护性。这类系统通常具有极其复杂的表单交互、庞大的数据表格以及严苛的权限控制逻辑。

在应对策略上，前端工作的重心应当从“视觉表现”转向“领域建模”。由于供应链涉及采购、仓储、物流等多个环节，前端需要通过高度抽象的元数据驱动（Metadata-driven）方案来解决页面同质化严重的问题。例如，通过配置化的方式生成复杂的查询表单与数据看板，减少重复劳动。同时，这类系统的用户通常是专业操作员，操作的连贯性与系统的稳定性远比首屏加载速度重要。因此，前端架构应重点关注复杂状态管理（如多页签下的数据同步）、长列表渲染性能以及在大规模数据流下的内存管理。此外，建立健壮的内部组件库和标准化的操作规范是降低培训成本、提高业务流转效率的关键。

ToC 业务：体验驱动与极致性能的转化

微信小程序与 H5 App 构成的 toC 业务场景，其核心逻辑在于低摩擦的用户路径与多端环境的适应性。在移动端互联网环境下，用户对加载延迟和交互卡顿的容忍度极低，这直接关联到业务的转化率与留存率。

应对 toC 业务时，策略应当聚焦于极致的性能优化与端对端的兼容性。对于 H5，需要建立完善的资源加载策略，包括服务端渲染（SSR）或静态预渲染（SSG）、关键路径 CSS 提取、以及基于 CDN 的智能缓存方案。针对微信小程序，则需深入理解其双线程架构的特性，规避频繁的 setData 调用带来的性能瓶颈。在业务快速迭代的过程中，如何利用埋点监控体系实时捕获用户行为，并针对弱网、低端设备进行降级处理，是保障用户体验的核心手段。此外，toC 业务往往伴随着营销活动的瞬时高并发，前端需要与后端配合，在静态资源分发和 API 限流保护上建立闭环。

差异化共存与工程化支撑

尽管两者的目标不同，但在同一公司体系下，应当在工程化底层寻找共性。通过建立统一的 CI/CD 流程和自动化测试标准，可以确保无论业务类型如何，代码质量都能维持在基准线之上。

对于 toB 业务，工程化更倾向于提供强大的调试工具和静态检查，防止复杂业务逻辑在迭代中产生副作用；对于 toC 业务，工程化则应侧重于自动化性能审计、多端构建产物的同构化处理，以及针对不同屏幕尺寸的响应式适配方案。在技术决策中，应当根据业务的生命周期阶段动态调整投入配比：在业务探索期利用低代码或模版化方案快速验证，在业务成熟期通过重构和精细化性能调优来筑高技术壁垒。