二面

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮共 13 道题。答案默认折叠，便于先自行作答。 1. 讲一下你的低代码平台架构设计 题目要点 分层架构、组件引擎、JSON Schema、热更新机制 参考答案 低代码平台采用分层架构设计：底层是组件引擎，负责组件的注册、渲染和生命周期管理；中间层是可视化编辑器，提供拖拽、属性配置和预览功能；上层是业务逻辑层，处理数据绑定、事件处理和页面路由。技术栈选择 Vue 3 + TypeScript，通过 JSON Schema 描述组件结构，使用虚拟 DOM 进行高效渲染。同时建立了组件市场和模板库，支持组件的版本管理和热更新机制。 2. 动态加载第三方组件时，如何解决样式冲突与DOM管理问题？ 题目要点 样式隔离、容器化渲染、事件总线、冲突检测 参考答案 样式隔离通过 CSS Modules 或 Shadow DOM 实现，为每个组件创建独立的样式作用域。建立样式优先级管理机制，通过 CSS 变量和主题系统统一管理全局样式。DOM管理采用容器化策略，每个第三方组件在独立的容器中渲染，通过事件总线进行通信。同时实现样式冲突检测工具，在组件加载时自动检测并解决潜在冲突。 3. 当业务需求超出平台预设组件能力时，你们是怎么扩展的 题目要点 插槽扩展、开发工具链、能力评估、贡献机制 参考答案 建立组件扩展机制，支持通过插槽（slot）和高阶组件进行功能扩展。提供自定义组件开发工具链，包括脚手架、调试工具和发布流程。实现组件能力评估系统，当检测到需求超出现有能力时，自动推荐相似组件或提供扩展建议。同时建立组件贡献机制，允许开发者提交自定义组件到组件库，经过审核后供全平台使用。 4. 组件的热更新策略是怎么处理的，在不影响用户的使用情况下 题目要点 渐进式更新、状态保持、回滚机制、用户确认 参考答案 采用渐进式热更新策略，通过版本控制和灰度发布确保更新的安全性。实现组件状态保持机制，在更新过程中保存组件的当前状态，更新完成后恢复状态。建立回滚机制，当检测到更新异常时自动回滚到稳定版本。同时提供更新通知和用户确认机制，让用户选择合适的时机进行更新，避免在关键操作时中断用户体验。 5. 组件通信机制如何设计 题目要点 多层次通信、消息路由、协议标准化、调试工具 参考答案 设计多层次的通信机制：父子组件通过 props 和 events 通信，兄弟组件通过事件总线或状态管理，跨层级组件使用 provide/inject 或全局状态。建立消息路由系统，支持组件间的异步通信和消息队列。实现通信协议标准化，定义统一的消息格式和处理流程。同时提供通信调试工具，帮助开发者追踪消息流向和排查通信问题。 6. 移动端适配是什么做的 题目要点 响应式设计、弹性布局、手势支持、性能优化 参考答案 采用响应式设计和移动优先策略，使用 rem/vw 单位实现弹性布局。建立设备适配规则库，根据屏幕尺寸和设备类型自动调整组件样式。实现触摸手势支持，优化移动端的交互体验。同时建立性能优化机制，针对移动设备的性能特点进行资源加载和渲染优化，确保在低性能设备上也能流畅运行。 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮共 9 道题。答案默认折叠，便于先自行作答。 1. 讲一下你觉得比较有亮点的项目 题目要点 技术选型合理性、渐进式迁移策略、自动化工具、性能保障 参考答案 在负责的一个大型电商平台重构项目中，面临着从传统 jQuery 架构向现代化 Vue 3 + TypeScript 架构迁移的挑战。项目的亮点在于采用了渐进式迁移策略，通过微前端架构实现新老系统的平滑过渡。设计了一套自动化的代码转换工具，将重复性的迁移工作自动化，提升了整体迁移效率 60%。同时建立了完善的性能监控体系，确保迁移过程中用户体验不受影响。 2. 项目的难点，你是怎么推动的 题目要点 风险控制、分阶段实施、灰度发布、跨团队协作 参考答案 最大的难点是在不影响线上业务的前提下完成大规模重构。通过制定详细的迁移计划，将整个项目拆分为多个独立的里程碑，每个阶段都有明确的交付物和验收标准。建立了灰度发布机制，新功能先在小范围用户中验证，逐步扩大覆盖范围。同时与产品、测试、运维团队建立了紧密的协作机制，确保各个环节的顺畅衔接。 3. 页面性能优化你做了哪些工作 题目要点 多维度优化、量化效果、监控体系、持续改进 参考答案 从多个维度进行了系统性优化：资源层面实施了代码分割和懒加载，将首屏加载时间减少 40%；网络层面启用了 HTTP/2 和资源预加载，优化了关键渲染路径；渲染层面使用了虚拟滚动和组件缓存，提升了长列表的交互性能；同时建立了性能监控体系，通过 Performance API 和用户行为分析持续跟踪优化效果。 4. 相关的指标有哪些，怎么去衡量的，标准是什么 题目要点 Core Web Vitals、RUM监控、分类基准、持续监测 参考答案 建立了完整的性能指标体系：Core Web Vitals 作为核心指标，包括 LCP（2.5s 以内）、FID（100ms 以内）、CLS（0.1 以内）；业务指标包括首屏加载时间、页面完全加载时间、接口响应时间等。通过 RUM（真实用户监控）收集线上数据，结合 Lighthouse 进行定期检测。制定了不同页面类型的性能基准，如首页 LCP 控制在 2s 内，列表页控制在 2.5s 内。 5. WebSocket 协议原理 题库原题：说下 websocket 的连接原理 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮共 10 道题。答案默认折叠，便于先自行作答。 1. 讲一下你的第一个项目 题目要点 突出难点与解决方案，亮点强调可扩展性与价值。 参考答案 第一个项目是一个内部管理系统，主要功能是数据可视化和表单管理。难点在于表单项类型复杂、交互逻辑多。解决方案是抽象出一套动态表单引擎，通过 JSON 配置生成组件，既降低了开发成本，也提升了可扩展性。项目的亮点在于统一了交互和样式规范，同时通过可配置化提高了可维护性。 2. 为什么选择 Vue3 + Vite 而非 React/Webpack 题目要点 Vue3 → 响应式系统和语法优势；Vite → 构建性能显著提升。 参考答案 Vue3 在响应式系统上引入了 Proxy，更适合处理复杂响应式数据，语法上对团队更友好。Vite 基于 ESBuild 和原生 ESM，构建速度远快于 Webpack，特别是在开发阶段的冷启动和热更新体验明显更优。而 Webpack 尽管生态成熟，但在开发构建效率上落后。 3. Vite 的构建速度比 Webpack 快多少 题目要点 冷启动快一个数量级，HMR 延迟极低，原因是按需编译 vs 整包构建。 参考答案 在实际项目中，冷启动通常能快 10 倍以上。例如一个中大型项目，Webpack 启动需要 20-30 秒，Vite 一般在 1-3 秒即可完成；热更新延迟也从秒级缩短到 100ms 以内。这是因为 Vite 基于原生 ESM 做按需编译，而 Webpack 是整包构建。 4. FCP 从 3.2s 降到 1.1s，具体做了哪些优化？ 题目要点 构建优化 + 资源优化 + 网络优化 + SSR 骨架屏。 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 面试时间： 60分钟 本轮共 21 道题。答案默认折叠，便于先自行作答。 1. 讲一下你在官网开发中的主要职责，开发的模块以及你觉的比较亮点的地方 题目要点 如果是面试官问到“官网开发中的主要职责、开发的模块以及比较亮点的地方”，一般可以从以下几个角度来回答，既展示你的全局把控能力，又体现你在某些点上有深度。 参考答案 如果是面试官问到“官网开发中的主要职责、开发的模块以及比较亮点的地方”，一般可以从以下几个角度来回答，既展示你的全局把控能力，又体现你在某些点上有深度。 下面是一个参考思路： 1. 主要职责 官网整体架构搭建：根据业务和设计稿，使用 React/Vue + Vite/Next.js/Nuxt.js 等技术栈完成整体框架搭建，包括路由、状态管理、多语言支持等。 公共模块封装：抽象公共组件（如导航栏、页脚、轮播、富文本渲染、内容卡片等），提高复用率，减少重复开发。 性能优化：处理首屏加载速度、资源拆分、图片懒加载、SSR/SSG、SEO 优化。 协作沟通：与产品、UI、后端保持沟通，保证页面上线节奏和质量。 2. 负责的模块（可根据实际情况举例） 首页：承担品牌形象展示，涉及 banner 动效、动态数据展示、视频播放等。 产品/解决方案页：结合后端接口，展示不同产品模块，支持筛选、搜索、动态路由。 活动/新闻动态页：接入 CMS（如 Strapi、Sanity、WordPress 等），支持运营人员通过后台直接发布。 多语言切换模块：基于 i18n 实现官网多语言，支持自动识别浏览器语言，静态资源跟随切换。 SEO 优化模块：处理 meta 信息、OG 标签、站点地图、robots.txt，提升搜索引擎收录效果。 3. 亮点/难点突破 性能优化亮点 利用 SSR/SSG（Next.js/Nuxt.js）提升首屏渲染速度，Lighthouse 分数提升到 90+。 使用图片 CDN + WebP 格式，首页加载时间缩短 30%。 按需加载组件、拆分 bundle，减少首次请求体积。 可配置化思路 引入 CMS 系统，实现官网内容可配置，避免频繁改代码上线，运营可直接维护。 封装通用“模块化组件”，如 Banner、富文本、图文组合，做到拖拽/配置式渲染。 前端体验优化 首页/产品页引入 动效（基于 Lottie 或 GSAP），提升视觉冲击力。 交互细节（滚动吸附、视差动画、过渡效果）增强用户沉浸感。 工程化实践 ...

← 第 1 轮 · 返回本次面经 · 第 1 轮 → 本轮要点： 浏览器的缓存机制、react hooks 本轮共 11 道题。答案默认折叠，便于先自行作答。 1. 魔方组件的整体架构设计，包括其模块划分和核心功能 题目要点 略 参考答案 略 2. 你们是如何选择技术栈的？有哪些关键因素影响了决策 题目要点 略 参考答案 略 3. 魔方组件如何实现动态加载，以提升初始加载性能 题目要点 略 参考答案 略 4. 魔方组件如何管理组件的配置信息？组件之间的通信是如何处理的 题目要点 略 参考答案 略 5. 三维模型的加载性能，将加载时间从10秒缩短至3秒都做了哪些操作 题目要点 略 参考答案 略 6. 这个项目中在移动端，你们是如何处理不同设备的适配问题的 题目要点 略 参考答案 略 7. 有没有用服务端渲染（SSR）？如果有，你们是如何实现的 题目要点 SSR 是服务器预先渲染页面，提高首屏性能和 SEO 常用框架有 Next.js、Nuxt.js，也可自研实现 实现时结合服务器渲染和客户端 Hydration 完成完整页面交互 需处理代码共享、数据预取、样式加载及性能优化 了解 SSR 的局限性和优化难点，合理权衡使用场景 参考答案 一、考察点 理解 SSR 的基本概念和优势 掌握常见 SSR 实现方案及其原理 理解 SSR 与客户端渲染（CSR）的区别和协同方式 了解 SSR 在项目中的具体落地方法和技术选型 二、参考答案 2.1 SSR 的基本概念 SSR（Server-Side Rendering）是指在服务器端完成页面的 HTML 渲染，再将完整的 HTML 返回给客户端 相比纯客户端渲染，SSR 提升了首屏渲染速度和 SEO 友好性 用户拿到的是已渲染好的页面，浏览器可以更快显示内容 2.2 SSR 的优势和适用场景 首屏速度快：浏览器无需等待大量 JS 执行即可显示页面 SEO 优化：搜索引擎能抓取到完整的内容，提升排名 社交分享友好：分享链接时可显示完整预览 适合内容型或公共站点，电商、新闻、博客等场景 2.3 常见 SSR 实现方案 Next.js（React）：提供开箱即用的 SSR 支持和静态生成 Nuxt.js（Vue）：Vue 生态的 SSR 框架，支持服务端渲染和静态导出 自研 SSR：使用 Node.js 搭配 ReactDOMServer 或 Vue SSR API 手动实现 传统模板引擎：如 EJS、Handlebars 等，服务器渲染 HTML 2.4 我们项目中 SSR 的实现方式 使用了 [Next.js / Nuxt.js / 自研 SSR] 作为 SSR 框架 服务器通过 Node.js 环境调用 ReactDOMServer.renderToString 或 Vue SSR 的 renderToString，生成完整 HTML 结合路由系统，实现根据请求 URL 渲染对应页面 页面返回时携带初始数据（通过服务端数据预取），客户端接管 Hydration，实现页面交互 结合缓存策略，优化性能和响应速度 配合 Webpack 和 Babel，保证服务端代码和客户端代码一致性 2.5 实现过程中需注意的问题 服务端和客户端代码共享及差异处理（避免浏览器 API 直接调用） 初始数据的获取与注入，保证页面完整性和交互 处理样式加载，避免闪烁（FOUC） 性能优化，如页面缓存、资源压缩和异步加载 服务器负载和扩展性考虑 三、常见误区或面试陷阱 ❌ 认为 SSR 只是在服务器渲染静态 HTML，忽略客户端 Hydration ❌ 忽视服务端渲染的性能开销和状态同步难题 ❌ 直接复用客户端代码，未处理服务端无 DOM 的环境差异 ❌ 忽略 SEO 以外的性能和用户体验提升点 8. 项目中使用了哪些状态管理工具？为什么选择这些工具 题目要点 状态管理工具选择基于项目规模、团队经验和性能需求 Redux 适合大型复杂应用，MobX 适合响应式需求 Context 适合轻量局部状态管理 结合工具生态和中间件支持，提升开发效率和维护性 合理划分全局与局部状态，避免状态管理复杂化 参考答案 一、考察点 理解不同状态管理工具的特点及适用场景 掌握项目中选择状态管理工具的决策逻辑 能清晰阐述所选工具带来的优势和解决的问题 了解状态管理的基本概念和复杂度控制方法 二、参考答案 2.1 项目中使用的状态管理工具 Redux 适用于大型复杂应用，状态集中管理 具备时间旅行调试、可预测状态变更、丰富中间件生态 MobX 响应式状态管理，自动追踪依赖，适合数据驱动视图更新 代码简洁，学习曲线较低 React Context + useReducer/useState 轻量级状态共享方案，适合中小型或局部状态管理 Recoil / Zustand / Valtio 等轻量方案 现代灵活的状态管理，适合部分场景需求 Vuex（Vue 项目） Vue 官方状态管理库，集中管理全局状态，支持插件扩展 2.2 选择这些工具的理由 项目规模与复杂度 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮要点： react hooks、高阶组件、列表和key、react 渲染机制、react 组件设计模式、前端模块化、Webpack与Vite 本轮共 12 道题。答案默认折叠，便于先自行作答。 1. 讲一下你对Hooks 了解 题目要点 Hooks 是函数组件状态和副作用管理的新方案 常用 Hooks 有 useState、useEffect、useMemo、useCallback 等 Hook 调用必须遵循规则，保证顺序稳定 自定义 Hooks 用于逻辑复用，提高代码可维护性 理解 Hook 设计原理，有助于写出高质量 React 代码 参考答案 一、考察点 理解 React Hooks 的设计初衷与核心概念 掌握常用 Hooks（如 useState、useEffect、useMemo、useCallback 等）的作用与使用场景 理解 Hooks 规则及其背后的原理机制 认识 Hooks 对函数组件状态管理和生命周期的改进 了解自定义 Hooks 的设计思路及复用价值 二、参考答案 2.1 Hooks 的定义与设计初衷 定义：Hooks 是 React 16.8 引入的函数组件状态和副作用管理的特性 设计目标： 解决类组件中状态逻辑难以复用和组件嵌套过深的问题 让函数组件拥有类似类组件的状态和生命周期能力 简化组件逻辑，提升代码可读性和复用性 2.2 常用 Hooks 及其作用 Hooks 功能描述 典型使用场景 useState 在函数组件中声明状态变量 组件内部状态管理 useEffect 处理副作用（订阅、异步请求、DOM操作等） 替代类组件的生命周期钩子 useContext 订阅 React Context，实现跨组件数据传递 共享全局状态、主题、语言等 useMemo 记忆计算结果，避免不必要的重复计算 性能优化，避免昂贵计算重复执行 useCallback 记忆函数实例，避免子组件重复渲染 优化子组件性能，防止无意义的 props 变化 useRef 保存可变值，不触发组件重新渲染 访问 DOM 节点或保存不变引用 2.3 Hooks 的规则与原理 规则： 只能在函数组件或自定义 Hooks 中调用 只能顶层调用，不能在循环、条件或嵌套函数中调用，保证 Hook 调用顺序稳定 原理：React 通过维护一个 Hook 链表和调用顺序，关联 Hook 状态与对应组件实例，实现状态的持久化和更新 2.4 自定义 Hooks 将组件中可复用的状态逻辑抽象成函数 函数内部调用其他 Hooks，实现逻辑复用与拆分 提高代码复用性和可维护性 三、常见误区或面试陷阱 误用 Hook 规则，导致调用顺序不稳定 过度使用 useEffect，产生复杂副作用链和性能问题 误解 useMemo 和 useCallback 的使用时机和作用 忽略依赖项数组，导致副作用不正确执行 不了解自定义 Hooks 是普通函数，不能在其中调用 Hook 规则外的逻辑 2. 对比 Class 组件的 Mixin 模式，Hooks 如何解决逻辑复用问题？Mixin 的主要缺陷是什么 题目要点 Mixin 依赖多继承，存在命名冲突、状态污染、难维护等问题 Hooks 通过函数组合和自定义 Hook 实现逻辑复用，避免冲突和复杂继承 Hooks 提升代码可读性、维护性、测试性和类型支持 React 官方推荐使用 Hooks 替代 Mixin 模式 参考答案 一、考察点 理解 Class 组件中 Mixin 的工作方式及缺陷 掌握 Hooks 解决组件逻辑复用的机制和优势 比较两种方案在代码组织、维护性和复用性上的差异 理解现代 React 设计理念和组件开发最佳实践 二、参考答案 2.1 Mixin 模式及其缺陷 Mixin 定义：通过多个类混入（mixin）共享方法和状态，Class 组件通过继承或组合多个 mixin 实现代码复用 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮要点： call、apply和bind、性能优化、浏览器渲染过程、浏览器的缓存机制 本轮共 10 道题。答案默认折叠，便于先自行作答。 1. 假设现在有一个老项目需从React 17升级至React 18，你会怎么做 题目要点 先升级 react/react-dom 版本，再更改根渲染方式为 createRoot 理解 React 18 并发特性，调整相关组件代码 确认并升级第三方依赖，保证兼容性 充分测试，监控性能，平滑迁移 参考答案 一、考察点 理解 React 18 的新特性及其对应用的影响 掌握 React 18 升级步骤及兼容性处理 了解新版本的渲染机制变化（如并发特性） 熟悉常见问题排查与升级风险规避 二、参考答案 2.1 升级前准备 阅读官方升级指南（React 官方文档提供详尽升级说明） 检查项目依赖版本，确保 React 相关依赖（如 ReactDOM、react-scripts 等）兼容 React 18 备份代码及建立测试环境，保证升级过程可回滚 2.2 主要升级步骤 1）升级 React 和 ReactDOM 版本 npm install react@18 react-dom@18 或 yarn add react@18 react-dom@18 2）更新根节点渲染方式 React 18 引入了新的根 API：createRoot，替代 React 17 的 ReactDOM.render。 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮要点： react hooks、性能优化 本轮共 10 道题。答案默认折叠，便于先自行作答。 1. 你们项目为什么选Redux而非MobX 题目要点 Redux 强调可预测性、单向数据流、纯函数 reducer，适合复杂项目 丰富的调试工具和社区中间件支持开发效率和可维护性 MobX 响应式自动追踪，适合快速开发，但隐式依赖增加调试难度 团队规模和项目复杂度是选择状态管理方案的关键因素 现代 Redux 已大幅简化，代码冗余感降低 参考答案 一、考察点 是否理解 Redux 和 MobX 两种状态管理库的设计理念与差异 是否能结合项目实际需求，论述选择某一方案的合理性 是否掌握 Redux 在复杂状态管理中的优势与局限 是否能表达对团队协作、维护性和性能的综合考虑 二、参考答案 1.1 原理说明 Redux 基于 Flux 架构思想，使用单一全局状态树（Store） 状态只读，通过派发（dispatch）纯函数（Reducer）更新状态 强调不可变数据和纯函数，方便调试和时间旅行（time-travel debugging） 侧重于可预测性和可维护性 MobX 采用响应式编程思想，通过可观察（observable）数据和自动追踪依赖实现状态同步 支持隐式状态更新，使用更接近传统面向对象编程 适合快速开发，较少样板代码 1.2 选择 Redux 的主要理由 1）明确的状态流向和可预测性 Redux 的单向数据流和纯函数 reducer 让状态变化过程清晰、易追踪 在多人协作中，可以方便定位状态更新的具体原因，减少调试成本 2）强大的开发者工具支持 Redux DevTools 提供时间旅行、快照对比、action 日志等，极大提升调试体验 有丰富的中间件生态（如 redux-thunk、redux-saga），便于处理复杂异步逻辑 3）适合大型复杂项目 状态结构复杂时，Redux 更便于组织和维护，模块化拆分 reducer 明确职责 明确的规范和社区共识，团队成员易于理解和统一编码风格 4）可测试性强 Reducer 是纯函数，易于单元测试，保证业务逻辑可靠 1.3 不选 MobX 的考虑 1）隐式依赖难以追踪 MobX 的自动依赖追踪机制带来状态变化的隐式性，可能导致调试困难 团队成员对响应式原理不熟悉时，维护成本升高 2）状态变化不够可预测 MobX 允许任意地方修改状态，可能出现难以预料的副作用 不利于实现严格的状态管理和权限控制 3）社区规范和中大型项目生态 Redux 生态成熟且社区规范丰富 MobX 在某些复杂场景下不够透明，团队风险较大 1.4 常见误区或面试陷阱 ❌ 误区一：认为 MobX 性能一定优于 Redux 实际性能差异因项目而异，合理使用 Redux 也能实现优秀性能 ❌ 误区二：Redux 代码一定繁琐难写 现代 Redux 工具（如 Redux Toolkit）极大简化开发体验，减少样板代码 ❌ 误区三：认为 MobX 是“魔法”，不需要学习状态管理原理 响应式原理本身也需要深入理解，否则容易导致维护难题 2. 项目中提到“首屏加载优化1.5秒”，具体如何实现 题目要点 首屏加载优化核心在于减少首屏资源体积和请求数量 结合 SSR/SSG 预渲染，缩短白屏时间 动态拆分代码，懒加载非关键资源 充分利用浏览器缓存和 CDN 监控指标涵盖 FCP、TTI，持续迭代优化 参考答案 一、考察点 理解首屏加载的定义及关键性能指标（如 FCP、TTI） 掌握多种前端性能优化手段，涵盖资源、网络、渲染等层面 能结合具体技术和业务场景，说明优化实施细节 理解优化过程中的权衡与监控方法 二、参考答案 1.1 首屏加载的概念与性能指标 首屏加载：用户打开页面到看到页面主要内容（首屏内容）完整渲染的时间 ...

← 第 1 轮 · 返回本次面经 · 已是最后一轮 → 本轮共 10 道题。答案默认折叠，便于先自行作答。 1. 介绍一下你觉的最有成就感的项目 题目要点 略 参考答案 略 2. 项目为什么选择Lerna+Yarn Workspaces构建Monorepo 题目要点 Monorepo 实现多包统一管理，提升代码复用和维护效率 Lerna 管理版本发布、变更检测、脚本执行 Yarn Workspaces 优化依赖安装，支持本地包软链接 两者结合，实现高效、便捷的 Monorepo 构建和维护 适合大型复杂项目及多包同步开发场景 参考答案 一、考察点 理解 Monorepo 的概念及优势 多个相关包/模块统一管理、版本控制、发布流程等 掌握 Lerna 与 Yarn Workspaces 的功能和配合方式 包管理、依赖安装优化、版本发布、脚本执行等 能够分析技术选型的利弊和实际应用场景 团队协作、构建效率、依赖一致性等 展示架构设计思路和实践经验 二、参考答案 1.1 原理说明 Monorepo 概念 将多个相关的项目包（packages）放在同一代码仓库中统一管理 便于代码复用、版本统一、跨包协调 Lerna 功能 管理 Monorepo 中多个包的版本发布和依赖关系 支持基于 Git 的变更检测，自动决定哪些包需要发布 脚本集中执行，提升跨包开发效率 Yarn Workspaces 功能 优化依赖安装，自动将多个包的依赖扁平化安装，避免重复依赖 支持包之间的本地软链接，方便跨包开发调试 减少 node_modules 大小，提升安装速度 Lerna + Yarn Workspaces 配合优势 Lerna 专注版本和发布管理 Yarn Workspaces 专注依赖管理和安装优化 组合使用，实现 Monorepo 的高效管理和性能提升 1.2 核心用法 + 选择理由 选择 Lerna + Yarn Workspaces 的具体理由 依赖管理高效：Yarn Workspaces 扁平化依赖树，减少冗余，提高安装速度，节省磁盘空间 版本发布便捷：Lerna 支持自动检测改动包，实现增量发布，减少发布成本 跨包开发友好：Workspaces 实现包间软链接，调试时无需发布即可实时联动 统一管理多个包：代码结构清晰，版本一致性好，避免包版本冲突 社区成熟稳定：Lerna 和 Yarn 是成熟开源项目，生态完善，文档丰富 使用场景举例 大型前端项目拆分为多个业务组件包 同时管理多个相关 npm 包，需同步发布和升级 需要提升 CI/CD 流程效率和开发体验 1.3 常见误区或面试陷阱 ❌ 误区一：认为 Lerna 可以独立完成所有 Monorepo 管理工作 实际 Lerna 本身不管理依赖安装，需配合 Workspaces 或 npm/yarn 其他特性 ❌ 误区二：忽视依赖扁平化带来的版本冲突风险 需要合理规划依赖版本，避免冲突和不兼容 ❌ 误区三：Monorepo 不适合所有项目，盲目迁移可能增加复杂度 适用项目规模和团队协作需求需评估清楚 3. 如何解决子包间的循环依赖问题 题目要点 循环依赖会导致加载异常和维护困难 抽取公共模块拆分依赖，消除环路 使用接口抽象和依赖注入解耦 动态导入延迟加载，规避同步循环 设计单向依赖，保持依赖关系 DAG 配合工具检测和团队规范防范 参考答案 一、考察点 理解循环依赖的概念及危害 ...

← 第 1 轮 · 返回本次面经 · 第 1 轮 → 本轮要点： react hooks、列表和key、高阶组件、性能优化、react 渲染机制、React函数组件更新、react 组件设计模式、全方位解读this、类型判断 本轮共 14 道题。答案默认折叠，便于先自行作答。 1. 项目中遇到的最大技术挑战是什么 题目要点 略 参考答案 略 2. 项目整体架构是什么样的 题目要点 略 参考答案 略 3. 在项目中，你们是如何进行前端代码的模块化和组件化的 题目要点 模块化：代码拆分成独立功能模块，使用 ES Module 标准 组件化：UI拆分成可复用组件，封装结构、样式和逻辑 结合构建工具支持模块管理和代码分割 组件通信通过 props、事件、状态管理实现 合理设计文件结构和规范，提升维护性和扩展性 注意职责单一、样式隔离和性能优化 防止模块和组件划分不合理导致管理混乱 参考答案 考察点 理解模块化和组件化的概念及其在前端开发中的重要性 熟悉常见的模块化规范（如 CommonJS、ES Module）及其区别 掌握组件化设计思想和实现方式，尤其是在主流框架中的实践 能结合项目需求合理组织代码结构，提高复用性和维护性 参考答案 一、原理说明 模块化 指将代码拆分成独立的、功能明确的模块，每个模块有自己的作用域和接口，避免全局污染，提高代码可维护性。 常见规范包括： CommonJS（Node.js环境，使用 require 和 module.exports） AMD（异步模块定义，适用于浏览器异步加载） ES Module（ESM）（现代标准，使用 import 和 export，支持静态分析） 组件化 是模块化的进一步细化，专注于 UI 层面，将界面拆分成独立且可复用的组件，封装逻辑、样式和结构。 组件通常包含状态管理、事件处理、生命周期管理等，方便组合和维护。 主流框架如 Vue、React、Angular 都鼓励基于组件开发。 二、项目中模块化和组件化的实践 1. 模块化管理 项目采用 ES Module 作为标准模块规范，利用 import 和 export 进行模块间依赖管理。 通过合理拆分功能模块（如工具库、接口服务、状态管理、业务逻辑）形成清晰的依赖关系，便于维护和测试。 使用构建工具（Webpack、Vite）支持模块打包和代码分割，提高加载效率。 配合 alias 和路径管理，保持模块引用简洁，提升开发体验。 2. 组件化设计 界面层面，拆分成粒度合适的可复用组件，满足单一职责原则。 采用状态提升、属性传递和事件回调机制实现组件间通信。 使用组件库（如 Element UI、Ant Design）或自研组件库提升开发效率。 结合样式模块化（CSS Modules、Scoped CSS、CSS-in-JS）实现样式隔离，防止样式冲突。 组件支持配置化和插槽机制，提高灵活性和扩展性。 3. 代码组织结构 按业务域或功能划分文件夹，模块和组件分层清晰，便于定位和扩展。 统一入口导出，方便模块聚合和复用。 编写完善的文档和规范，确保团队成员对模块和组件使用方式达成共识。 4. 优势与价值 提高代码复用率，减少重复开发和维护成本。 降低耦合度，提升系统可扩展性。 加快开发节奏，方便多人协作。 利用现代构建工具实现性能优化。 三、常见误区与注意点 模块划分过细或过粗 导致管理困难或代码臃肿，需根据项目复杂度合理拆分。 组件职责不明确，混合业务逻辑和表现层，影响复用和测试。 忽视样式隔离，导致样式污染和冲突。 组件间通信设计不合理，导致状态管理混乱。 忽略模块和组件的性能优化，如避免无意义的重新渲染和重复加载。 4. 项目中做过哪些性能优化方面的工作 题目要点 资源按需加载与代码拆分减少首屏加载时间 静态资源压缩、合并和 CDN 加速 图片优化与懒加载 减少 DOM 操作，合理使用虚拟 DOM JS 任务拆分，使用防抖节流和 Web Worker 接口合并、缓存和 HTTP/2 多路复用 持续性能监控与数据驱动优化 避免过度拆分和缓存策略失误 注重整体性能和用户设备多样性 参考答案 考察点 理解前端性能优化的核心目标与常见瓶颈 掌握多种性能优化手段及其适用场景 能结合具体项目场景，分析问题并提出有效优化策略 熟悉常用性能监控和评估工具，验证优化效果 参考答案 一、原理说明 前端性能优化的核心目标是提升页面加载速度、响应速度和交互流畅度，从而改善用户体验，降低用户流失。 性能瓶颈通常来源于资源加载慢、渲染阻塞、JavaScript 执行耗时、内存泄漏和网络请求频繁等。 现代性能优化涉及多个层面，包括网络层、资源层、渲染层和代码执行层。 性能优化不仅是技术问题，更涉及合理架构设计和业务合理拆分。 二、项目中的具体优化实践 1. 资源加载优化 采用代码拆分（Code Splitting）和按需加载，避免一次性加载大量无关代码，缩短首屏加载时间。 使用 CDN 分发静态资源，提升资源下载速度。 资源压缩和合并（如压缩 JS/CSS，合并小文件减少请求数量）。 图片优化（WebP 格式替代、图片懒加载、合理尺寸裁剪）。 利用浏览器缓存策略（Cache-Control、Service Worker）减少重复请求。 2. 渲染性能优化 减少 DOM 操作次数，合并多次修改，避免触发频繁回流和重绘。 使用虚拟 DOM 和虚拟列表技术优化大量数据渲染。 CSS 动画尽量使用 GPU 加速属性（如 transform、opacity）。 避免长任务阻塞主线程，合理拆分 JS 任务，防止界面卡顿。 3. JavaScript 执行优化 减少不必要的计算和事件绑定，防抖节流常用来优化频繁触发的事件。 使用 Web Worker 将计算密集型任务移至后台线程，避免主线程阻塞。 利用 Tree Shaking 去除未使用代码，减小包体积。 预编译和缓存机制提升运行效率。 4. 网络请求优化 接口合并，减少请求次数。 接口缓存，避免重复请求同一数据。 接口压缩与批量请求。 使用 HTTP/2 多路复用，提升请求并发性能。 5. 性能监控与持续优化 集成性能监控工具（如 Lighthouse、Chrome DevTools Performance、RUM 埋点等）。 通过埋点监控首屏时间、接口响应时间、动画帧率等关键指标。 根据监控数据持续跟踪性能瓶颈，迭代优化。 三、常见误区与注意点 只注重单一优化手段，忽视整体性能提升策略。 盲目过度拆分导致请求过多，反而影响性能。 缓存设置不合理，导致用户看到过期内容。 不关注性能监控数据，缺乏闭环改进。 忽视用户设备差异，优化方案不够适配低端设备。 5. 在移动端开发中，你们是如何处理不同设备的适配问题的 题目要点 了解并使用 viewport 设置布局基础 灵活组合 rem/vw/flex/media query 等单位和布局方案 使用 postcss 工具链统一适配流程 考虑高DPR设备图像清晰度适配 针对横屏、Pad 等极端设备考虑额外样式方案 注重兼容性测试，处理浏览器差异 参考答案 考察点 是否了解常见的移动端适配方案及原理 是否能结合业务场景选择合理的适配策略 是否关注兼容性、用户体验和性能平衡 是否能系统性总结适配技术手段的优缺点 参考答案 一、适配问题的来源 移动端设备种类繁多，存在如下适配挑战： ...