https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/Recent content in 阿里巴巴-社招-1年 on Last StandHugozh-cnMon, 28 Jul 2025 11:54:27 +0000https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/round-98/Mon, 28 Jul 2025 11:54:27 +0000https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/round-98/<blockquote> <p>← <a href="https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/round-97/">第 1 轮</a> · <a href="https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/">返回本次面经</a> · 已是最后一轮 →</p> </blockquote> <p><strong>本轮要点：</strong> react hooks、性能优化</p> <p>本轮共 10 道题。答案默认折叠，便于先自行作答。</p> <h2 id="question-subjective-8c25c1ddc7f3">1. 你们项目为什么选Redux而非MobX</h2> <h3 id="题目要点">题目要点</h3> <ul> <li>Redux 强调可预测性、单向数据流、纯函数 reducer，适合复杂项目</li> <li>丰富的调试工具和社区中间件支持开发效率和可维护性</li> <li>MobX 响应式自动追踪，适合快速开发，但隐式依赖增加调试难度</li> <li>团队规模和项目复杂度是选择状态管理方案的关键因素</li> <li>现代 Redux 已大幅简化，代码冗余感降低</li> </ul> <details> <summary>参考答案</summary> <h2 id="一考察点">一、考察点</h2> <ul> <li><strong>是否理解 Redux 和 MobX 两种状态管理库的设计理念与差异</strong></li> <li><strong>是否能结合项目实际需求，论述选择某一方案的合理性</strong></li> <li><strong>是否掌握 Redux 在复杂状态管理中的优势与局限</strong></li> <li><strong>是否能表达对团队协作、维护性和性能的综合考虑</strong></li> </ul> <hr> <h2 id="二参考答案">二、参考答案</h2> <h3 id="11-原理说明">1.1 原理说明</h3> <h4 id="redux">Redux</h4> <ul> <li><strong>基于 Flux 架构思想，使用单一全局状态树（Store）</strong></li> <li>状态只读，通过派发（dispatch）纯函数（Reducer）更新状态</li> <li>强调<strong>不可变数据和纯函数</strong>，方便调试和时间旅行（time-travel debugging）</li> <li>侧重于<strong>可预测性和可维护性</strong></li> </ul> <h4 id="mobx">MobX</h4> <ul> <li>采用响应式编程思想，通过可观察（observable）数据和自动追踪依赖实现状态同步</li> <li>支持<strong>隐式状态更新</strong>，使用更接近传统面向对象编程</li> <li>适合快速开发，较少样板代码</li> </ul> <hr> <h3 id="12-选择-redux-的主要理由">1.2 选择 Redux 的主要理由</h3> <h4 id="1明确的状态流向和可预测性">1）明确的状态流向和可预测性</h4> <ul> <li>Redux 的单向数据流和纯函数 reducer 让状态变化过程清晰、易追踪</li> <li>在多人协作中，可以方便定位状态更新的具体原因，减少调试成本</li> </ul> <h4 id="2强大的开发者工具支持">2）强大的开发者工具支持</h4> <ul> <li>Redux DevTools 提供时间旅行、快照对比、action 日志等，极大提升调试体验</li> <li>有丰富的中间件生态（如 redux-thunk、redux-saga），便于处理复杂异步逻辑</li> </ul> <h4 id="3适合大型复杂项目">3）适合大型复杂项目</h4> <ul> <li>状态结构复杂时，Redux 更便于组织和维护，模块化拆分 reducer 明确职责</li> <li>明确的规范和社区共识，团队成员易于理解和统一编码风格</li> </ul> <h4 id="4可测试性强">4）可测试性强</h4> <ul> <li>Reducer 是纯函数，易于单元测试，保证业务逻辑可靠</li> </ul> <hr> <h3 id="13-不选-mobx-的考虑">1.3 不选 MobX 的考虑</h3> <h4 id="1隐式依赖难以追踪">1）隐式依赖难以追踪</h4> <ul> <li>MobX 的自动依赖追踪机制带来状态变化的隐式性，可能导致调试困难</li> <li>团队成员对响应式原理不熟悉时，维护成本升高</li> </ul> <h4 id="2状态变化不够可预测">2）状态变化不够可预测</h4> <ul> <li>MobX 允许任意地方修改状态，可能出现难以预料的副作用</li> <li>不利于实现严格的状态管理和权限控制</li> </ul> <h4 id="3社区规范和中大型项目生态">3）社区规范和中大型项目生态</h4> <ul> <li>Redux 生态成熟且社区规范丰富</li> <li>MobX 在某些复杂场景下不够透明，团队风险较大</li> </ul> <hr> <h3 id="14-常见误区或面试陷阱">1.4 常见误区或面试陷阱</h3> <h4 id="-误区一认为-mobx-性能一定优于-redux">❌ 误区一：认为 MobX 性能一定优于 Redux</h4> <ul> <li>实际性能差异因项目而异，合理使用 Redux 也能实现优秀性能</li> </ul> <h4 id="-误区二redux-代码一定繁琐难写">❌ 误区二：Redux 代码一定繁琐难写</h4> <ul> <li>现代 Redux 工具（如 Redux Toolkit）极大简化开发体验，减少样板代码</li> </ul> <h4 id="-误区三认为-mobx-是魔法不需要学习状态管理原理">❌ 误区三：认为 MobX 是“魔法”，不需要学习状态管理原理</h4> <ul> <li>响应式原理本身也需要深入理解，否则容易导致维护难题</li> </ul> </details> <h2 id="question-subjective-9bdd9b86d8fe">2. 项目中提到“首屏加载优化1.5秒”，具体如何实现</h2> <h3 id="题目要点-1">题目要点</h3> <ul> <li>首屏加载优化核心在于减少首屏资源体积和请求数量</li> <li>结合 SSR/SSG 预渲染，缩短白屏时间</li> <li>动态拆分代码，懒加载非关键资源</li> <li>充分利用浏览器缓存和 CDN</li> <li>监控指标涵盖 FCP、TTI，持续迭代优化</li> </ul> <details> <summary>参考答案</summary> <h2 id="一考察点-1">一、考察点</h2> <ul> <li><strong>理解首屏加载的定义及关键性能指标（如 FCP、TTI）</strong></li> <li><strong>掌握多种前端性能优化手段，涵盖资源、网络、渲染等层面</strong></li> <li><strong>能结合具体技术和业务场景，说明优化实施细节</strong></li> <li><strong>理解优化过程中的权衡与监控方法</strong></li> </ul> <hr> <h2 id="二参考答案-1">二、参考答案</h2> <h3 id="11-首屏加载的概念与性能指标">1.1 首屏加载的概念与性能指标</h3> <ul> <li> <p><strong>首屏加载</strong>：用户打开页面到看到页面主要内容（首屏内容）完整渲染的时间</p>https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/round-97/Mon, 28 Jul 2025 11:47:07 +0000https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/round-97/<blockquote> <p>← 已是第一轮 · <a href="https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/">返回本次面经</a> · <a href="https://amatsuzero.github.io/LastStand/posts/frontend/interview-experiences/experience-61/round-98/">第 1 轮</a> →</p> </blockquote> <p><strong>本轮要点：</strong> Webpack与Vite、事件循环、跨域通信</p> <p>本轮共 16 道题。答案默认折叠，便于先自行作答。</p> <h2 id="question-subjective-80619f2d22f7">1. 项目中遇到了哪些技术难题，是如何解决的</h2> <h3 id="题目要点">题目要点</h3> <p>STAR法则</p> <details> <summary>参考答案</summary> <p>略</p> </details> <h2 id="question-subjective-8eccdcf5f029">2. 在解决这些技术难题的过程中，有没有尝试过其他解决方案</h2> <h3 id="题目要点-1">题目要点</h3> <p>略</p> <details> <summary>参考答案</summary> <p>略</p> </details> <h2 id="question-subjective-97e442c116a5">3. 项目中是如何进行团队协作的</h2> <h3 id="题目要点-2">题目要点</h3> <p>略</p> <details> <summary>参考答案</summary> <p>略</p> </details> <h2 id="question-subjective-ff0b3dbd2346">4. 在团队协作中，有没有遇到过沟通不畅或者意见不合的情况？是如何解决的</h2> <h3 id="题目要点-3">题目要点</h3> <p>略</p> <details> <summary>参考答案</summary> <p>略</p> </details> <h2 id="question-subjective-78a32c9021bc">5. webpack 的 plugin 了解吗</h2> <h3 id="题目要点-4">题目要点</h3> <ul> <li>Plugin 是 Webpack 扩展机制，贯穿构建全过程</li> <li>核心结构是类 + <code>apply(compiler)</code> + Tapable 钩子</li> <li>常见生命周期钩子：<code>compile</code>、<code>emit</code>、<code>done</code> 等</li> <li>可用于注入变量、分析构建、生成资源、操作产物等</li> <li>熟悉 compiler 与 compilation 的概念</li> <li>可结合实际项目经验举例说明插件使用场景</li> </ul> <details> <summary>参考答案</summary> <h2 id="一考察点">一、考察点</h2> <ul> <li> <p><strong>是否理解 Plugin 在 Webpack 中的作用和工作机制</strong></p> <ul> <li>Plugin 是 Webpack 最核心的扩展机制之一</li> </ul> </li> <li> <p><strong>是否掌握编写 Plugin 的基本方法和生命周期</strong></p> <ul> <li>了解 <code>compiler</code>、<code>compilation</code>、钩子（hooks）等概念</li> </ul> </li> <li> <p><strong>能否结合实际项目场景说明使用插件的案例和目的</strong></p>