钉子的生活日记
文章目录

快手商业化前端日常一面整理笔记（三）

1. 讲一下浅拷贝和深拷贝的区别

答案

浅拷贝只复制第一层属性，遇到引用类型时仍然共享同一块内存；深拷贝会递归复制每一层，拷贝后的对象和原对象互不影响。

  1. 浅拷贝常见写法有 Object.assign、展开运算符、数组 slice。
  2. 深拷贝常见做法有 structuredClone、递归拷贝、lodash.cloneDeep。
  3. JSON 序列化不是完整深拷贝，会丢失函数、undefined、循环引用等信息。

2. Vue3 相比 Vue2 有哪些优点和升级

答案

Vue3 相比 Vue2 的核心升级有四点：

  1. 响应式从 defineProperty 升级到 Proxy，对新增属性、删除属性、数组索引等场景支持更自然。
  2. 提供 Composition API，逻辑复用和复杂组件组织能力更强。
  3. TypeScript 支持更好，源码本身也更偏 TS 设计。
  4. 编译优化和运行时性能更好，比如静态提升、Patch Flag、Tree Shaking 更完善。

一句话：Vue2 更偏 Options API，Vue3 在响应式、逻辑组织、性能和工程化上都更现代。

3. 你怎么理解 Vue3 里的 Hooks / 组合式逻辑

答案

如果这里指 Vue3 的组合式逻辑，本质是把“状态、计算属性、副作用、复用逻辑”从 Options API 的配置项里拆出来，用函数组织。

  1. 好处是相关逻辑可以按业务能力聚合，而不是被 data/computed/methods/watch 分散。
  2. 适合复杂组件、跨页面复用、抽离表单逻辑、请求逻辑、滚动监听、权限判断等。
  3. 自定义 hooks / composables 适合复用“带状态和生命周期”的逻辑；纯计算逻辑则更适合普通工具函数。

4. 有没有自己封装过 hooks，适合在什么场景下封装

答案

如果这里指 Vue3 的组合式逻辑，本质是把“状态、计算属性、副作用、复用逻辑”从 Options API 的配置项里拆出来，用函数组织。

  1. 好处是相关逻辑可以按业务能力聚合，而不是被 data/computed/methods/watch 分散。
  2. 适合复杂组件、跨页面复用、抽离表单逻辑、请求逻辑、滚动监听、权限判断等。
  3. 自定义 hooks / composables 适合复用“带状态和生命周期”的逻辑；纯计算逻辑则更适合普通工具函数。

5. 讲一下 Vue 里的虚拟 DOM，它主要解决什么问题

答案

虚拟 DOM 本质是用 JavaScript 对真实 DOM 做一层抽象，更新时先比较新旧虚拟节点，再把最少的变更同步到真实 DOM。

  1. 它解决的不是“完全不操作 DOM”，而是降低手写 DOM 更新的复杂度。
  2. 重点价值是跨平台抽象、声明式开发体验，以及用 Diff 策略减少不必要更新。
  3. 真正性能好不好，不只看虚拟 DOM，还和组件拆分、key 使用、渲染粒度有关。

6. 从输入 URL 到页面最终渲染出来，中间发生了什么

答案

从输入 URL 到页面展示，主线一般是：

  1. URL 解析，判断协议和资源地址。
  2. DNS 解析拿到 IP。
  3. 建立 TCP 连接；如果是 HTTPS，还会进行 TLS 握手。
  4. 浏览器发起 HTTP 请求，服务端返回 HTML。
  5. 浏览器解析 HTML 构建 DOM，解析 CSS 构建 CSSOM。
  6. 如果遇到同步脚本，可能会阻塞解析并执行 JS。
  7. DOM 和 CSSOM 合成渲染树，随后做布局、绘制、合成显示。
  8. 页面加载后，还可能继续执行异步请求、图片加载和事件绑定。

7. 多人协作开发时，Git 分支一般怎么管理

答案

多人协作里常见做法是：

  1. main/master 保持稳定，只放可发布代码。
  2. 日常开发从主干切功能分支，需求完成后通过 PR / MR 合并。
  3. 发布前可以有 release 分支，紧急修复用 hotfix 分支。
  4. 团队里最好配套代码评审、CI 校验和分支保护，避免直接往主分支提交。

8. 如果往公共分支提交了一段有 bug 的代码，怎么安全撤回

答案

公共分支代码有 bug，最安全的撤回方式一般是 git revert，而不是强推覆盖历史。

  1. revert 会生成一个反向提交，保留历史，团队协作更安全。
  2. 如果只是本地还没推送，可以用 reset 或 rebase -i 调整历史。
  3. 线上已经被别人拉取过的公共提交，不建议直接 push --force。

9. 你有了解或使用过 React 吗

答案

可以直接从三个层次回答：

  1. 我了解 React 的组件化、单向数据流、Hooks、虚拟 DOM 等核心概念。
  2. 如果做过项目，可以补充自己用过 useState/useEffect/useMemo、路由、状态管理等场景。
  3. 如果主要技术栈是 Vue，也可以说自己理解 React 的基本思想，并说明两者在状态管理和逻辑复用上的差异。

10. AI 对话平台项目的项目规模、页面结构和负责部分

答案

项目题建议按“背景、目标、职责、难点、结果”来回答。

  1. 先说项目是做什么的，面向谁，解决什么问题。
  2. 再说页面结构和核心模块，比如会话区、输入区、历史记录、设置区、文件区等。
  3. 说明自己负责的部分，不要泛泛说“都做了”。
  4. 最后讲 1 到 2 个真正的难点，比如流式渲染、状态管理、性能优化、上传链路、权限模型，并补充最终效果。

11. SSE 里混合文本、图片、视频怎么处理

答案

多模态流式内容一般不能只当纯字符串处理，推荐把服务端返回统一抽象成消息片段流。

  1. 每个片段带上 type，例如 text、image、pdf、markdown、component。
  2. 前端先按协议解析，再分发给不同渲染器组件。
  3. 文本流可以增量更新；图片、文件类内容更适合先展示占位状态，拿到完整地址后再渲染。
  4. 多轮图片编辑相比纯文字对话，额外要管理素材引用、版本关系、操作指令和结果回显。

12. 本地持久化机制怎么做，为什么用 Pinia 和 LocalStorage

答案

本地持久化常见做法是“内存状态 + 本地存储”配合。

  1. Pinia 负责运行时状态管理，适合页面之间共享会话、用户信息、设置项。
  2. LocalStorage 负责持久化一些轻量数据，比如最近会话、主题、用户偏好。
  3. 初始化时从本地恢复，运行时通过订阅或插件同步写入。
  4. 不建议把大体积聊天记录、图片 base64、长文本全文都放进 LocalStorage。

13. 如果会话数据不断增长，LocalStorage 超出容量上限了怎么办

答案

LocalStorage 容量有限，通常只有几 MB，所以不能无限塞会话内容。

  1. 只持久化必要字段，比如会话摘要、最近消息、配置项。
  2. 历史长消息可以只保留最近 N 条，其余走服务端存储或 IndexedDB。
  3. 图片、文件、长文本正文不要存 LocalStorage。
  4. 写入前可以做大小监控和淘汰策略，避免一次写爆导致异常。

14. 如果把 SSE 改成 WebSocket，能力上能不能完全对齐

答案

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

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

15. 后台管理系统项目的难点是什么

答案

项目题建议按“背景、目标、职责、难点、结果”来回答。

  1. 先说项目是做什么的，面向谁，解决什么问题。
  2. 再说页面结构和核心模块，比如会话区、输入区、历史记录、设置区、文件区等。
  3. 说明自己负责的部分，不要泛泛说“都做了”。
  4. 最后讲 1 到 2 个真正的难点，比如流式渲染、状态管理、性能优化、上传链路、权限模型，并补充最终效果。

16. 上传的文件一般是什么类型

答案

回答这题重点不是枚举所有文件后缀，而是说明业务为什么要按类型区分处理。

  1. 常见有图片、PDF、文档、压缩包、音视频等。
  2. 不同类型在预览、校验、分片策略、大小限制、转码处理上都不同。
  3. 实战里一般会先做 MIME 类型和后缀白名单校验，再根据类型走不同上传或预览链路。

17. 分片上传的分片策略是怎么设计的，为什么用这个阈值

答案

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

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

18. 分片是越多越好还是越少越好，怎么权衡

答案

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

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

19. 讲一下断点续传的完整实现流程

答案

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

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

20. 秒传是怎么做的，核心判断依据是什么

答案

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

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

21. 性能优化有没有量化效果，怎么测出来的

答案

性能优化题一定要讲“指标、手段、结果”。

  1. 先说明你关注的是 FCP、LCP、首屏时间、交互耗时还是滚动帧率。
  2. 再说做了什么，比如拆包、懒加载、虚拟列表、分帧渲染、缓存、减少主线程长任务。
  3. 最后说如何验证：Lighthouse、Performance 面板、埋点平台、真实用户监控。
  4. 如果问“怎么保证不卡”，关键是把长任务拆小，必要时放到 Worker，并减少一次性大量 DOM 更新。

22. 平时学习前端主要通过哪些渠道

答案

我一般会按“官方文档 -> 最小 demo -> 项目实践 -> 复盘沉淀”的顺序学习。

  1. 先看官方文档和权威资料，建立正确认知。
  2. 再做一个最小可运行 demo，确认自己真会用。
  3. 再放进真实项目，看它在工程里有没有边界问题。
  4. 最后把结论沉淀成笔记或模板，方便后续复用。

23. 最近有了解哪些前端相关的 AI 工具

答案

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

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

24. 你怎么理解 Skills

答案

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

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

25. LC20 有效的括号

答案

这题标准解法是栈。

  1. 遍历字符串，左括号入栈。
  2. 遇到右括号时，检查栈顶是否是对应的左括号。
  3. 不匹配就直接返回 false；最后栈为空才说明完全匹配。