jitu 面试记录

面试日期：2025-01-01
面试公司：jitu
应聘职位：前端开发

面试关键词

🏗️ 微前端架构

为什么使用微前端？

当前部门只是一个业务部，所在的部门是物流部，还有其他部门，负责的业务是物流相关的业务，前端代码量上百万行时，多人开发，耦合度很高，改动一个模块容易影响全局，测试、构建、部署都很慢。

qiankun 微前端方案的优势：

业务模块划分：可以将寻源、物流、订单、支付等模块拆分，每个子应用可以独立开发、测试、发布，不会影响其他模块
技术栈渐进升级：老项目 jQuery、AngularJS 迁移到 Vue/React 重构成本太高，可以采用微前端，新项目使用新的技术栈，老项目保持原来的技术栈，新老功能共存
容错能力强：每个子模块相互独立，某个模块崩溃都不会影响整体
按需加载：支持按需加载，减少首屏体积，提升性能

📦 依赖管理

全局 CDN 插件、工具库，版本挂载到主应用 window 上，怎么去做统一的升级？

方案一：Window 对象挂载

将工具或者组件挂载在主应用 window 上，子应用可以通过 window 来访问组件或者库

方案二：映射表管理

主应用维护一个组件或者工具的映射表挂在 window 上，主应用在启动的时候加载这些依赖，子应用再去相应的检测、加载

方案三：CDN 软链/别名

自建 CDN 或者 OSS 的话，通过软链/别名实现灰度发布升级，主应用子应用代码都不改变

方案四：模块联邦

模块联邦依赖共享（缺点：主子应用都必须使用 webpack5）

🔄 状态管理

两个系统的状态管理怎么做，比如登录后将信息共享到所有子应用？

方案一：Props 传递

主应用加载子应用时，通过 props 传递数据给子应用

方案二：共享 Storage

使用 LocalStorage + StorageEvent 实现跨应用状态共享

⚙️ 技术难点

微前端有没有遇到印象深刻的技术难点，怎么解决？

难点一：公共依赖版本冲突

问题描述：

例如主应用 React 18，子应用是 React 16 以下，打包时 React 加载了两份

解决方案：

使用 externals 配置公共依赖，主应用通过 CDN 统一引入 React/Vue
子应用通过 webpack 配置 externals，不再打包这些依赖

难点二：主应用统一登录，但进入子应用时状态丢失

问题描述：

子应用无法访问主应用的 store

解决方案：

通过 props 传递注入给子应用
或者使用 BroadcastChannel 进行跨应用通信

难点三：样式污染

解决方案：

使用 CSS Module，加上 module 配置
使用 createShadowRoot() 包裹子应用根节点，实现样式隔离
使用 qiankun 沙箱样式隔离功能

难点四：每次切换都要重新加载 bundle.js，加载慢

解决方案：

采用预加载策略，使用首屏加载（Service Worker）技术

难点五：非父子间通信

解决方案：

使用全局事件总线
基于 Shared Worker 或 BroadcastChannel 实现跨应用通信

🔍 异常监控

如何优化线上异常日志监控？

1. 框架级捕获

React 使用 ErrorBoundary 组件进行错误边界处理
Vue 使用 app.config.errorHandler 进行全局错误处理

2. Source Map 上报

部署前将 sourcemap 上传到监控平台 Sentry 上去，开启堆栈反解码，便于定位生产环境的错误代码位置

🛠️ 监控优化

监控平台误报怎么处理，U1库的源码报错怎么忽略？

方案一：Sentry 配置规则

在 Sentry 后台配置过滤规则：Project Settings → Inbound Filters（或 Issue Stream → Ignore）

方案二：代码层过滤

在 Sentry.init() 中使用 beforeSend 回调，可以在上报前过滤掉特定类型的报错，例如第三方库的错误

总结

本次面试主要围绕微前端架构展开，涉及的核心问题包括：

架构设计：微前端的价值、qiankun 方案的优势
工程化：CDN 依赖管理、版本升级策略
状态管理：跨应用状态共享方案
问题解决：依赖冲突、状态丢失、样式污染、性能优化等
监控体系：异常捕获、Source Map、误报过滤

通过这次面试，深入了解了微前端在大型项目中的实际应用场景和解决方案。