Q1：同时精通 React 和 Vue，实际选型时你怎么决策？⭐⭐⭐ 🔥#

考察点：是否理解两个框架的设计哲学，而不是只会 API。

参考回答：

我不认为”哪个更好”是个有意义的问题，选型要看三个维度：

1. 团队基因：团队之前用什么、成员的心智模型是什么，迁移成本永远比框架优劣更贵。
2. 业务形态：
   • 中后台、强表单、快速交付 → Vue + Element/ProComponents 生态成熟，模板语法对多人协作更友好；
   • 复杂交互、重状态逻辑、需要精细控制渲染 → React 的函数式模型 + Hooks 组合能力更强，配合 zustand 这类原子化状态库可以做到很细的渲染控制。
3. 渲染目标：需要 SSR/SEO 深度定制时，Next.js 生态目前仍是第一梯队；纯客户端应用两者差距不大。

我自己的习惯是：在 React 里用 Vue 的思维审视模板复杂度，在 Vue 里用 React 的思维审视状态流向。双栈的价值不是会两套 API，而是能跳出单一框架的惯性去设计架构。

Q2：React 和 Vue 的响应式原理有什么本质区别？⭐⭐⭐ 🔥#

参考回答：

• Vue：编译时 + 运行时结合的依赖收集。Vue 3 用 Proxy 拦截数据读写，组件渲染时收集依赖，数据变更时精确通知到依赖它的组件，更新粒度是”组件级 + 依赖级”。
• React：不可变数据 + 调度重渲染。状态变更触发组件及其子树重新执行 render 函数，通过 diff 决定真实 DOM 操作。React 不追踪”谁依赖了哪个数据”，所以需要 memo / useMemo / useCallback 手动做优化，或者靠 zustand 这类带 selector 的状态库实现精确订阅。

一句话总结：Vue 把优化做在框架里，React 把优化交给开发者。这也解释了为什么 React 项目更容易出现”改一处、渲染一片”的性能问题——它是心智模型层面的差异。

Q3：TypeScript 在大型项目里怎么落地，遇到过哪些深水区问题？⭐⭐⭐#

参考回答：

落地路径上我推动过三件事：

1. 严格模式渐进开启：先 strictNullChecks，再全量 strict，配合 CI 卡口防止回退；
2. 类型收口：接口类型从服务端 Schema（OpenAPI/protobuf）自动生成，杜绝手写漂移；
3. 公共类型库：把业务实体、枚举、组件 Props 规范沉淀到 monorepo 的 shared 包。

深水区问题举两个例子：

• 泛型与配置驱动：做「模板 × 场景 × 画幅」这类配置化渲染时，需要用条件类型 + 映射类型让配置项和组件 Props 联动，配置写错在编译期就报错，而不是运行时白屏；
• 声明文件的坑：调用 C++ SDK 的 N-API 桥接层、UVC 设备协议这类没有类型的原生模块，需要手写 .d.ts 并把回调风格封装成 Promise 泛型，保证调用侧类型完整。

我的观点是：TS 的收益不在写的时候，而在改的时候。类型覆盖率上到 90% 以后，重构的心理成本会下降一个数量级。

Q4：SSR、SSG、ISR 分别适合什么场景？ISR 的实现原理是什么？⭐⭐ 🔥#

参考回答：

ISR 原理：页面带 revalidate 时间，过期后的第一个请求仍返回旧页面（stale），同时后台触发再生成，生成完成后原子替换缓存——即 stale-while-revalidate 策略。它把 SSG 的性能和 SSR 的时效性折中了。

Q5：SSR 项目最常见的坑有哪些？⭐⭐⭐#

参考回答：

1. 同构代码的环境判断：window / document 在 Node 端不存在，需要动态 import 或 useEffect 内访问；Konva、Three.js 这类 Canvas 库必须 ssr: false 或客户端懒加载；
2. 数据获取的瀑布流：getServerSideProps 里串行 await 多个接口会拖垮 TTFB，要 Promise.all 并行，或下沉到 BFF 聚合；
3. hydration mismatch：服务端和客户端渲染结果不一致（时间戳、随机数、UA 相关逻辑）会导致整棵树降级重渲染，必须保证首屏输出确定性；
4. 缓存分层：CDN 缓存、Next.js 的 fetch 缓存、浏览器缓存三层要统一设计，尤其是带 Cookie 的个性化页面必须 Cache-Control: private。

Q6：复杂画布应用怎么做图层编排？Konva 的性能瓶颈在哪里？⭐⭐⭐#

参考回答：

图层编排：Konva 的 Layer 对应独立 Canvas，我把图层按”更新频率”划分而不是按业务划分——静态背景一层、低频元素一层、高频交互（拖拽、动画）一层。高频层重绘不会波及静态层，这是 Konva 性能优化的第一原则。

瓶颈与对策：

1. 节点数量：上千节点时命中检测（hit graph）变慢 → 简化非交互元素的 hitFunc，或 listening: false 跳过检测；
2. 重绘范围：整层重绘代价高 → 拆分 Layer，必要时用 layer.draw() 局部控制；
3. 图片解码：大量高清图同步 decode 卡主线程 → 预加载 + createImageBitmap 异步解码 + LRU 缓存；
4. 导出场景：toDataURL 大画布很慢 → 导出走离屏 Canvas + Worker 处理（OffscreenCanvas），主线程不阻塞。

Q7：2D 画布转纹理和 Three.js 协同渲染，具体怎么做的？⭐⭐⭐#

参考回答：

场景是需要在 3D 场景里展示可交互编辑的 2D 内容（如画布设计稿贴到 3D 样机上）。方案：

1. Konva 画布本身就是一个 <canvas> 元素，直接作为 THREE.CanvasTexture 的源；
2. 关键在更新节流：Konva 每次重绘后标记 texture.needsUpdate = true，但不能每帧都传——用 rAF 合并，一帧最多上传一次；
3. 大画布显存压力：2D 画布分辨率高时纹理占用显存大，按 3D 场景实际展示尺寸做降采样，并设置合理的 mipmap；
4. 交互映射：3D 场景里点击模型表面，通过射线检测拿到 UV 坐标，反算回 2D 画布坐标，转发给 Konva 的命中系统——实现”在 3D 里编辑 2D”。

这套协同的核心经验：2D 和 3D 各自维护单一职责，用纹理做单向数据流，用坐标映射做交互回流，不要试图让两个渲染循环互相侵入。（完整实现见 前端深水区实战 第二章）

Q8：「模板 × 场景 × 画幅」这种多维组合问题，配置驱动怎么设计？⭐⭐⭐ 🔥#

参考回答：

这是我最有代表性的架构实践。问题本质：模板有 N 种、场景有 M 种、画幅有 K 种，if-else 写死是 N×M×K 的分支爆炸。

设计分四层：

1. Schema 层：用 JSON Schema 描述”一个画面由哪些元素组成、每个元素的可变属性（位置、尺寸、数据源、可见条件）”；
2. 约束层：画幅变化不是简单缩放——定义元素的对齐规则、伸缩优先级、最小尺寸、溢出策略（裁切/缩放/隐藏），类似 CSS 的约束求解，但由配置声明；
3. 场景层：场景差异（数据源、主题、语言）以”变量注入”方式解析进 Schema，模板本身不感知场景；
4. 运行时层：统一的渲染管线消费解析后的配置，Konva 和 DOM 两套渲染器实现同一接口。

收益：新增一个画幅从”改 N 个模板”变成”写一份约束配置”；组合正确性由 TS 类型 + Schema 校验在编译期/发布前拦截。把组合问题从代码空间搬到配置空间，是这类需求的通解。（四层架构与求解器代码见 前端深水区实战 第一章）

Q9：同一份前端产物适配 Android / iOS WebView、桌面客户端与浏览器，架构上怎么做？⭐⭐⭐ 🔥#

参考回答：

核心是桥接层抽象 + 能力降级矩阵：

1. 统一 Bridge SDK：定义与宿主无关的能力接口（相机、存储、支付、设备信息、窗口控制），每个宿主实现一个 adapter：
   • Android：JavascriptInterface / addWebMessageListener；
   • iOS：WKScriptMessageHandler；
   • 桌面客户端（Electron/CEF）：preload 注入 IPC；
   • 浏览器：降级实现（WebRTC / IndexedDB / Web API）或标记能力不可用。
2. 能力探测而非宿主嗅探：启动时握手交换 capability 列表，业务代码只问”有没有这个能力”，不问”在哪个宿主”。UA 嗅探是不可维护的。
3. 构建期分平台产物：webpack/Rollup 按宿主维度出包，用环境变量裁剪掉不可能用到的 adapter，控制包体。
4. 通信协议版本化：Bridge 协议带版本号，客户端升级慢于 H5 时按版本协商降级，这是 Hybrid 长期维护的生命线。

Q10：Node N-API 调用 C++ SDK、对接 UVC 摄像头，前端工程师做到这一层的价值是什么？难点在哪？⭐⭐⭐#

参考回答：

价值：打通”前端产物 → 桌面客户端 → 外设硬件”的全链路，设备相关问题不用等客户端团队排期，排查半径覆盖全链路。

实践要点：

1. N-API 封装：C++ SDK 是回调风格，N-API 层用 ThreadSafeFunction 把设备事件安全地抛回 JS 主线程，再封装成 EventEmitter + Promise 的 API；
2. UVC 协议：设备枚举、格式协商（分辨率/帧率/YUYV-MJPEG）、控制指令（曝光、对焦）都要处理；采集帧经共享内存/回调传给渲染层，注意背压——JS 消费不过来时要丢帧策略而不是堆积；
3. 设备状态同步机制：热插拔是最大难点。设计了”设备状态机 + 事件广播”：连接、就绪、忙、异常、断开每个状态迁移都发事件，UI 层订阅后做防御性渲染；断线重连用指数退避，重连成功后校验会话（比如摄像头被其他进程占用要给出明确错误）；
4. 崩溃隔离：C++ 层崩溃不能带走整个客户端进程，SDK 跑在独立子进程，主进程监控心跳自动拉起。

Q11：离线包差量热更新怎么设计？⭐⭐⭐#

参考回答：

1. 包的粒度：离线包 = 静态资源 bundle + 版本清单（manifest：文件哈希列表）；
2. 差量下发：客户端上报本地版本 manifest，服务端对比算出差量文件列表，只下载变更文件（文件级 diff 足够，bsdiff 级二进制 diff 用于超大单文件）；
3. 原子切换：下载写入临时目录，全部校验通过后一次性切换软链/路径指针，避免半更新状态；
4. 回滚兜底：保留上一版本，新版本首启崩溃计数超阈值自动回滚；
5. 安全：包签名校验（防篡改）+ HTTPS 下发 + 版本号防降级。

这套机制让 H5 功能发布摆脱了 WebView 缓存和发版节奏的约束，紧急修复分钟级触达。（manifest 结构与更新流程见 前端深水区实战 第四章）

Q12：webpack / Rollup 构建调优，你的方法论是什么？⭐⭐ 🔥#

参考回答：

先测量再优化，顺序是：

1. 定位耗时：webpack 用 speed-measure-plugin，Rollup/Vite 看 phase 耗时；
2. 缓存：filesystem cache、babel/swc 缓存、持久化缓存到 CI（命中率是关键指标）；
3. 换编译器：babel → swc/esbuild，loader 层提速通常 5~10 倍；
4. 减少工作量：DLL/预构建第三方库、缩小 resolve 范围、include/exclude 精确化；
5. 并行：thread-loader、多入口分包并行构建；
6. 产物层：分平台构建时用环境变量 + DefinePlugin 做 tree-shaking 友好的死代码消除，避免把全宿主 adapter 打进一个包。

我的原则：构建时间优化的尽头是缓存和任务图，不是调参。

Q13：字体子集化和包体裁剪怎么做？⭐⭐#

参考回答：

字体是国际化产品的包体大户，一个全量 CJK 字体 10MB+：

1. 子集化：用 fonttools/pyftsubset 按”实际用到的字符集”裁剪——静态文案直接扫描源码提取；动态内容（用户昵称、商品名）按 GB2312 常用字 + 业务词库兜底；
2. 多语言分片：按 unicode-range 切分 woff2 分片，浏览器按需加载对应语言的字体分片，而不是一次拉全量；
3. 授权字体处理：商用授权字体往往不能修改原文件，和字体厂商确认子集化授权，或用”系统字体栈 + 关键标题用图/SVG”的策略绕开；
4. 包体裁剪：bundle analyzer 常态化，lodash/moment 这类全家桶换成 lodash-es/按需引入或 dayjs；组件库用 ESM + sideEffects 配置保证 tree-shaking 生效。

Q14：渲染性能治理，你的排查和落地流程？⭐⭐⭐ 🔥#

参考回答：

流程是”度量 → 归因 → 治理 → 防劣化”：

1. 度量：Performance 面板录制定位长任务；线上用 PerformanceObserver 采集 LCP / INP / 长任务分布，按机型分档看 P75 而不是平均值；
2. 常见归因：
   • JS 长任务阻塞主线程 → 拆片（scheduler / requestIdleCallback）、移入 Worker；
   • 高频重渲染 → React 侧 selector 精确订阅、memo 边界；Canvas 侧图层拆分（见 Q6）；
   • 布局抖动 → 读写分离，批量 DOM 操作；
   • 图片解码 → 异步 decode + 尺寸预设防 CLS；
3. 防劣化：CI 里跑 Lighthouse CI，性能预算（bundle size / LCP）超标直接卡合并。性能治理不是一次项目，是一套门禁。

Q15：埋点体系怎么设计？线上问题如何定位？⭐⭐⭐#

参考回答：

埋点设计：

1. 分层：全埋点（PV/点击/曝光自动采集）+ 代码埋点（业务语义事件）+ 性能埋点（Web Vitals）+ 异常埋点（error/unhandledrejection/资源加载失败）；
2. 声明式优先：曝光和点击用指令/HOC 声明，业务代码不手写上报，schema 统一管理事件字典，防止口径漂移；
3. 上报策略：批量合并 + 空闲上报 + 页面卸载时 sendBeacon，采样率按事件类型分级。

线上定位：错误上报带 sourcemap 还原堆栈 + 用户行为回溯（breadcrumb）+ 设备/宿主/版本维度。我落地的关键一步是异常和埋点串联：一条报错能看到用户前 30 步操作路径和所在宿主环境，Hybrid 场景下”哪个客户端版本 + 哪个 H5 离线包版本”的组合问题靠这个定位效率提升非常明显。

Q16：zustand 和 Redux 怎么选？⭐⭐ 🔥#

参考回答：

• Redux（+RTK）：强规范、中间件生态成熟、devtools 时间旅行完善，适合大团队强约束、状态流转复杂需要审计的场景；
• zustand：API 极简、无 Provider、selector 精确订阅天然对渲染友好，适合中小规模状态、跨组件工具型状态（如画布编辑器状态、设备连接状态）。

我的实际决策依据是状态的性质：业务流转型状态（表单流、下单流）需要明确 action 语义的用 Redux 风格；工具型/视图型状态（UI 状态、订阅式数据）用 zustand。两者混用没有问题，关键是团队约定清楚每类状态归谁管。

Q17：讲一个你做过的”重复逻辑收敛为共用组件”的实际案例？⭐⭐⭐#

参考回答：

典型场景：多个业务分支各自实现了”设备选择 + 状态展示 + 重连操作”的 UI，行为细节互不一致（有的轮询、有的事件驱动，错误文案五花八门），维护时一个 bug 要改四处。

收敛步骤：

1. 先梳理差异再抽象：把各分支实现的行为列成矩阵，区分”本质差异”（业务确实不同）和”实现漂移”（本该一样但写岔了）；
2. 分层抽象：底层是无 UI 的 useDeviceSession hook（连接状态机 + 事件订阅），中层是带默认交互的组合组件，顶层允许业务通过 Props/slot 定制；
3. 配置化承接差异：本质差异不进代码分支，进配置项；
4. 迁移策略：新旧并存一个迭代，灰度切换，用埋点对比迁移前后行为一致性。

抽象的度我有个经验法则：第三次重复出现时再抽象，前两次忍住。过早抽象的成本比重复代码更高，因为你还不知道哪些是变轴。

Q18：BFF 层解决什么问题？用 Egg.js / Express 怎么设计？⭐⭐⭐#

参考回答：

BFF 解决的是”端的诉求和服务端的领域模型不匹配”：

1. 接口聚合：一个页面要调 4 个微服务，BFF 聚合成 1 个请求，串行变并行，弱网收益显著；
2. 数据裁剪与整形：服务端返回的领域模型字段多、结构深，BFF 按端（H5/小程序/桌面）输出恰好需要的结构；
3. 端侧逻辑上收：权限拼装、多语言文案选择、降级策略放 BFF，各端不用重复实现。

设计上注意：BFF 是薄层，不承载核心业务规则和事务；做好超时与熔断（下游慢不能拖死 BFF）；缓存放在 BFF 层收益最大（页面级数据 Redis 缓存 + 主动失效）。

我有 Java（Spring Boot + MyBatis + Nacos）服务端经验，所以能独立打通「后台配置 → 服务端下发 → 端上消费」全链路——这个能力在做配置驱动渲染系统时特别关键：配置模型怎么定义、下发协议怎么设计、灰度怎么做，前端一个人就能端到端负责。（Node.js 服务端更多细节见 Node.js 面试题专篇）

Q19：多语种文案体系怎么设计？缺失怎么监控？⭐⭐#

参考回答：

1. 文案管理：文案 key 化，源语言（如中文）为基准，翻译平台管理词条，构建时按语言产出资源包；
2. 缺失监控：
   • 构建期：扫描代码中的 key 与语言包 diff，缺失直接 CI 告警；
   • 运行期：i18n 库的 missing handler 上报缺失 key + 页面 + 语言维度，聚合后就是”翻译缺口看板”；
3. 按需加载：语言包按页面/模块分片，跟随路由懒加载，而不是一次性全量下发；
4. 排版问题：德语/俄语文案比中文长 30%~100%，UI 必须弹性布局 + 关键位置定义截断/换行策略，这类问题要在设计规范层面前置解决。

Q20：多语言下的字体问题怎么处理？⭐⭐#

参考回答：

三个层面：

1. 字符集裁剪：按目标语言裁字体子集（阿拉伯语、泰语、CJK 各自独立分片），unicode-range 按需加载；
2. 授权替换：品牌字体在部分地区无授权时，定义”授权字体 → 地区替代字体”的映射表，font-family 栈按语言环境动态生成；
3. 排版适配：RTL（阿拉伯语/希伯来语）用逻辑属性（margin-inline-start 代替 margin-left）；行高、断词（word-break / hyphens）按语言配置。

Q21：你说的”规范驱动（spec + TDD 实施计划）的人机协作流程”具体是怎么运作的？⭐⭐⭐ 🔥#

参考回答：

这是我目前主推的工作流，分四步：

1. Spec 先行：需求先写成结构化 spec（背景、边界、验收标准、非目标），人负责把模糊需求收敛成无歧义文档——这一步 AI 辅助起草，人做裁决；
2. TDD 实施计划：让 AI 基于 spec 先产出测试用例（验收标准的可执行化），再生成实施计划（改动文件清单 + 每步验证方式），人审查计划而不是审查生成结果；
3. 执行与校验：AI 按计划实施，每步跑测试绿灯再进下一步；
4. 行级归因：对 AI 产出的 diff 逐行做归因审查——“这行改动对应 spec 哪一条？测试覆盖了没有？“不能归因的改动一律拒收。

关键认知：AI 放大的是清晰需求的产出效率，放大不了模糊需求的正确率。spec 写得越准，AI 的价值越大；跳过 spec 直接”帮我写个 xxx”，返工成本会吞掉所有效率收益。（完整工作流见 前端深水区实战 第五章）

Q22：Claude Code、自定义 Skill、MCP 工具链你分别怎么用？⭐⭐#

参考回答：

• Claude Code：日常主力，承担仓库级理解、跨文件重构、测试生成。用得好的关键是给它足够的上下文约定（项目规范文件）和明确的验证闭环（测试命令）；
• 自定义 Skill：把团队高频流程固化成 Skill——比如”按我们的 commit 规范生成提交信息""按组件模板生成新组件+测试+文档”，把个人经验变成团队可复用的自动化；
• MCP：打通 AI 与内部系统的边界——接内部文档库、设计稿平台、监控平台，让 AI 能直接查线上报错、读设计规范，而不是靠人复制粘贴喂上下文。

对 AI 产出的质量底线：任何合入必须经过行级归因 + 本地自测，AI 是初稿引擎，人是最终责任人。

Q23：前端工程师需要掌握 Docker / K8s / Nginx 到什么程度？⭐⭐#

参考回答：

不需要到 SRE 深度，但要能独立完成”部署与排障闭环”：

1. Nginx：路由转发、gzip/brotli、缓存头策略、SPA history fallback、反向代理与跨域处理——这些直接决定前端性能优化的最后一公里；
2. Docker：多阶段构建（node 构建 + nginx 运行）、镜像瘦身、构建缓存优化；
3. K8s：看得懂 Deployment/Service/Ingress/ConfigMap，能自己排查 Pod 起不来（镜像、探针、资源限制）、能配合灰度发布调整路由权重。

Q24：前端 SEO 优化你实际做过哪些？⭐⭐ 🔥#

参考回答：

1. 渲染策略：核心内容 SSR/SSG 化，保证爬虫拿到完整 HTML（Next.js 的 metadata API 管理 TDK、Open Graph、canonical）；
2. 结构化数据：JSON-LD 标注商品、文章、面包屑，争取富媒体摘要；
3. 性能即 SEO：Core Web Vitals（LCP/INP/CLS）是排名因子，性能治理和 SEO 是同一件事；
4. 工程细节：sitemap 自动生成与提交、robots 管理、多语言 hreflang 标注、URL 规范化（去参数化、统一大小写与尾斜杠）；
5. 验证：Search Console 监控收录与展现，配合日志分析爬虫抓取行为，确认 SSR 内容真实可达。