钉子的生活日记
文章目录

TMEqq音乐前端暑期二面整理笔记（四十一）

1. 虚拟列表怎么实现的

答案

如果项目里既提过 Webpack 又提过 Vite，建议先说明主用哪一个，再对比原因。

  1. Webpack 生态更老更全，适合历史项目和高度定制场景。
  2. Vite 开发态基于原生 ESM，冷启动和热更新通常更快，适合现代前端项目。
  3. 如果面试官追问，一定补上：开发态和生产构建的策略不一样，不能只说“Vite 更快”。

2. 一道性能指标采集代码找错误

答案

这类题通常在考你对性能指标采集时机和 API 的理解。

  1. 要先确认指标采集是不是放在正确生命周期，比如 PerformanceObserver、paint、largest-contentful-paint 等。
  2. 再看是否存在重复监听、时机过早、数据读取不准确、未清理 observer 等问题。
  3. 回答时可以强调：指标采集最怕“采到了，但不准”。

3. 文件上传是怎么实现的

答案

文件上传这类题建议按完整链路回答：

  1. 前端先按大小阈值切片，通常 2MB 到 10MB 比较常见。
  2. 上传前计算文件 hash，服务端据此判断是否已存在完整文件或部分分片。
  3. 断点续传时，前端先查询已上传分片列表，只补传缺失分片。
  4. 全部分片上传完成后，通知服务端按顺序合并。
  5. 秒传一般基于完整文件 hash；分片 hash 更多用于断点续传和重复分片复用。
  6. 分片不是越多越好：分太小请求数会暴涨，分太大失败重传成本高，所以要结合网络、文件大小和后端承载能力权衡。

4. 大文件分片上传时，计算 5MB 分片 MD5 大概要多久

答案

文件上传这类题建议按完整链路回答：

  1. 前端先按大小阈值切片，通常 2MB 到 10MB 比较常见。
  2. 上传前计算文件 hash，服务端据此判断是否已存在完整文件或部分分片。
  3. 断点续传时，前端先查询已上传分片列表，只补传缺失分片。
  4. 全部分片上传完成后，通知服务端按顺序合并。
  5. 秒传一般基于完整文件 hash；分片 hash 更多用于断点续传和重复分片复用。
  6. 分片不是越多越好：分太小请求数会暴涨，分太大失败重传成本高，所以要结合网络、文件大小和后端承载能力权衡。

5. 如果文件很大，计算完整文件 MD5 很耗时，有什么性能优化方案

答案

大文件算完整 MD5 耗时长，核心优化思路是“分片 + Worker + 增量计算”。

  1. 不要一次性把整个文件读进主线程。
  2. 按分片读取并增量计算 hash。
  3. 计算过程放到 Web Worker，避免页面卡顿。
  4. 如果业务允许，可以优先用分片 hash 配合后端做断点续传。

6. Web Worker 在大文件 MD5 计算里能怎么用

答案

Web Worker 的作用是把计算密集型任务移出主线程，避免页面卡顿。

  1. 适合大文件 hash、复杂解析、图片压缩、数据预处理。
  2. 它不能直接操作 DOM。
  3. 主线程和 Worker 通过 postMessage 通信，大对象传输时要注意成本。

7. 服务端保存所有分片索引和分片文件，会不会导致碎片文件越来越多

答案

会，如果没有治理，碎片文件和索引确实会不断积累。

  1. 所以服务端要有上传会话状态和过期清理机制。
  2. 未完成上传的分片要定期回收。
  3. 合并完成后也要清理临时分片目录。

9. 如果清理了分片，下次上传同一个文件还能不能做分片级别的秒传

答案

文件上传这类题建议按完整链路回答：

  1. 前端先按大小阈值切片，通常 2MB 到 10MB 比较常见。
  2. 上传前计算文件 hash，服务端据此判断是否已存在完整文件或部分分片。
  3. 断点续传时，前端先查询已上传分片列表，只补传缺失分片。
  4. 全部分片上传完成后，通知服务端按顺序合并。
  5. 秒传一般基于完整文件 hash；分片 hash 更多用于断点续传和重复分片复用。
  6. 分片不是越多越好：分太小请求数会暴涨，分太大失败重传成本高，所以要结合网络、文件大小和后端承载能力权衡。

10. 秒传应该基于完整文件 hash 还是分片 hash

答案

文件上传这类题建议按完整链路回答：

  1. 前端先按大小阈值切片，通常 2MB 到 10MB 比较常见。
  2. 上传前计算文件 hash，服务端据此判断是否已存在完整文件或部分分片。
  3. 断点续传时，前端先查询已上传分片列表，只补传缺失分片。
  4. 全部分片上传完成后，通知服务端按顺序合并。
  5. 秒传一般基于完整文件 hash；分片 hash 更多用于断点续传和重复分片复用。
  6. 分片不是越多越好：分太小请求数会暴涨，分太大失败重传成本高，所以要结合网络、文件大小和后端承载能力权衡。

11. 服务端怎么设计分片管理，才能避免既存完整文件又存所有分片造成空间浪费

答案

服务端通常要区分“临时分片存储”和“最终文件存储”。

  1. 分片只是上传过程中的中间态。
  2. 一旦合并成功且校验通过，就应该删除临时分片。
  3. 如果要复用分片，可以做内容寻址和引用计数，而不是无脑永久保留所有碎片。

12. 如果两个文件部分分片相同、整体文件不同，怎么判断和复用分片

答案

如果要做分片复用，关键是给每个分片做内容级 hash。

  1. 相同 hash 的分片说明内容一致，可以复用。
  2. 但完整文件是否相同，仍然要靠完整文件 hash 判断。
  3. 这种设计本质上接近去重存储。

13. 歌曲列表页点击歌曲后，如何打开一个独立播放页

答案

最直接的方式是列表页点击后打开新窗口或新标签页，并把歌曲标识传过去。

  1. 可以通过 URL 参数、查询串或共享存储传 songId。
  2. 播放页根据 songId 拉取详情并开始播放。

14. 如果播放页已经存在，列表页怎么通知已有播放页切换歌曲

答案

如果播放页已经存在，关键是做跨页面通信。

  1. 可以用 postMessage、BroadcastChannel、storage 事件等方式通知。
  2. 通知内容通常只传歌曲 ID 或播放指令。
  3. 播放页收到后更新当前播放状态。

15. 怎么判断播放页是否已经存在或是否被关闭

答案

如果是通过 window.open 打开的窗口，可以保留窗口引用。

  1. 有引用时可判断 windowRef.closed。
  2. 如果没有直接引用，也可以通过心跳或跨页面通信确认播放页是否还在线。

16. 如何用 LocalStorage 实现跨页面通信

答案

AI 相关题最好回答成“工具边界 + 落地方式”。

  1. AI 适合做样板代码、重构建议、测试用例、文档整理和方案对比。
  2. 真正落地时要给它足够上下文，比如代码规范、目录结构、接口文档、历史实现和约束规则。
  3. Skills / MCP / Agent 可以理解为不同层级的能力扩展：Skills 偏可复用能力包，MCP 偏工具和上下文接入协议，Agent 偏任务编排和执行过程。
  4. AI 不能代替工程判断，核心链路仍然要靠人 review 和兜底。

17. 如何用 LocalStorage 实现页面间心跳检测

答案

AI 相关题最好回答成“工具边界 + 落地方式”。

  1. AI 适合做样板代码、重构建议、测试用例、文档整理和方案对比。
  2. 真正落地时要给它足够上下文，比如代码规范、目录结构、接口文档、历史实现和约束规则。
  3. Skills / MCP / Agent 可以理解为不同层级的能力扩展：Skills 偏可复用能力包，MCP 偏工具和上下文接入协议，Agent 偏任务编排和执行过程。
  4. AI 不能代替工程判断，核心链路仍然要靠人 review 和兜底。

18. LocalStorage 轮询方案有什么性能问题

答案

AI 相关题最好回答成“工具边界 + 落地方式”。

  1. AI 适合做样板代码、重构建议、测试用例、文档整理和方案对比。
  2. 真正落地时要给它足够上下文，比如代码规范、目录结构、接口文档、历史实现和约束规则。
  3. Skills / MCP / Agent 可以理解为不同层级的能力扩展：Skills 偏可复用能力包，MCP 偏工具和上下文接入协议，Agent 偏任务编排和执行过程。
  4. AI 不能代替工程判断，核心链路仍然要靠人 review 和兜底。

19. 除了 LocalStorage，跨页面通信还有哪些更好的方案

答案

AI 相关题最好回答成“工具边界 + 落地方式”。

  1. AI 适合做样板代码、重构建议、测试用例、文档整理和方案对比。
  2. 真正落地时要给它足够上下文，比如代码规范、目录结构、接口文档、历史实现和约束规则。
  3. Skills / MCP / Agent 可以理解为不同层级的能力扩展：Skills 偏可复用能力包，MCP 偏工具和上下文接入协议，Agent 偏任务编排和执行过程。
  4. AI 不能代替工程判断，核心链路仍然要靠人 review 和兜底。

20. postMessage 和 Service Worker 怎么用于跨页面通信

答案

postMessage 适合窗口、iframe、worker 之间显式发消息。

  1. 页面之间如果有直接窗口关系，用 postMessage 很方便。
  2. Service Worker 更像一个中间层，适合做多个页面共享消息和离线能力。
  3. 但轻量通信优先级通常还是 BroadcastChannel 或 postMessage 更直接。

21. 歌曲列表中大量图片加载时，如何先展示占位图

答案

常见做法是先渲染占位图或骨架屏，等真实图片加载完成后再切换。

  1. 初始阶段展示统一占位图。
  2. 图片加载成功后替换成真实图。
  3. 失败时再兜底成错误图。

22. 图片加载成功后怎么切换为真实图片

答案

可以监听图片的 load 事件。

  1. 先让占位图展示。
  2. 图片真正加载完成后，把显示源切换成真实图片。
  3. 过渡时可以加淡入效果，避免闪烁。

23. 图片加载失败后怎么展示失败图

答案

图片失败兜底一般监听 error 事件。

  1. 一旦触发错误，就把图片地址切换到默认错误图。
  2. 同时可以记录错误日志或埋点，方便排查资源问题。

24. 如何通过图片的 load 和 error 事件判断加载状态

答案

图片加载状态最常见就是监听两个事件。

  1. load 表示资源成功加载完成。
  2. error 表示加载失败。
  3. 结合本地状态，就能切换占位、真实图和失败图。

25. 你接触过 React Native 或 Flutter 这类跨端技术吗

答案

如果接触过，就说实际使用场景；如果没深入用过，也可以从理解层面回答。

  1. React Native 和 Flutter 都是跨端方案，目标是复用业务逻辑和 UI 能力。
  2. React Native 更贴近前端生态；Flutter 有自己完整的渲染体系。
  3. 回答时不要硬装做过，诚实说明接触深度更稳。

26. Vite 相比 Webpack，为什么开发阶段启动更快

答案

如果项目里既提过 Webpack 又提过 Vite，建议先说明主用哪一个，再对比原因。

  1. Webpack 生态更老更全，适合历史项目和高度定制场景。
  2. Vite 开发态基于原生 ESM，冷启动和热更新通常更快，适合现代前端项目。
  3. 如果面试官追问，一定补上：开发态和生产构建的策略不一样，不能只说“Vite 更快”。

27. Webpack 能不能也配置成使用 ES Module

答案

可以，Webpack 本身就支持 ESM。

  1. 入口和源码层可以直接用 import/export。
  2. 它也支持输出成某些 ESM 格式。
  3. 但“支持 ESM”不代表开发态就和 Vite 一样按原生 ESM 直接跑。

28. Vite 的热更新 HMR 是怎么实现的

答案

Vite 的 HMR 核心是“原生 ESM + WebSocket 通知 + 精准模块失效”。

  1. 浏览器按 ESM 方式加载模块。
  2. 文件变化后，Vite 通过 WebSocket 通知客户端哪些模块失效。
  3. 客户端只重新请求受影响模块，而不是整页刷新。

29. WebSocket 和 SSE 有什么区别

答案

SSE 和 WebSocket 的核心区别是通信方向和适用场景。

  1. SSE 是服务端单向推送，基于 HTTP，天然适合大模型文本流、通知流、日志流。
  2. WebSocket 是全双工通信，更适合聊天、协同编辑、实时互动。
  3. AI 对话里如果主要是服务端不断吐内容，SSE 往往更简单、更稳定，也更容易复用现有 HTTP 鉴权和网关体系。
  4. 如果需要客户端高频主动发消息、双向实时同步，WebSocket 更合适。