orion_frontend
前端面试题（5 年+ 经验）
招聘方向：React (Web) + Flutter (Mobile) + Node.js (BFF) 全栈/跨平台角色，Tech Lead / 架构师级别。
面试重点：底层原理、架构设计、性能优化、工程化体系、技术选型决策。
注：Flutter 发布至今约 5-6 年，5 年纯 Flutter 经验较难，考察的是 5 年总开发经验 + 深厚 Flutter 实战能力。
一、React 高级（Web 前端核心）
Q1: React Fiber 架构解决了什么问题？React 18 Concurrent Mode 对用户体验的具体提升？
考察点：React 核心渲染机制、是否跟进最新技术。
参考答案要点：
1. Fiber 的目的：解决旧 Stack Reconciler 递归更新阻塞主线程。将渲染任务拆分为小单元，更新过程可中断、可恢复。
2. 数据结构：Fiber Node 链表结构（child, sibling, return），支持增量渲染。
3. React 18 并发特性：
- Automatic Batching：减少渲染次数
- Transitions（useTransition）：非紧急更新标记为低优先级，保证紧急更新不卡顿
- Suspense for Data Fetching：更好的加载状态管理
- useInsertionEffect：解决 CSS-in-JS 时序问题
4. 实际场景：大数据量列表或复杂交互中，利用 startTransition 避免 UI 冻结。
Q2: 大型 React 项目如何设计状态管理方案？Context / Redux/Zustand / Server State 如何选择？
考察点：架构设计能力，对"状态"分类的清晰度。
参考答案要点： 1. 状态分类：UI 状态（本地）→ 全局客户端状态（用户信息、主题）→ 服务器状态（API 数据）→ 表单状态 2. Context 的局限：不适合高频更新状态（所有 Consumer 重渲染），仅适合低频全局配置 3. 客户端状态管理：轻量方案（Zustand/Jotai）替代 Redux，除非需要时间旅行调试 4. Server State：React Query / SWR 处理缓存、去重、后台刷新、乐观更新，不应存入 Redux 5. 架构决策：根据团队规模、项目复杂度给出选型理由
Q3: React 应用性能瓶颈（FPS 低、内存泄漏）排查思路和优化手段？
考察点：性能调优实战。
参考答案要点：
1. 工具链：React DevTools Profiler, Chrome Performance, Lighthouse, Why Did You Render
2. 常见瓶颈：滥用 useEffect，未正确使用 memo/useMemo/useCallback，大列表未虚拟滚动
3. 内存泄漏：未清理定时器、未取消异步请求、闭包引用过大
4. 代码分割：React.lazy + Suspense，路由级拆分
5. 构建优化：Tree Shaking, Bundle Analysis
Q4: React 服务端渲染（SSR）原理？实际项目实现？常见坑？
考察点：SSR 实战经验。
参考答案要点：
1. 核心流程：服务端渲染 HTML → 客户端 Hydration 恢复交互
2. 实现：Next.js 框架，getServerSideProps / getStaticProps / ISR
3. 常见坑：
- 服务端与客户端环境不一致（window/document）→ typeof window !== 'undefined' 判断
- 水合不匹配 → 确保服务端/客户端渲染逻辑一致，避免随机值/时间戳
- SSR 性能问题 → Redis 缓存渲染 HTML，优化数据请求
- 样式错乱 → CSS Modules / styled-jsx
Q5: useEffect vs useLayoutEffect 区别？useCallback 解决了什么问题？
参考答案要点： 1. useEffect：异步执行，不阻塞绘制，用于副作用（数据请求、DOM 操作） 2. useLayoutEffect：同步执行，DOM 更新后、绘制前运行，用于测量布局 3. useCallback：缓存函数引用，避免子组件不必要的重渲染；稳定 useEffect 依赖项
二、Flutter 高级（移动端跨平台）
Q1: Flutter 渲染管线？Widget / Element / RenderObject 三者关系？
考察点：Flutter 核心原理理解。
参考答案要点： 1. 三棵树： - Widget：配置信息（不可变，轻量），描述 UI 长什么样 - Element：生命周期管理者（可变），连接 Widget 和 RenderObject，负责 Diff - RenderObject：实际布局（Layout）和绘制（Paint），重量级 2. 更新流程：Widget 更新 → Element 比对 → 配置变则更新 RenderObject 属性，类型变则重建 3. 四阶段流水线：Build → Layout → Paint → Compositing 4. Key 的作用：列表移动时保持 Element 状态
Q2: Flutter 如何处理耗时操作避免 Jank？Isolate 和 Event Loop 机制？
考察点：移动端性能优化，多线程理解。
参考答案要点：
1. 单线程模型：主 Isolate Event Loop，帧率目标 16ms（60fps）
2. Jank 原因：主线程被耗时计算阻塞
3. 解决方案：
- Isolate：独立内存空间线程，SendPort/ReceivePort 通信，CPU 密集型
- compute()：简化 Isolate 封装
- async/await：仅用于 I/O 密集型，不能解决 CPU 阻塞
4. Impeller 引擎：新版渲染引擎减少 Shader 编译卡顿
Q3: Flutter 状态管理方案对比？如何封装通用状态管理逻辑？
考察点：状态管理架构能力。
参考答案要点： 1. 方案对比： - Provider：轻量简单，官方推荐，复杂场景性能一般 - Bloc：事件驱动，可追溯，模板代码多，适合复杂业务 - GetX：功能全面（状态+路由+依赖注入），开发效率高，封装深 - Riverpod：Provider 升级版，原子化状态，无 context 依赖 2. 选择原则：小项目用 Provider/GetX，中大型用 Bloc/Riverpod 3. 封装实践：基础 Bloc 类（统一 loading/error/empty），通用 Repository（统一网络请求），UI 解耦
Q4: Flutter 与 Native 交互方式？混合开发常见问题？
考察点：混合开发经验，架构稳定性。
参考答案要点：
1. 通信机制：
- MethodChannel：双向方法调用（最常用）
- EventChannel：原生→Flutter 单向事件流
- BasicMessageChannel：双向消息传递，大数据传输
- PlatformView：原生组件嵌入 Flutter
2. 常见坑：
- 线程切换：Native 回调可能在子线程
- 序列化成本：大数据传输用 BinaryMessenger 或共享内存
- 生命周期：App 后台时 Channel 可能断开
3. 架构设计：抽象层（Interface + Factory 注入），统一 PlatformException 处理，pigeon 类型安全生成
4. 兼容性：Android 权限、iOS MethodChannel 调用时机、PlatformView 渲染异常、SDK 版本兼容
Q5: Flutter 性能优化实战？
参考答案要点：
1. 减少 Widget 重建：const 构造函数，避免 build 中创建新对象/函数
2. 优化布局：避免嵌套过深，RepaintBoundary 隔离频繁重绘组件
3. 图片优化：合适分辨率，CachedNetworkImage，列表懒加载
4. 动画优化：Tween 动画替代 setState，AnimationController 控制时长和曲线
三、Web API 与 IndexedDB
Q1: Web API 设计最佳实践？RESTful vs GraphQL？
考察点：API 设计能力。
参考答案要点： 1. RESTful：资源导向，HTTP 动词语义化，状态码规范，适合 CRUD 场景 2. GraphQL：按需查询，单次请求获取多资源，适合复杂前端数据需求 3. 设计原则： - 版本控制（URL 路径或 Header） - 分页（cursor-based / offset-based） - 错误处理（统一错误格式，HTTP 状态码 + 业务错误码） - 安全（CORS, Rate Limiting, JWT/OAuth2） - 文档（OpenAPI/Swagger）
Q2: IndexedDB 的核心概念和使用场景？
考察点：浏览器端大容量存储方案。
参考答案要点： 1. 核心概念： - 数据库 → Object Store（表）→ Index（索引）→ Record（记录） - 异步操作，支持事务（read / readwrite / versionchange） - 容量大（通常可达硬盘空间的 50%+） 2. 使用场景： - 离线缓存（PWA 应用） - 大量结构化数据本地存储（聊天记录、文档草稿） - 替代 localStorage（容量限制 5MB） 3. 封装库：idb, localForage, Dexie.js（简化 API） 4. 注意事项：兼容性（IE 不支持），版本升级（onupgradeneeded 迁移逻辑）
四、微信小程序
Q1: 微信小程序架构原理？与 Web 开发的区别？
考察点：小程序平台理解。
参考答案要点： 1. 双线程架构： - 渲染层（WebView）：负责 WXML/WXSS 渲染 - 逻辑层（JSCore）：执行 JS 代码 - 通过 Native 桥接通信（setData 数据传递） 2. 与 Web 区别： - 无 DOM/BOM API，不能直接操作 DOM - 使用 WXML/WXSS 替代 HTML/CSS - 页面路由由框架管理，非 URL 跳转 - 能力受限（依赖微信提供的 API） 3. 性能优化： - 减少 setData 频率和数据量（避免传递大对象） - 避免频繁 setData（合并操作） - 图片懒加载，分包加载 - 使用 WXS 处理动画和手势（避免逻辑层/渲染层通信开销）
Q2: 小程序跨端方案对比？Taro vs uni-app？
参考答案要点： 1. Taro：React 语法，多端编译（微信/H5/React Native），适合 React 技术栈团队 2. uni-app：Vue 语法，生态丰富，插件市场成熟，适合 Vue 技术栈团队 3. 选型：根据团队技术栈、目标平台、生态需求决定
五、Node.js（BFF 层）
Q1: Node.js Event Loop 机制？v11 前后差异？阻塞场景？
考察点：异步编程底层。
参考答案要点：
1. 六个阶段：Timers → Pending Callbacks → Idle/Prepare → Poll（I/O）→ Check → Close
2. 执行顺序：process.nextTick（微任务，最高）> Promise.then > setTimeout > setImmediate
3. v11 前后差异：
- v11 前：每个阶段结束后执行微任务
- v11+：每个宏任务后执行微任务（与浏览器对齐）
4. 阻塞场景：同步大计算、fs.readFileSync、复杂 JSON.stringify、正则回溯
5. 解决方案：Worker Threads 处理 CPU 密集型，Stream 处理大文件
Q2: Node.js BFF 服务如何保证稳定性和安全性？
考察点：系统设计，生产环境经验。
参考答案要点：
1. 多进程管理：PM2 或 cluster 模块利用多核
2. 稳定性：超时控制，熔断降级（Opossum），内存监控
3. 安全性：Rate Limiting，输入验证（Zod/Joi），CORS & Helmet，依赖扫描
4. 日志与追踪：结构化日志（Winston/Pino），OpenTelemetry 全链路追踪
Q3: Node.js 内存泄漏如何定位和修复？
考察点：调试与排错。
参考答案要点：
1. 现象：RSS 持续上涨，GC 后不下降，OOM 崩溃
2. 定位工具：heapdump, Chrome DevTools Memory, clinic.js, 0x
3. 常见原因：全局变量，闭包引用，缓存无限制，事件监听器未解绑，Stream 未关闭
4. 修复策略：WeakMap，限制缓存大小（LRU），确保事件解绑
Q4: Node.js 高并发场景优化方案？
考察点：高并发架构设计。
参考答案要点： 1. 架构层：cluster 多进程，Nginx 负载均衡，微服务拆分 + 消息队列解耦 2. 代码层：异步 I/O，连接池，多级缓存（本地 Map/lru-cache + Redis），限流降级 3. 部署层：PM2 进程管理（max_memory_restart），异步日志，内核参数优化（文件描述符上限）
六、Git
Q1: Git 分支策略？Git Flow vs GitHub Flow vs Trunk-Based？
考察点：团队协作和版本管理。
参考答案要点： 1. Git Flow：main + develop + feature + release + hotfix，适合有固定发布周期的项目 2. GitHub Flow：main + feature 分支，PR 合并后部署，适合持续交付 3. Trunk-Based：主干开发 + 短生命周期分支 + Feature Flag，适合大型团队高频发布 4. 选型：根据发布频率、团队规模、CI/CD 成熟度决定
Q2: Git rebase vs merge 区别？何时使用？
参考答案要点：
1. merge：保留完整分支历史，产生 merge commit，适合公共分支
2. rebase：线性历史，重写 commit，适合本地 feature 分支同步主干
3. 原则：公共分支用 merge，本地分支用 rebase；never rebase pushed commits
Q3: Git 常见问题解决？
参考答案要点：
1. 冲突解决：git mergetool，理解 conflict markers
2. 误操作恢复：git reflog，git reset vs git revert
3. 大文件处理：Git LFS，.gitignore 排除
七、架构与软技能（5 年+ 经验）
Q1: 老旧单体应用重构（React + Node + Flutter），如何制定演进路线？
参考答案要点： 1. 评估现状：代码覆盖率、技术债务、业务依赖 2. 策略：绞杀者模式（Strangler Fig），逐步剥离功能 3. 基础设施：统一 CI/CD，建立自动化测试屏障 4. BFF 层：Node.js BFF 屏蔽后端差异 5. 组件库：Design System 统一设计语言 6. Monorepo（Turborepo/Nx）共享类型定义和工具库
Q2: 如何保证代码质量？Code Review 关注点？
参考答案要点： 1. 自动化：ESLint, Prettier, Husky (Git Hooks), Jest/Vitest, Cypress 2. CR 关注点：可读性（命名/逻辑），可维护性（SOLID），安全性（XSS/SQL 注入），性能（N+1/无效渲染），边缘情况 3. 文化：小 PR，及时反馈，知识共享
Q3: 三大技术栈的最大痛点及解决方案？
参考答案要点： - React：状态管理碎片化 → Server State 模式简化 - Flutter：包体积大/Web 支持弱 → 按需加载，Wasm 优化 - Node：类型安全弱 → 全面 TypeScript，tRPC / GraphQL 端到端类型安全
面试官评分指南（5 年+ 候选人）
| 维度 | 不合格 (Junior/Mid) | 合格 (Senior) | 优秀 (Lead/Architect) |
|---|---|---|---|
| 原理深度 | 仅知道 API 怎么用 | 知道底层机制（Fiber, Event Loop） | 能修改源码或提出底层优化方案 |
| 性能优化 | 知道 memo |
能用 Profiler 定位并解决 | 能建立性能监控体系，预防退化 |
| 架构设计 | 关注单个组件实现 | 关注模块解耦、状态流转 | 关注系统边界、容错、演进路线 |
| Node/后端 | 仅会简单 CRUD | 理解流、缓冲区、安全、集群 | 理解分布式、高可用、数据库调优 |
| 软技能 | 被动执行任务 | 能独立负责模块 | 能指导他人，制定规范，平衡业务与技术 |
Page Source