滴滴-社招-5年 · 第 1 轮 · 二面

略

一、考察点

• 理解 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 不适合所有项目，盲目迁移可能增加复杂度

• 适用项目规模和团队协作需求需评估清楚

一、考察点

• 理解循环依赖的概念及危害

  • 模块之间相互引用导致依赖链环状，影响构建和运行

• 掌握循环依赖产生的根源和场景

  • 设计缺陷、职责划分不清、过度耦合

• 熟悉解决循环依赖的常用方法和策略

  • 代码重构、接口抽象、依赖反转、动态加载等

• 具备系统思考和架构优化能力

二、参考答案

1.1 原理说明

循环依赖的本质

• A 依赖 B，B 又依赖 A，形成环状引用
• 造成模块加载顺序不确定，可能导致运行时异常或部分模块未定义
• 破坏模块的单向依赖原则，增加维护难度和潜在风险

为什么会出现循环依赖

• 设计时模块职责边界不清晰
• 业务逻辑紧密耦合，缺乏抽象层
• 复用不当或依赖导入写法不合理

1.2 核心解决方案

方案一：调整模块设计，拆分公共依赖

• 抽取循环依赖中的共同部分到独立公共模块
• 让子包只依赖公共模块，避免直接相互依赖

方案二：使用接口或抽象层解耦依赖

• 定义接口或约定，避免直接引用具体实现
• 通过依赖注入或工厂模式降低耦合

方案三：延迟加载或动态导入

• 使用动态 import() 异步加载依赖，打破同步循环引用
• 适用于部分场景，需注意异步处理逻辑

方案四：重构依赖关系，单向依赖原则

• 明确依赖方向，避免双向引用
• 设计清晰的依赖图，确保依赖关系是有向无环图 (DAG)

1.3 实践中注意事项

• 使用工具检测循环依赖，如 ESLint 插件 import/no-cycle
• 在 CI 流程中加入循环依赖检查，防止新增问题
• 代码审查时关注依赖关系，及时发现设计缺陷
• 避免过度耦合，提倡模块职责单一，接口清晰

1.4 示例说明

// 错误示例：A.js 依赖 B.js，B.js 又依赖 A.js

// 解决示例：提取公共逻辑到 Common.js，A.js 和 B.js 依赖 Common.js，避免循环

// Common.js
export function sharedLogic() { /* ... */ }

// A.js
import { sharedLogic } from './Common';
export function funcA() { sharedLogic(); }

// B.js
import { sharedLogic } from './Common';
export function funcB() { sharedLogic(); }

一、考察点

• 理解多端（CLI 与 VS Code 插件）共用代码的架构设计

  • 代码复用、维护性、耦合度控制

• 掌握如何设计和组织共享代码库

  • 目录结构、模块划分、发布方式

• 熟悉构建工具和模块系统的使用

  • CommonJS、ESM 兼容，构建打包配置（如 Rollup、Webpack）

• 了解 VS Code 插件开发及 CLI 应用开发差异与共性

二、参考答案

1.1 原理说明

共享代码的必要性

• CLI 和 VS Code 插件通常存在功能重叠，如核心业务逻辑、配置解析、工具方法等
• 共享代码减少重复开发，保证逻辑一致性，提高维护效率

设计原则

• 将核心功能抽象为无关环境的纯逻辑模块
• 通过独立的共享包管理，方便多个项目依赖和版本控制
• 保持接口稳定，确保不同环境调用一致

技术难点

• 兼容不同运行环境：Node.js 环境下 CLI，VS Code 插件基于 Electron（Node + 浏览器环境）
• 构建方式差异：VS Code 插件通常需要打包成单文件，CLI 直接运行脚本或编译后发布
• 调试体验差异

1.2 核心用法 + 具体实现步骤

1）抽象共享代码为独立包

• 新建一个目录 shared，放置纯业务逻辑代码，无环境依赖
• 使用 TypeScript 或 JavaScript 编写模块，定义清晰的 API

目录结构示例：

/project-root
  /cli
  /vscode-extension
  /shared
    /src
      index.ts

2）共享包的构建与发布

• 使用构建工具（如 Rollup、tsc）将共享代码编译为兼容 CommonJS 和 ESM 的包
• 生成 dist 目录，供 CLI 和插件分别引用

示例 rollup.config.js 简化配置：

import typescript from '@rollup/plugin-typescript';

export default {
  input: 'shared/src/index.ts',
  output: [
    { file: 'shared/dist/index.cjs.js', format: 'cjs' },
    { file: 'shared/dist/index.esm.js', format: 'esm' }
  ],
  plugins: [typescript()]
};

3）CLI 与 VS Code 插件中引用共享代码

• 在 cli 和 vscode-extension 项目中，通过相对路径或 npm workspace 方式引用共享包

// CLI 示例
const shared = require('../shared/dist/index.cjs.js');
shared.someFunction();

// VS Code 插件示例（TypeScript）
import * as shared from '../../shared/dist/index.esm.js';
shared.someFunction();

4）使用 Monorepo + Yarn Workspaces（推荐）

• 通过 Monorepo 管理三个子项目（cli、vscode-extension、shared）
• Yarn Workspaces 自动管理依赖和软链接，方便本地开发调试

package.json 示例（项目根）：

{
  "private": true,
  "workspaces": ["cli", "vscode-extension", "shared"]
}

5）调试与测试

• 在 CLI 和 VS Code 插件中均编写调用共享代码的单元测试
• 使用 VS Code 插件调试配置加载共享模块

1.3 常见误区或面试陷阱

❌ 误区一：将 UI 相关逻辑写入共享代码，导致环境依赖耦合

• 共享代码应纯业务逻辑，避免依赖 DOM、VS Code API 等

❌ 误区二：不区分模块格式，导致兼容性问题

• 确保共享包支持 CommonJS 与 ESM，根据运行环境加载对应模块

❌ 误区三：忽略构建与发布流程，手动复制代码引发版本不一致

• 使用 Monorepo 和自动化构建流程，保证版本统一和开发效率

略

一、考察点

• 理解 Source Map 的作用和原理

  • 调试时将编译后的代码映射回源码，方便定位错误

• 掌握 Vue 单文件组件（SFC）编译流程中 <script> 块的处理

  • 解析、转译、生成代码与 Source Map 关联

• 了解 @vue/compiler-sfc 内部如何生成和合并 Source Map

  • 保障调试体验的连续性和准确性

• 理解多语言 <script>（如 <script lang="ts">）的特殊处理

二、参考答案

1.1 原理说明

Source Map 的基本概念

• Source Map 是一种 JSON 格式的映射文件，关联转换后的代码与原始源码
• 便于开发者调试编译、打包后的代码，准确定位源码位置

Vue SFC <script> 块编译流程

• 单文件组件（.vue）中 <script> 块可能是 JavaScript 或 TypeScript 等语言
• @vue/compiler-sfc 负责解析 .vue 文件，抽取并处理 <script> 内容
• 当 <script> 含有语言预处理（lang="ts"），需先转译成 JS
• 编译器需生成对应的 Source Map，将转换后的代码映射回原始 <script> 源码

Source Map 生成与合并

• 编译器从 <script> 块读取原始源码及其对应的 Source Map（如果有）
• 对源码进行转译（如 TypeScript -> JavaScript），产生新的代码和 Source Map
• 使用工具（如 source-map 库）合并多级 Source Map，保证调试时能准确映射回 .vue 文件源代码

1.2 核心用法 + 处理细节

1）提取和转译 <script> 块源码

• 使用 @vue/compiler-sfc 的 parse 方法获取 <script> 块内容
• 如果有语言（如 TypeScript），交由对应的编译器（如 esbuild、tsc）转译
• 转译产物包含 JS 代码和 Source Map

2）生成或合并 Source Map

• 如果原 <script> 块本身带有 Source Map（比如预处理器产生），需合并
• 合并时将子 Source Map 映射到 .vue 文件对应的源码位置
• 生成的 Source Map 指向 .vue 文件，而非单独的 <script> 文件，便于断点调试

3）输出最终代码和 Source Map

• @vue/compiler-sfc 返回编译结果，包括 JS 代码和对应 Source Map
• 下游构建工具（如 Vite、Webpack）使用该 Source Map 实现调试映射

1.3 常见误区或面试陷阱

❌ 误区一：忽略多级 Source Map 合并

• 转译链中若不合并 Source Map，调试时定位只能到中间产物，无法回到 .vue 文件源码

❌ 误区二：认为 .vue 文件只有 JS 代码，无需处理 Source Map

• .vue 是复合文件，多个块的 Source Map 需综合管理，忽略会丧失调试体验

❌ 误区三：未考虑 <script setup> 和 <script lang="ts"> 等特殊语法的 Source Map 处理

• 这两者涉及更复杂的转译和合并逻辑，必须准确处理映射关系

一、考察点

• 理解抽象语法树（AST）的概念及其作用

  • 代码结构的抽象表示，便于分析和转换

• 掌握作用域（Scope）概念及其重要性

  • 变量声明、访问、生命周期管理

• 熟悉作用域分析的具体步骤和方法

  • 构建作用域链，标记变量定义与引用

• 了解在编译器、静态分析和代码优化中的应用

二、参考答案

1.1 原理说明

抽象语法树（AST）基础

• AST 是代码的树状结构表示，每个节点代表语言结构元素（如表达式、声明）
• 通过 AST，可以系统分析代码语义和结构

作用域的概念

• 作用域定义变量可访问的区域，分为全局作用域、函数作用域、块级作用域等
• 作用域链用于解析变量，确保变量查找的正确性和安全性

作用域分析的目标

• 识别所有变量声明及其所属作用域
• 解析变量引用，确定变量绑定关系
• 发现变量提升、闭包等行为基础

1.2 作用域分析的具体流程

1）初始化全局作用域

• 创建全局作用域对象，作为作用域链的顶层
• 全局作用域包含全局变量和函数

2）遍历 AST 节点

• 使用深度优先遍历（DFS）遍历 AST
• 根据节点类型判断是否进入新作用域（如函数声明、块级作用域）

3）作用域的创建与嵌套

• 遇到函数、块（ES6 let/const）等新作用域节点时，创建新的作用域对象
• 新作用域的父作用域指向当前作用域，形成作用域链结构

4）变量声明收集

• 在当前作用域中收集变量声明（var、let、const、function 参数等）
• 标记变量类型、作用域级别及声明位置

5）变量引用解析

• 遇到变量使用（标识符）节点时，沿作用域链向上查找变量声明
• 确定引用绑定的具体变量，支持闭包和变量捕获分析

6）作用域退出

• 遍历完成当前作用域节点后，返回父作用域，继续遍历

1.3 应用示例与工具

• Babel、ESLint 等工具中均实现了作用域分析
• 作用域信息支持代码转译、变量重命名、死代码消除、闭包分析等

1.4 常见误区或面试陷阱

❌ 误区一：混淆词法作用域和动态作用域

• JavaScript 采用词法作用域，变量作用域由代码结构决定，而非执行顺序

❌ 误区二：忽略块级作用域（let/const）

• ES5 只有函数作用域，ES6 引入块级作用域，影响变量生命周期

❌ 误区三：未处理闭包中的作用域链

• 闭包形成的作用域链是作用域分析的重要难点

一、考察点

• 理解 AST 修改可能引发的语法冲突原因

  • 语法扩展（JSX）与标准 JavaScript 的差异

• 掌握多语法共存情况下的代码解析与生成策略

  • 解析器和生成器对不同语法的支持

• 熟悉工具链（Babel、ESLint、Prettier 等）对 JSX 等扩展的处理

• 具备排查和解决语法冲突的思路与方法

二、参考答案

1.1 原理说明

语法冲突的本质

• AST 修改涉及插入、替换、删除节点，若新节点语法格式不正确或未被解析器支持，导致冲突
• JSX 语法不是标准 JS，需专门解析插件支持，否则生成代码无法被标准 JS 解析器理解
• 修改 AST 时如果未正确处理 JSX 特殊节点，会引发语法错误或转换失败

解析与生成器支持

• 现代工具链（如 Babel）通过插件体系支持 JSX 语法
• AST 修改需基于支持 JSX 的解析器和生成器，保证语法兼容

1.2 解决方案与实践

方案一：使用支持 JSX 的解析器和生成器

• 使用 Babel Parser（@babel/parser）开启 jsx 语法支持
• 使用 Babel Generator（@babel/generator）正确输出 JSX 代码
• 确保所有处理工具链（如 ESLint、Prettier）均开启 JSX 支持

方案二：保持 AST 语法正确性

• 修改 AST 时严格遵守 JSX 语法规范
• 避免在 JSX 标签内插入非法节点或错误结构
• 使用官方 AST 节点类型，如 JSXElement、JSXText、JSXExpressionContainer

方案三：分离处理非 JSX 与 JSX 代码

• 对含 JSX 的代码片段单独处理，其他标准 JS 代码分开处理
• 在构建管线中合理配置 Loader 和插件，确保 JSX 代码被正确处理

方案四：逐步调试和验证

• 利用 AST 可视化工具（如 AST Explorer）确认修改后的 AST 结构正确
• 单元测试覆盖修改后代码生成结果，保证无语法错误
• 通过源码映射（Source Map）确保调试体验正常

1.3 常见误区或面试陷阱

❌ 误区一：用不支持 JSX 的解析器解析含 JSX 的代码

• 导致解析失败或丢失 JSX 信息

❌ 误区二：直接操作 AST 字符串化，忽视语法树结构完整性

• 可能破坏语法树，导致生成代码有误

❌ 误区三：忽略工具链对 JSX 的支持配置，导致格式化或检查失败

• 需要统一配置支持 JSX 的规则和插件

一、考察点

• 理解性能瓶颈的多维度来源

  • 网络请求、资源加载、渲染效率、JavaScript 执行等

• 掌握常见前端性能优化手段和技术

  • 从页面加载、渲染到交互的全流程优化

• 具备根据具体场景制定针对性优化策略的能力

• 了解工具使用与监控性能指标的方法

二、参考答案

1.1 原理说明

性能瓶颈分类

• 网络性能：请求数量多、资源大小大、请求阻塞等
• 渲染性能：DOM 复杂度高、频繁重排重绘、动画不流畅
• JavaScript 执行性能：长任务阻塞主线程、低效算法
• 内存性能：泄漏、溢出导致卡顿或崩溃

性能优化目标

• 缩短首次内容渲染时间（FCP）
• 缩短首次交互时间（TTI）
• 降低页面卡顿，提升响应速度
• 减少资源消耗，提升用户体验

1.2 核心优化策略

资源加载优化

• 使用 CDN 和缓存策略

  • 静态资源分发，浏览器缓存、HTTP 缓存控制（Cache-Control）

• 资源压缩与合并

  • 图片压缩、代码压缩（minify）、文件合并减少请求

• 按需加载和懒加载

  • 路由分割、组件懒加载、图片懒加载降低首屏体积

• 减少 HTTP 请求

  • 使用雪碧图、字体图标合并、HTTP/2 多路复用

渲染性能优化

• 减少 DOM 操作

  • 批量修改 DOM，避免频繁读写引起回流重绘

• 避免强制同步布局

  • 避免读取影响布局的属性（如 offsetHeight）后立即写入样式

• 合理使用 CSS 动画和硬件加速

  • 利用 transform、opacity 代替布局属性动画

• 虚拟列表和虚拟 DOM

  • 只渲染可视区域节点，减少渲染压力

JavaScript 执行优化

• 任务拆分

  • 使用 Web Worker、requestIdleCallback 异步执行长任务

• 高效算法和数据结构

  • 减少不必要的计算和循环

• 事件节流和防抖

  • 限制高频事件处理次数，减少重复执行

• 避免内存泄漏

  • 清理事件监听、定时器，避免闭包造成泄漏

监控与调试

• 使用浏览器 DevTools（Performance、Network、Memory）
• Lighthouse、WebPageTest 等工具测评
• 埋点与日志收集实际用户性能数据

1.3 常见误区或面试陷阱

❌ 误区一：无针对性盲目优化

• 先定位瓶颈，再针对性优化，避免资源浪费

❌ 误区二：只关注页面加载，不重视交互流畅度

• 优化用户体验需要兼顾加载和交互两方面

❌ 误区三：忽略移动端设备性能差异

• 低端设备需要更多性能考虑和适配

略