字节-今日头条-校招 · 第 1 轮 · 二面

我在XX公司实习期间，参与了一个内部运营效率工具的开发，其中我主导了"智能数据报表系统"的前端部分，这个项目我个人觉得做得比较好。项目背景是，之前的运营数据统计完全依赖人工手动导出和整理，效率低下且易出错。我们团队的目标是构建一个自动化、可视化的报表系统，让运营人员能够实时查看核心数据指标。

我主要负责报表的可视化组件开发和数据交互逻辑。在技术选型上，我没有简单地套用现有图表库，而是深入调研了业务需求，最终选择了ECharts进行定制化开发，因为它的灵活性和丰富图表类型能很好地满足我们多样化的报表展示需求。开发过程中最大的挑战是如何处理海量数据在前端的渲染性能问题。初期我们尝试直接加载全部数据，导致页面卡顿严重。我查阅资料并与后端协商，最终采用了数据分批加载和前端数据虚拟化的方案，即只加载当前视图所需数据，并对表格和图表进行局部渲染。这不仅大幅提升了页面响应速度，也降低了后端的数据传输压力。

另一个亮点是，我设计并实现了一个可配置的报表生成器。运营人员可以通过拖拽组件、配置数据源和筛选条件，自定义生成各种报表，极大地提高了他们的工作效率，也减少了开发人员的维护成本。在项目上线后，我通过用户反馈持续迭代，例如增加了数据导出功能、优化了图表联动效果，使得系统更加完善。这个项目让我深刻体会到了前端工程化和性能优化的重要性，也锻炼了我从需求分析到方案设计、再到具体实现和持续优化的全链路项目能力。

我们团队负责的XX系统，其整体架构是一个典型的微前端应用。具体来说，我们采用了基于qiankun的微前端方案，将整个系统拆分为多个独立的子应用，例如用户管理、订单中心、数据分析等。每个子应用都可以独立开发、独立部署，但在主应用中进行集成和路由管理。这样的好处是，团队成员可以专注于各自的子应用开发，降低了耦合度，也便于技术栈的演进和模块的复用。

当我接到一个开发任务时，通常会遵循以下步骤：

首先是需求分析和理解。我会仔细阅读需求文档，明确用户故事和业务目标，如果存在不清晰的地方，会主动与产品经理或设计师沟通，确保我对需求的理解是准确和全面的。这一步至关重要，它决定了后续开发的方向。

其次是技术方案设计。我会根据需求，结合当前项目的架构和技术栈，思考实现方案。这包括：是否需要新增组件或模块？数据流如何设计？接口如何定义？是否涉及到性能优化或兼容性问题？例如，如果是一个新功能模块，我会考虑其在微前端架构下的集成方式，以及与主应用之间的通信机制。如果涉及复杂的数据处理，我会优先考虑数据在前端的缓存策略，以及如何减少不必要的渲染。

接着是代码实现。我会根据设计好的方案，开始编写代码。我会严格遵循团队的代码规范和组件化原则，确保代码的可读性和可维护性。在实现过程中，我会注重模块的拆分和函数的封装，避免出现冗余代码。

在开发过程中，我非常重视自测和调试。我会编写单元测试和集成测试，确保自己实现的功能符合预期。如果遇到问题，会利用浏览器开发工具进行调试，分析问题原因并及时解决。此外，我也会关注代码的性能，例如使用Chrome DevTools进行性能分析，寻找优化点。

最后是代码评审和部署。在完成开发和自测后，我会提交代码进行代码评审，听取团队成员的建议，并对代码进行优化。通过评审后，会按照CI/CD流程进行部署，并在部署后关注线上监控，确保功能稳定运行。

这种结构化的开发流程，使得我在面对复杂任务时能够有条不紊地进行，并能及时发现和解决问题，保障了项目的开发质量和效率。

1.1 原理说明

IntersectionObserver 的事件回调是微任务。

• 宏任务 (MacroTask)：包括 script (整体代码)、setTimeout、setInterval、setImmediate (Node.js 独有)、I/O、UI 渲染等。每次事件循环只会执行一个宏任务，执行完后会检查微任务队列。
• 微任务 (MicroTask)：包括 Promise.then()/.catch()/.finally()、MutationObserver、process.nextTick (Node.js 独有)、queueMicrotask。微任务在当前宏任务执行完毕后，下一个宏任务开始之前执行，且会清空所有微任务。

IntersectionObserver 的回调函数被设计为微任务，是为了保证在当前帧的 DOM 更新完成之后、但浏览器渲染之前执行。这样可以确保在回调函数中进行的 DOM 操作能够及时反映在当前帧的渲染中，避免了不必要的布局抖动或视觉闪烁。

1.2 核心用法 + 示例代码

IntersectionObserver 用于异步观察目标元素与其祖先元素或顶级文档视窗（viewport）交叉状态的变化。

示例代码：

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      console.log('目标元素进入可视区域');
      // 可以在这里加载图片、执行动画等
    } else {
      console.log('目标元素离开可视区域');
    }
  });
});

const targetElement = document.getElementById('my-element');
observer.observe(targetElement);

console.log('主线程代码执行完毕');

// 模拟一个 Promise，其then回调也是微任务
Promise.resolve().then(() => {
  console.log('Promise.then 是微任务');
});

// 模拟一个 setTimeout，其回调是宏任务
setTimeout(() => {
  console.log('setTimeout 是宏任务');
}, 0);

判断方法： 要判断 IntersectionObserver 的回调是宏任务还是微任务，可以通过以下实验：

1. 在 IntersectionObserver 回调函数内部放置 console.log。
2. 在主线程代码中，在 IntersectionObserver.observe() 之后，立即放置 Promise.then() 和 setTimeout(..., 0)。
3. 观察控制台输出的顺序。

如果 IntersectionObserver 的回调在 Promise.then() 之后、setTimeout 之前执行，则说明它是微任务。

实验结果分析： 你会发现输出顺序通常是：

1. 主线程代码执行完毕
2. Promise.then 是微任务
3. 目标元素进入可视区域 或 目标元素离开可视区域 (IntersectionObserver 回调)
4. setTimeout 是宏任务

这个顺序明确表明 IntersectionObserver 的回调与 Promise.then 属于同一优先级队列，即微任务队列。

1.3 常见误区或面试陷阱

• 误区： 认为所有异步操作都是宏任务。这是常见的误解，尤其是在不清楚微任务概念的情况下。
• 陷阱： 不了解 IntersectionObserver 的设计目的和它为什么选择微任务。面试官可能会追问为什么 IntersectionObserver 回调是微任务而不是宏任务，这时需要结合其性能优化（避免布局抖动）和浏览器渲染时机进行解释。
• 陷阱： 将其与 MutationObserver 混淆。两者都是微任务，但应用场景不同。MutationObserver 观察 DOM 树的变动，而 IntersectionObserver 观察元素的交叉状态。
• 注意点： IntersectionObserver 回调是异步执行的，如果需要在回调中进行大量计算或复杂 DOM 操作，可能会影响页面响应性。但在大多数情况下，由于其微任务的特性，它能提供更好的性能表现。

1.1 原理说明

在虚拟列表中，当元素高度不定时，确定滚动条的位置是一个复杂的问题。传统的虚拟列表通常依赖于固定高度来快速计算每个元素的偏移量 (offset) 和总高度。然而，当元素高度不固定时，我们就无法简单地通过索引和固定高度来计算这些值。这会导致：

1. 无法准确计算每个元素的 top 和 bottom 偏移量：由于每个元素的高度未知，我们无法预先确定它们在列表中的确切位置。
2. 滚动条 scrollTop 与实际渲染内容的不匹配：当用户滚动时，scrollTop 值不再能直接映射到某个元素的精确位置，因为每个元素的高度都不一样。
3. 滚动跳动 (Jumpiness)：如果不能及时、准确地更新元素高度和位置信息，用户在滚动时会感受到明显的跳动。

为了解决这些问题，核心思想是：预估高度 + 动态测量与缓存真实高度 + 补偿偏移量。

1.2 核心用法 + 示例代码

处理不定高虚拟列表滚动条位置的关键在于维护一个数据结构来存储每个元素的真实高度和累积偏移量。

核心步骤：

1. 初始化预估高度： 在首次渲染时，为所有元素设置一个预估高度。这个预估值可以是一个平均高度，或者基于内容类型的一个经验值。这个预估高度用于首次计算总高度和每个元素的初始位置。

2. 测量并缓存真实高度：

   • 当元素首次进入可视区域并被渲染时，需要通过 getBoundingClientRect() 或其他方式测量其真实高度。
   • 将测量到的真实高度存储起来（例如，在一个 Map 或数组中，以元素索引为键）。
   • 一旦真实高度被确定，后续计算就使用真实高度而不是预估高度。

3. 计算累积偏移量： 维护一个列表，记录每个元素上方的累积高度（即该元素顶部的偏移量）。这个累积偏移量是其前面所有元素真实高度（或预估高度）的总和。

4. 根据滚动位置确定显示范围：

   • 当 scrollTop 发生变化时，不能直接通过 scrollTop / itemHeight 来确定起始索引。
   • 需要遍历累积偏移量列表，找到第一个累积偏移量大于 scrollTop 的元素，即为可视区域的起始元素索引 (startIndex)。
   • 同理，计算 endIndex。

5. 处理高度差异引起的偏移： 当预估高度与真实高度不一致时，会导致总高度和元素偏移量发生变化。这会造成滚动条的"跳动"或位置不准确。为了解决这个问题，需要引入一个"补偿偏移量"(offset-correction)。

   • 补偿偏移量是所有已渲染元素"真实高度"与"预估高度"之间的差值的累积。
   • 在计算滚动条高度(scrollHeight)和元素的 top 样式时，需要加上这个补偿偏移量，以修正因为高度差异而产生的视觉偏差。

示例数据结构：

// 存储每个元素的真实高度和顶部偏移量
const itemPositions = []; // [{ index: 0, height: 50, top: 0, bottom: 50 }, ...]

// 假设有一个函数来更新 itemPositions
function updateItemPosition(index, height) {
  const existingPosition = itemPositions[index];
  if (existingPosition && existingPosition.height === height) {
    return; // 高度未变，无需更新
  }

  // 更新当前元素的真实高度
  itemPositions[index] = { ...existingPosition, height: height };

  // 重新计算从当前元素开始后续所有元素的 top/bottom，并更新总高度
  let currentTop = 0;
  for (let i = 0; i < itemPositions.length; i++) {
    if (itemPositions[i]) {
      itemPositions[i].top = currentTop;
      itemPositions[i].bottom = currentTop + itemPositions[i].height;
      currentTop += itemPositions[i].height;
    } else {
      // 如果还未测量，使用预估高度
      currentTop += ESTIMATED_ITEM_HEIGHT;
    }
  }
  // 更新总高度 (scrollHeight)
  // totalHeight = currentTop;
}

// 根据 scrollTop 找到可见区域的起始和结束索引
function getVisibleRange(scrollTop, containerHeight) {
  let startIndex = 0;
  let currentOffset = 0;
  for (let i = 0; i < itemPositions.length; i++) {
    const item = itemPositions[i];
    const itemHeight = item ? item.height : ESTIMATED_ITEM_HEIGHT;
    if (currentOffset + itemHeight > scrollTop) {
      startIndex = i;
      break;
    }
    currentOffset += itemHeight;
  }

  let endIndex = startIndex;
  let visibleHeight = 0;
  for (let i = startIndex; i < itemPositions.length; i++) {
    const item = itemPositions[i];
    const itemHeight = item ? item.height : ESTIMATED_ITEM_HEIGHT;
    visibleHeight += itemHeight;
    if (visibleHeight > containerHeight) {
      endIndex = i;
      break;
    }
    endIndex = i; // 确保至少包含一个元素
  }

  return { startIndex, endIndex };
}

// 在滚动时，根据 startIndex 和 endIndex 渲染对应的数据，并动态设置每个元素的 top 样式
// 例如： element.style.top = `${itemPositions[index].top}px`;

1.3 常见误区或面试陷阱

• 误区： 认为只要在元素渲染后测量高度就万事大吉。仅仅测量高度是不够的，还需要将真实高度缓存起来，并更新累积偏移量，否则在再次滚动到该区域时还会重新测量，造成性能浪费和跳动。
• 陷阱： 忽略了滚动条跳动问题。当真实高度与预估高度差异较大时，如果没有进行适当的偏移量补偿，滚动条会出现明显的"跳动"，严重影响用户体验。这通常需要调整 container 的 padding-top 和 padding-bottom 来模拟未渲染区域的空间，或者通过调整 scrollTop 来纠正位置。
• 陷阱： 频繁地进行 DOM 测量。getBoundingClientRect() 是一个同步操作，如果对所有元素都进行测量，会造成性能问题。只在元素首次进入可视区域时进行测量，并缓存结果，是更优的方案。
• 注意点： 滚动到特定位置 (scrollToIndex) 的实现会更加复杂，需要根据目标索引的累积偏移量来设置 scrollTop，并且要考虑到该元素上方的补偿偏移量。
• 注意点： 对于新增或删除数据的情况，itemPositions 数组需要进行相应的更新和重新计算，以保持数据的一致性。

是的，在我的虚拟列表实现过程中，我确实对一些主流的第三方虚拟列表插件进行了对比和学习，例如react-window、react-virtualized以及一些基于Vue的虚拟列表库。对比主要从几个维度进行：性能优化（尤其是大数据量渲染和滚动时的流畅度）、功能完整性（是否支持不定高、滚动到指定位置、动态增删数据等）、API易用性、以及代码可维护性。

我自己的实现，在性能上，主要针对了我们业务场景下常见的列表项高度不一致的问题，采用了"预估高度+动态测量与缓存+补偿偏移量"的方案，这在一定程度上达到了与react-virtualized等库类似的不定高支持能力。我们通过MutationObserver或者ResizeObserver监听子元素的高度变化，并及时更新缓存和重绘，确保了滚动体验的平滑。在初始渲染时，我的实现更轻量，没有引入额外的复杂逻辑，核心代码量较小，这使得它在项目初期集成时更容易理解和维护。

然而，与成熟的第三方插件相比，我的实现也存在一些局限性。例如，react-virtualized提供了更丰富的功能，比如列虚拟化、网格虚拟化、自动计算高度等，并且经过了大量的社区验证和性能优化，在极端复杂场景下可能表现更稳定。同时，这些插件通常会有更好的错误处理机制和更全面的文档支持。我的实现目前主要服务于特定业务场景，对于通用性、更复杂的交互需求，可能需要投入更多精力去完善，而第三方库在这方面已经提供了现成的解决方案。

通过这次对比和自研，我深刻理解了虚拟列表的核心原理，包括如何平衡预估与真实高度、如何处理滚动跳动等挑战。同时，也认识到在实际项目中，选择自研还是引入第三方库，需要根据项目需求、团队资源和维护成本进行权衡。对于一些通用且复杂的组件，成熟的第三方库往往是更高效和可靠的选择；但自研能让我们对技术有更深入的掌控，并能更好地适配特定的业务场景。

在直播这种不断推送新消息的场景下，设计一个高效、稳定且用户体验良好的系统，需要从数据传输、前端渲染和后端处理多个层面综合考虑。我会主要从以下几个方面进行设计：

1. 数据传输层面：选择合适的协议与机制 对于实时消息推送，HTTP短轮询或长轮询效率较低。我会优先考虑使用WebSocket。WebSocket提供了全双工通信，建立一次连接后，服务器可以主动向客户端推送消息，极大地降低了网络延迟和连接开销，非常适合直播间这种高并发、低延迟的场景。此外，为了确保消息的顺序性和不丢失，可以考虑在应用层引入消息ID或序列号机制，并在客户端进行去重和排序。

2. 前端渲染与性能优化：避免页面卡顿

• 虚拟列表/消息列表优化： 直播间消息量非常大，如果全部渲染会导致页面卡顿。我会采用**虚拟列表（或虚拟滚动）**技术，只渲染可视区域内的消息，对于快速滚动的场景，甚至可以适当降低渲染帧率或延迟加载非核心信息，确保UI的流畅性。针对不定高消息，需要结合"预估高度+动态测量"的方案。
• 消息合并与节流： 对于短时间内大量消息涌入的情况，可以考虑在客户端对消息进行合并或节流处理。例如，将多条相似消息合并为一条显示（如"XXX进入直播间"连续出现多次），或者限制每秒渲染的消息数量，将超出部分暂存，待UI空闲时再逐渐渲染，避免瞬间的渲染压力。
• 离屏渲染与CSS优化： 消息列表的渲染可以考虑使用transform而非top/left进行定位，减少DOM回流重绘。对于非必要的DOM元素，可以使用display: none或完全移除，减少浏览器渲染负担。
• 弹幕优化： 如果有弹幕功能，弹幕也需要独立进行渲染优化，例如使用Canvas或WebGL进行高性能渲染，而不是简单的DOM操作，并且要控制弹幕的数量和显示密度。

3. 后端架构与消息分发：支撑高并发

• 消息队列： 后端服务应引入消息队列（如Kafka、RabbitMQ）来缓冲和处理大量的消息。直播用户发送的消息首先进入消息队列，再由消费者服务异步处理，并将处理后的消息推送到WebSocket服务。
• 水平扩展： WebSocket服务器、消息处理服务都应设计为可水平扩展的架构，通过负载均衡器分发请求，以应对直播高峰期的巨大并发量。
• CDN/边缘计算： 对于直播流本身，通常会通过CDN进行分发，确保全球用户都能低延迟地观看。

4. 用户体验与容错

• 消息通知与提示： 当有新消息但用户不在底部时，可以通过提示（如"有新消息"）引导用户点击回到最新消息。
• 断线重连： 客户端需要实现WebSocket的断线重连机制，确保网络波动时能自动恢复消息接收。
• 错误日志与监控： 完善的前端错误日志上报和后端监控系统，能够及时发现和解决问题。

总的来说，这是一个系统工程，需要前后端紧密协作。前端侧注重渲染效率和用户体验，后端侧则侧重于高并发处理和消息可靠性。

1.1 原理说明

在用户快速关闭页面的场景下，传统的异步数据上报方式（如 fetch、XMLHttpRequest）往往会失败，因为浏览器会立即终止所有未完成的网络请求以加速页面卸载。为了解决这个问题，我们需要利用浏览器在页面卸载阶段提供的一些特殊机制，确保数据能够可靠地发送到服务器。

主要涉及的事件和机制有：

1. beforeunload 事件：

   • 在页面即将卸载时触发，此时页面仍然可见，允许执行少量同步操作。
   • 可以用来提示用户保存数据，但如果事件处理函数中进行耗时操作或弹出提示，会阻塞页面关闭，影响用户体验。
   • 不推荐在此事件中发送异步请求，因为它无法保证请求完成。

2. unload 事件：

   • 在页面完全卸载时触发，此时页面文档处于只读状态，DOM 元素已不可用，所有网络活动几乎都被停止。
   • 传统异步请求（fetch 或 XMLHttpRequest）在此事件中发送几乎都会失败，因为它们被视为"不可靠的"。

3. visibilitychange 事件：

   • 当页面的可见状态（document.hidden）发生改变时触发，例如用户切换标签页、最小化窗口或离开当前页面。
   • 在页面进入后台（document.hidden 为 true）但尚未关闭时，这是一个较好的时机来发送非关键的、或需要在用户离开前立即上报的数据。此时页面仍然处于活跃状态，可以发送异步请求。

4. navigator.sendBeacon() 方法：

   • 这是专门为在页面卸载时发送少量数据而设计的 API。
   • 非阻塞：它不会阻塞页面关闭，因此不会影响用户体验。
   • 异步且可靠：浏览器会保证在后台异步发送数据，即使页面已经关闭，请求也会继续完成，只要浏览器进程还在运行。
   • 限制：主要用于发送少量数据（通常是 POST 请求），并且不能自定义请求头、不能获取响应。
   • 是解决"页面快速关闭前获取数据"的最佳实践。

5. 同步 XMLHttpRequest (不推荐)：

   • 在 beforeunload 或 unload 事件中，理论上可以使用同步的 XMLHttpRequest 来发送数据，因为同步请求会阻塞页面卸载直到请求完成。
   • 严重缺点：会阻塞用户界面，导致页面关闭体验极差，在现代 Web 开发中强烈不推荐使用。仅在极少数、对数据可靠性要求极高且能接受用户体验牺牲的场景下可能考虑（例如某些遗留系统）。

1.2 核心用法 + 示例代码

最佳实践是结合 visibilitychange 和 unload 事件，并利用 navigator.sendBeacon() 进行数据上报。

使用 navigator.sendBeacon() (推荐方式):

// 假设这是需要上报的埋点数据
let userActionsData = [];

function trackUserAction(actionType, details) {
  userActionsData.push({
    timestamp: Date.now(),
    action: actionType,
    details: details
  });
  // 可以在每次操作后立即发送（例如，对于关键、实时数据）
  // 或者积累到一定量或在页面关闭时发送
  // console.log('Action tracked:', actionType, details);
}

// 模拟用户操作
trackUserAction('click', { element: 'button-A' });
trackUserAction('scroll', { position: '50%' });

// 监听页面即将卸载的事件
window.addEventListener('beforeunload', () => {
  if (userActionsData.length > 0) {
    const blob = new Blob([JSON.stringify(userActionsData)], { type: 'application/json' });
    // sendBeacon 会在后台发送数据，不会阻塞页面关闭
    // 确保这里的 URL 是你的埋点服务器地址
    const success = navigator.sendBeacon('/api/track-events', blob);
    console.log('sendBeacon attempt on beforeunload:', success ? 'succeeded' : 'failed');
    userActionsData = []; // 清空数据，避免重复发送
  }
});

// 或者监听 visibilitychange 事件，在页面进入后台时发送
document.addEventListener('visibilitychange', () => {
  if (document.hidden && userActionsData.length > 0) {
    const blob = new Blob([JSON.stringify(userActionsData)], { type: 'application/json' });
    const success = navigator.sendBeacon('/api/track-events', blob);
    console.log('sendBeacon attempt on visibilitychange (hidden):', success ? 'succeeded' : 'failed');
    userActionsData = []; // 清空数据
  }
});

// 对于单页应用 (SPA)，需要在路由切换时模拟"页面卸载"逻辑
// 例如：
/*
function setupSPATracking() {
  let lastPath = window.location.pathname;
  window.addEventListener('popstate', () => { // 监听前进后退
    handleSPARouteChange(lastPath, window.location.pathname);
    lastPath = window.location.pathname;
  });

  // 监听你的路由框架的路由变化事件
  // 例如 for React Router: history.listen()
  // for Vue Router: router.beforeEach
  // 假设有一个自定义事件 'routeChange'
  window.addEventListener('routeChange', (event) => {
    const { from, to } = event.detail; // 从事件中获取路由信息
    handleSPARouteChange(from, to);
  });
}

function handleSPARouteChange(oldPath, newPath) {
  if (userActionsData.length > 0) {
    const blob = new Blob([JSON.stringify(userActionsData)], { type: 'application/json' });
    navigator.sendBeacon('/api/track-spa-events', blob);
    console.log(`sendBeacon for SPA route change from ${oldPath} to ${newPath}`);
    userActionsData = [];
  }
}

// setupSPATracking();
*/

同步 XMLHttpRequest (仅作了解，强烈不推荐):

// 不推荐这种方式，会阻塞页面关闭
// window.addEventListener('beforeunload', () => {
//   if (userActionsData.length > 0) {
//     const xhr = new XMLHttpRequest();
//     xhr.open('POST', '/api/track-events', false); // true for async, false for sync
//     xhr.setRequestHeader('Content-Type', 'application/json');
//     xhr.send(JSON.stringify(userActionsData));
//     console.log('Synchronous XHR sent on beforeunload.');
//     userActionsData = [];
//   }
// });

1.3 常见误区或面试陷阱

• 误区： 认为在 unload 事件中使用 fetch 或 XMLHttpRequest 异步发送数据是可靠的。实际上，这些异步请求在 unload 阶段很容易被浏览器取消，导致数据丢失。
• 陷阱： 在 beforeunload 事件中执行耗时操作或同步请求。这会显著延迟页面的卸载，导致糟糕的用户体验，用户会感觉页面卡顿。面试官可能会追问如何避免阻塞页面。
• 陷阱： 没有考虑到 navigator.sendBeacon() 的局限性。它主要用于发送少量数据，不能获取服务器响应，也不能进行复杂的请求配置（如自定义请求头、CORS 凭证等）。
• 注意点： sendBeacon 不支持发送大文件或复杂二进制数据，因为它是一个"小而美"的 API。
• 注意点： 对于单页应用 (SPA)，页面的切换并不触发传统的 unload 或 beforeunload 事件。因此，需要监听路由变化事件（如 popstate 或前端路由库提供的事件），在路由切换时执行数据上报逻辑。
• 注意点： sendBeacon 并非 100% 保证发送成功，例如浏览器崩溃、用户断网等极端情况仍可能导致数据丢失。但它比其他异步请求在卸载阶段的可靠性高得多。
• 注意点： 数据持久化。如果对数据丢失的容忍度极低，可以考虑将数据先存储在 localStorage 或 sessionStorage 中，下次页面加载时再尝试发送。但这会增加复杂性。

1.1 原理说明

Monorepo（Mono Repository）是一种代码管理策略，它将多个项目的代码存储在一个版本控制仓库中。与传统的 Polyrepo（Poly Repository，即多个项目对应多个仓库）相反，Monorepo 旨在通过集中管理来解决多项目开发中的一些痛点，例如代码共享、版本管理和依赖管理。

核心概念：

• 单一仓库，多个包/项目： 所有的相关项目（例如一个组件库的多个组件、一个应用的多个微服务、前端和后端代码等）都放在同一个 Git 仓库中。
• 独立发布： 尽管代码在同一个仓库中，但每个包或项目仍然可以独立地进行版本管理和发布。
• 集中式依赖管理： 共享的依赖可以被统一管理，减少重复安装和版本冲突。
• 工具支持： 通常会配合 Lerna、Yarn Workspaces、Nx 等工具来管理不同包之间的依赖、构建和发布。

Monorepo 的出现是为了解决在大型项目或组织中，随着项目数量和复杂性的增加，Polyrepo 模式下可能遇到的问题，例如：

• 代码重复： 多个项目可能需要相同的工具函数、UI 组件或业务逻辑，Polyrepo 容易导致代码复制粘贴。
• 版本管理复杂： 共享库的更新需要同时更新所有依赖它的项目，版本管理和协调成本高。
• 跨项目重构困难： 涉及到多个项目的重构操作，在 Polyrepo 模式下需要克隆多个仓库，操作繁琐。
• 开发环境搭建： 新成员加入时，需要克隆和设置多个仓库，增加了 onboarding 成本。

1.2 核心用法 + 示例代码

在前端领域，Monorepo 常用于构建组件库、微前端架构或大型应用。以下是结合 Yarn Workspaces 和 Lerna 的简单示例：

使用 Yarn Workspaces： Yarn Workspaces 允许在 Monorepo 中管理多个包，并通过 yarn install 一次性安装所有包的依赖，并将内部依赖通过软链接（symlink）的方式链接起来，无需发布到 npm。

步骤：

1. 创建根目录和 package.json：

   // package.json (根目录)
   {
     "name": "my-monorepo",
     "private": true, // 阻止发布到 npm
     "workspaces": [
       "packages/*" // 定义工作区，所有子包都放在 packages 目录下
     ]
   }
   

2. 创建子包：

   my-monorepo/
   ├── package.json
   └── packages/
       ├── package-a/
       │   └── package.json
       └── package-b/
           └── package.json
   

   packages/package-a/package.json:

   {
     "name": "package-a",
     "version": "1.0.0",
     "main": "index.js",
     "dependencies": {
       "package-b": "^1.0.0" // 内部依赖
     }
   }
   

   packages/package-b/package.json:

   {
     "name": "package-b",
     "version": "1.0.0",
     "main": "index.js"
   }
   

3. 安装依赖： 在根目录运行 yarn install。Yarn 会自动处理 package-a 对 package-b 的内部依赖，将其软链接到 node_modules 中。

结合 Lerna (更强大的 Monorepo 管理工具)： Lerna 是一个管理包含多个 JavaScript/TypeScript 包的仓库的工具，它提供了更高级的功能，如发布管理、版本控制等。

步骤：

1. 初始化 Lerna：

   npx lerna init
   

   这会生成 lerna.json 和 packages 目录（如果不存在）。
2. 管理依赖和发布： Lerna 提供命令来批量运行脚本、安装依赖、发布包等。
   • lerna bootstrap: 安装所有包的依赖，并处理内部依赖。
   • lerna run <script>: 在所有包中运行指定的 npm 脚本（例如 lerna run build）。
   • lerna publish: 发布更新的包到 npm。

使用场景：

• 组件库开发： 将所有 UI 组件作为独立的包，统一管理、测试和发布。
• 微前端架构： 将不同的微应用或共享模块放在同一个仓库中，便于协调和集成。
• 全栈项目： 前端应用、后端 API、共享的类型定义等放在一个仓库中。

解决了什么问题/优势：

• 代码共享与复用： 内部包之间可以轻松地共享代码，避免重复开发。
• 统一依赖管理： 共享的第三方依赖可以提升安装速度，减少重复依赖。
• 简化版本管理： 对于相互依赖的包，可以统一管理版本，避免版本不兼容问题。
• 原子化提交与测试： 一个提交可以影响多个项目，测试也更容易在整个仓库范围内进行。
• 提升开发体验： 新开发者 onboarding 更快，所有代码在一个地方，IDE 索引更高效。
• 更清晰的依赖关系： 内部包之间的依赖关系一目了然。

相比其他方案的优势： 相比 Polyrepo，Monorepo 在代码共享、版本协调和跨项目重构方面具有显著优势。它减少了多仓库管理带来的碎片化和复杂性，提高了开发效率和项目维护性。

1.3 常见误区或面试陷阱

• 误区： 认为 Monorepo 意味着所有代码都必须紧密耦合。实际上，Monorepo 强调的是逻辑上的独立，技术上允许将独立包放在同一个仓库中，它们仍然是独立的单元。
• 陷阱： 忽视 Monorepo 带来的构建和测试复杂性。随着包的数量增加，整个仓库的构建和测试时间可能会变长，需要配合增量构建、缓存等优化策略。
• 陷阱： 认为 Monorepo 适用于所有项目。对于非常小或完全独立的单个项目，Polyrepo 可能更简单直接。Monorepo 更适合于有大量共享代码、多团队协作或需要频繁进行跨项目重构的场景。
• 注意点： Git 仓库大小问题。虽然所有代码在一个仓库，但 Git 本身对大仓库的支持也在不断优化。合理使用 Git LFS 等工具，以及关注仓库大小，是需要考虑的。
• 注意点： CI/CD 流水线设计。Monorepo 下的 CI/CD 需要能够识别哪些包发生了变化，只对受影响的包进行构建和部署，这需要更精细的配置。
• 注意点： 工具选择。Yarn Workspaces、npm Workspaces、Lerna、Nx、Turborepo 等工具各有特点，选择合适的工具对于 Monorepo 的成功实施至关重要。

1.1 原理说明

Monorepo 的"对比其他方式"主要是指与 Polyrepo（多仓库）模式的对比。Polyrepo 模式是每个项目或组件都有自己独立的版本控制仓库。而 Monorepo 将多个相关项目或包的代码放在一个统一的仓库中。

Monorepo 最大的好处可以概括为以下几点，这些优势共同提升了大型团队和复杂项目的开发效率和维护性：

1.2 核心优势

1. 简化代码共享与复用 (Code Sharing and Reuse Simplification)

   • 优势说明： 在 Monorepo 中，所有包都在同一个文件系统中，内部包之间的依赖引用变得非常简单和直观，通常通过软链接（如 Yarn Workspaces）实现。这意味着你可以直接 import 或 require 同一个仓库中的其他包，而无需发布到 npm 或处理复杂的本地路径。
   • 解决了什么问题： 避免了在 Polyrepo 中，为了共享代码而需要频繁发布共享库到 npm、处理版本兼容性、或者进行大量的复制粘贴。这极大地提高了代码的复用率和一致性，减少了"重复造轮子"的情况，并降低了维护成本。

2. 统一依赖管理与版本协调 (Unified Dependency Management and Version Coordination)

   • 优势说明： 所有的第三方依赖可以集中在根目录的 package.json 中管理（通过工作区工具），或者至少在子包之间可以清晰地看到和协调依赖版本。当你升级一个共享依赖时，所有依赖它的子包都可以轻松地同步更新，减少了版本冲突的风险。
   • 解决了什么问题： 在 Polyrepo 中，一个共享库的版本升级可能需要手动更新所有引用它的项目，这可能导致不同项目使用不同版本的共享库，造成"依赖地狱"和不兼容问题。Monorepo 通过统一管理，确保了整个项目生态系统的依赖版本一致性。

3. 原子化提交与跨项目重构 (Atomic Commits and Cross-Project Refactoring)

   • 优势说明： 可以在一个 Git 提交中修改多个相互关联的包。这意味着如果一个功能的实现或一个重构涉及到多个组件或模块，你可以一次性完成所有相关的改动，并作为一个单一的、原子性的提交。这样，代码库的变更历史更加清晰，更容易理解。
   • 解决了什么问题： 在 Polyrepo 中，涉及多个仓库的重构或功能开发需要多次提交，并且需要在不同仓库之间切换。这使得代码评审、问题追溯和变更回滚变得复杂和繁琐。Monorepo 简化了这种跨项目的操作，提高了开发效率和代码质量。

4. 提升开发体验与协作效率 (Improved Developer Experience and Collaboration Efficiency)

   • 优势说明： 新加入的开发者只需要克隆一个仓库，就可以获取到所有相关项目的代码，极大地简化了开发环境的搭建过程。开发者可以在一个统一的 IDE 中进行所有项目的开发，方便进行全局搜索、代码跳转和调试。团队成员之间对彼此的代码结构和逻辑也更容易理解，促进了知识共享和协作。
   • 解决了什么问题： 在 Polyrepo 中，新开发者需要克隆和设置多个仓库，熟悉多个项目的构建流程，增加了 onboarding 成本。同时，由于代码分散，跨项目协作和问题排查也相对困难。

1.3 常见误区或面试陷阱

• 陷阱： 只提 Monorepo 的好处，不提其潜在的挑战。面试官可能会追问 Monorepo 的缺点或适用场景。例如，仓库体积增大、CI/CD 复杂性增加、构建时间变长等，需要配合工具和策略来解决这些问题。
• 误区： 认为 Monorepo 就是简单的把所有代码放到一个文件夹里。Monorepo 并非简单粗暴的堆叠，而是需要配合专业的工具（如 Yarn Workspaces, Lerna, Nx, Turborepo）来有效管理和利用其优势。
• 注意点： 混淆 Monorepo 和微服务。Monorepo 是一种代码组织方式，而微服务是一种服务架构。它们可以结合使用（在一个 Monorepo 中管理多个微服务），但本身不是同一个概念。
• 注意点： 对于小型项目或完全没有关联的项目，强制使用 Monorepo 可能反而会增加不必要的复杂性。 Monorepo 更适合于有大量共享代码、多团队协作或需要频繁进行跨项目重构的场景。

是的，我对我在XX公司实习期间所处的部门和公司的主要业务都有比较深入的了解。

我所在的部门是前端体验部，主要职责是负责公司核心产品线的用户界面开发和前端性能优化。我们公司的主要业务是提供[简单描述公司的主营业务，例如：面向企业的SaaS解决方案，或者提供To C的在线教育平台]。具体到我参与的XX项目，它是[说明项目所属的具体业务领域，例如：面向运营人员的内部效率工具，或是面向用户的核心交易平台]。

我认为我们公司的业务核心在于[提出你对公司业务的理解，例如：通过技术赋能，提升企业客户的运营效率；或者通过优质内容和技术平台，为用户提供沉浸式的学习体验]。我观察到，公司非常注重用户反馈和数据驱动，不断迭代产品以满足市场需求。例如，在我参与的智能数据报表系统中，其最终目标就是帮助运营团队更高效地分析用户行为，从而优化产品策略，这直接支持了公司的业务增长。

作为一名前端开发者，我的工作不仅仅是实现UI功能，更重要的是理解这些功能背后的业务价值。例如，我在优化虚拟列表性能时，考虑的不仅仅是技术指标，更是为了确保运营人员在大数据量下也能流畅地查看报表，不影响他们的决策效率。这种将技术实现与业务目标相结合的思考方式，让我能够更好地理解我的工作对公司业务的贡献，并以此驱动我不断提升技术能力去解决实际的业务问题。

1.1 原理说明

LCR 091. 粉刷房子是一道经典的动态规划问题。

• 题目描述：假如有一排房子，共 n 个，每个房子可以被粉刷成红色、蓝色或者绿色这三种颜色中的一种，你需要粉刷所有的房子并且使其相邻的两个房子颜色不能相同。当然，因为市场上不同颜色油漆的价格不同，所以房子粉刷成不同颜色的花费成本也是不同的。每个房子粉刷成不同颜色的花费是以一个 n x 3 的正整数矩阵 costs 来表示的。请计算出粉刷完所有房子最少的花费成本。

• 动态规划思想：此问题具有最优子结构和重叠子问题。我们可以定义状态 dp[i][j] 为粉刷到第 i 个房子，且第 i 个房子粉刷成颜色 j 时的最小花费。

  • 状态定义： dp[i][0] 表示粉刷完第 i 个房子，且第 i 个房子粉刷成红色时的最小花费。 dp[i][1] 表示粉刷完第 i 个房子，且第 i 个房子粉刷成蓝色时的最小花费。 dp[i][2] 表示粉刷完第 i 个房子，且第 i 个房子粉刷成绿色时的最小花费。

  • 状态转移方程： 由于相邻房子颜色不能相同，当粉刷第 i 个房子时，其颜色 j 的花费，需要加上粉刷第 i-1 个房子时，选择非颜色 j 的两种颜色中的最小花费。

    • dp[i][0] = costs[i][0] + min(dp[i-1][1], dp[i-1][2]) (第 i 个房子粉刷红色，第 i-1 个房子只能是蓝色或绿色)
    • dp[i][1] = costs[i][1] + min(dp[i-1][0], dp[i-1][2]) (第 i 个房子粉刷蓝色，第 i-1 个房子只能是红色或绿色)
    • dp[i][2] = costs[i][2] + min(dp[i-1][0], dp[i-1][1]) (第 i 个房子粉刷绿色，第 i-1 个房子只能是红色或蓝色)

  • 边界条件： 对于第一个房子 (i = 0)，其最小花费就是粉刷成对应颜色的成本。 dp[0][0] = costs[0][0] dp[0][1] = costs[0][1] dp[0][2] = costs[0][2]

  • 最终结果是 min(dp[n-1][0], dp[n-1][1], dp[n-1][2])。

1.2 核心用法 + 示例代码

非空间优化版本：

function minCost(costs) {
    const n = costs.length;
    if (n === 0) return 0;

    // dp[i][j] 表示粉刷到第 i 个房子，且第 i 个房子粉刷成颜色 j 时的最小花费
    // j = 0: 红色, j = 1: 蓝色, j = 2: 绿色
    const dp = Array(n).fill(0).map(() => Array(3).fill(0));

    // 边界条件：第一个房子的花费
    dp[0][0] = costs[0][0];
    dp[0][1] = costs[0][1];
    dp[0][2] = costs[0][2];

    // 状态转移
    for (let i = 1; i < n; i++) {
        dp[i][0] = costs[i][0] + Math.min(dp[i - 1][1], dp[i - 1][2]);
        dp[i][1] = costs[i][1] + Math.min(dp[i - 1][0], dp[i - 1][2]);
        dp[i][2] = costs[i][2] + Math.min(dp[i - 1][0], dp[i - 1][1]);
    }

    // 结果是最后一个房子粉刷成三种颜色中的最小花费
    return Math.min(dp[n - 1][0], dp[n - 1][1], dp[n - 1][2]);
}

// 示例 1：
// console.log(minCost([[17,2,17],[16,16,5],[14,3,19]])); // 输出: 10
// 示例 2：
// console.log(minCost([[7,6,2]])); // 输出: 2

空间优化版本（滚动数组）： 由于 dp[i] 的值只依赖于 dp[i-1] 的值，我们可以使用滚动数组（两个大小为 3 的数组）来优化空间复杂度，将其从 O(n) 降低到 O(1)。

function minCostOptimized(costs) {
    const n = costs.length;
    if (n === 0) return 0;

    // current_dp 存储当前房子的最小花费
    // prev_dp 存储上一个房子的最小花费
    let prev_dp = [costs[0][0], costs[0][1], costs[0][2]];

    for (let i = 1; i < n; i++) {
        let current_dp = [0, 0, 0];
        current_dp[0] = costs[i][0] + Math.min(prev_dp[1], prev_dp[2]);
        current_dp[1] = costs[i][1] + Math.min(prev_dp[0], prev_dp[2]);
        current_dp[2] = costs[i][2] + Math.min(prev_dp[0], prev_dp[1]);
        prev_dp = current_dp; // 更新 prev_dp 为当前计算出的最小花费
    }

    return Math.min(prev_dp[0], prev_dp[1], prev_dp[2]);
}

// 示例 1：
// console.log(minCostOptimized([[17,2,17],[16,16,5],[14,3,19]])); // 输出: 10
// 示例 2：
// console.log(minCostOptimized([[7,6,2]])); // 输出: 2

在项目中为什么会使用、在哪些环节使用： 动态规划是一种解决具有重叠子问题和最优子结构问题的重要算法范式。在前端领域，虽然不直接粉刷房子，但其思想可以应用于：

• 资源加载优化：例如，在分批加载图片或数据时，根据用户的行为和资源优先级动态调整加载策略，以最小化加载时间或带宽消耗。
• UI 布局优化：在某些复杂的布局场景中，可能需要计算元素的最优位置或大小，以满足特定约束条件，动态规划可以帮助寻找最优解。
• 前端动画：在复杂的动画序列中，如果涉及到多个元素的相互影响和最优路径选择，可以考虑动态规划。

该技术方案解决了什么问题，相比其他方案有什么优势： 动态规划解决了暴力枚举带来的指数级时间复杂度问题。通过存储子问题的解，避免了重复计算，从而将时间复杂度降低到多项式级别。在本题中，如果没有动态规划，直接递归尝试所有可能的颜色组合，会非常低效。

1.3 常见误区或面试陷阱

• 误区： 忘记处理边界条件。动态规划问题通常需要正确初始化最开始的状态（例如 dp[0]）。
• 陷阱： 状态转移方程错误。未能正确理解相邻房子颜色不能相同的限制，导致状态转移逻辑出错。
• 陷阱： 空间复杂度优化不足。面试官可能会要求进行空间优化，如果只给出 O(n) 的解法而没有考虑滚动数组优化，可能会被认为对动态规划的理解不够深入。
• 注意点： 对于 min 函数的用法，C++ 中 std::min 可以比较两个参数，但要比较多个需要嵌套使用或使用 *std::min_element。JavaScript 的 Math.min 可以直接传入多个参数。
• 注意点： 没有正确理解"动态规划"和"递归"的区别。虽然动态规划可以用递归（带备忘录）实现，但通常我们更倾向于自底向上的迭代实现，因为它可以避免递归栈溢出，并且更容易进行空间优化。

1.1 原理说明

数组扁平化（Array Flattening）是将一个多维数组转换成一个一维数组的过程。例如，[1, [2, 3], [4, [5, 6]]] 扁平化后变为 [1, 2, 3, 4, 5, 6]。这是一个在数据处理和结构转换中常见的需求。

1.2 核心用法 + 示例代码

方法一：使用 Array.prototype.flat() (非尾递归，ES2019) 这是最简洁的内置方法，可以指定扁平化深度。

const arr = [1, [2, 3], [4, [5, 6]]];
console.log(arr.flat(Infinity)); // [1, 2, 3, 4, 5, 6]

flat() 方法内部实现可能不是尾递归，但对于一般使用场景足够高效。

方法二：递归实现 (非尾递归)

function flattenRecursive(arr) {
  let result = [];
  for (let i = 0; i < arr.length; i++) {
    if (Array.isArray(arr[i])) {
      result = result.concat(flattenRecursive(arr[i]));
    } else {
      result.push(arr[i]);
    }
  }
  return result;
}

// console.log(flattenRecursive([1, [2, 3], [4, [5, 6]]]));

这种递归方式在每次递归调用后需要等待子递归的结果进行 concat 或 push，因此不是尾递归。当数组嵌套层级很深时，可能会导致栈溢出。

方法三：尾递归实现 尾递归的特点是，递归调用是函数体中最后执行的操作，并且其返回值直接作为函数的返回值，不需要在上一层函数中进行额外的计算。在JavaScript中，虽然V8引擎（以及其他JS引擎）没有强制实现尾调用优化（Tail Call Optimization, TCO），但理解尾递归的思想并尝试实现它仍然是重要的。实现尾递归通常需要引入一个累加器（accumulator）参数来保存中间结果。

function flattenTailRecursive(arr, result = []) {
  if (arr.length === 0) {
    return result;
  }

  const [head, ...tail] = arr; // 解构出头部和剩余部分

  if (Array.isArray(head)) {
    // 如果头部是数组，先扁平化头部数组，再与剩余部分合并进行下一次递归
    // 注意：这里仍然存在一个隐含的 concat 操作，严格意义上的TCO较难在JS中完美实现
    // 但思想上是"累加"扁平化结果
    return flattenTailRecursive(tail, flattenTailRecursive(head, result));
  } else {
    // 如果头部不是数组，直接添加到结果中，并处理剩余部分
    return flattenTailRecursive(tail, result.concat(head));
  }
}

// console.log(flattenTailRecursive([1, [2, 3], [4, [5, 6]]]));
// console.log(flattenTailRecursive([1, [2, [3, [4]]], 5]));

更常见的"伪尾递归"或者说基于迭代模拟尾递归的扁平化方案（使用栈）： 由于JavaScript引擎对尾调用优化的支持不一致，更实用的方式是通过迭代（例如使用循环和栈）来模拟尾递归的"累加"效果，从而避免栈溢出。

function flattenIterativeStack(arr) {
  const stack = [...arr]; // 将数组元素放入栈中
  const result = [];
  while (stack.length) {
    // 注意：这里使用 shift() 会影响性能，如果追求极致性能可使用 pop() 配合 reverse() 或其他方式
    const item = stack.shift();
    if (Array.isArray(item)) {
      // 如果是数组，将数组元素倒序推入栈中，这样下次循环先处理的是内部数组的第一个元素
      stack.unshift(...item);
    } else {
      result.push(item);
    }
  }
  return result;
}

// console.log(flattenIterativeStack([1, [2, 3], [4, [5, 6]]]));
// console.log(flattenIterativeStack([1, [2, [3, [4]]], 5]));

在项目中为什么会使用、在哪些环节使用：

• 数据处理与转换： 当从后端获取的数据结构是多维数组，而前端需要扁平化处理后才能进行展示或进一步计算时，会使用数组扁平化。例如，树形结构数据转换为列表。
• 兼容性处理： 如果目标运行环境不支持 Array.prototype.flat()（老旧浏览器或Node.js版本），则需要手动实现扁平化逻辑。
• 特定算法实现： 在某些算法（如深度优先搜索）中，扁平化操作可能是中间步骤。

该技术方案解决了什么问题，相比其他方案有什么优势：

• 解决了多维数组处理的复杂性： 将复杂的多维结构简化为一维，便于后续的数据操作和遍历。
• 尾递归的优势（理论上）： 相比普通递归，尾递归在支持尾调用优化的引擎中可以避免栈溢出，从而处理更深嵌套的数组，提高程序稳定性。但如前所述，JS引擎对其支持不一。
• 迭代方案的优势： 基于迭代（如栈）的扁平化方案，则能完全避免递归栈的限制，对于任意深度的嵌套数组都能稳定处理，并且通常性能也很好。

1.3 常见误区或面试陷阱

• 误区： 认为 Array.prototype.flat() 可以处理所有扁平化需求，忘记了它有深度限制（默认1，Infinity扁平化所有）。
• 陷阱： 混淆普通递归和尾递归。未能正确识别尾递归的条件（最后一步操作是递归调用且返回值直接返回）。
• 陷阱： 没有考虑到栈溢出问题。对于深层嵌套的数组，普通递归可能会导致栈溢出，需要思考迭代或尾递归的优化方案。
• 注意点： JavaScript 对尾调用优化（TCO）的支持并不普遍（尤其是在浏览器环境中），所以即便写出严格的尾递归形式，也可能无法获得性能上的优化。在面试中，应该明确指出这一点，并提出迭代方案作为更稳健的选择。
• 注意点： 扁平化操作的性能，尤其是当数组元素数量非常大时，要考虑 concat 操作可能带来的性能损耗（因为它会创建新数组）。