前端面试题手册

Webpack 有哪些优化手段？从构建速度和产物体积两个方向回答，面试中最常考察的优化点如下：构建速度优化1. 持久化缓存// webpack.config.jsmodule.exports = { cache: { type: 'filesystem', // Webpack 5 支持 buildDependencies: { config: [__filename] } }}首次构建后缓存写入 node_modules/.cache/webpack，二次构建可减少 60%-80% 时间。修改配置文件会自动失效。2. 缩小 Loader 处理范围module.exports = { module: { rules: [{ test: /\.js$/, include: path.resolve(__dirname, 'src'), // 只处理 src 目录 exclude: /node_modules/, use: 'babel-loader' }] }}不配置 include 时，Babel 会遍历 node_modules 中所有 JS 文件，构建时间翻倍。3. 多线程编译thread-loader：将耗时的 loader 放到 worker 池中并行执行terser-webpack-plugin 开启 parallel: true：并行压缩 JSWebpack 5 原生支持 parallel 配置4. 优化模块解析module.exports = { resolve: { extensions: ['.ts', '.tsx', '.js'], // 按使用频率排列，减少尝试次数 alias: { '@': path.resolve(__dirname, 'src') }, // 别名减少路径查找 }, module: { noParse: /lodash|jquery/, // 跳过已打包库的解析 }}noParse 告诉 Webpack 这些库没有 import/require，不需要解析依赖关系。5. 使用更快的编译器swc-loader 替代 babel-loader（Rust 实现，速度快 20 倍以上）esbuild-loader 替代 terser-webpack-plugin（Go 实现）6. DLL 预编译（Webpack 4 适用）// webpack.dll.config.jsnew webpack.DllPlugin({ name: '[name]', path: path.join(__dirname, 'dll', '[name]-manifest.json')})将 React、Vue 等不变库提前编译成 DLL，开发构建跳过。Webpack 5 的持久化缓存已基本替代此方案。产物体积优化1. 代码分割（Code Splitting）splitChunks — 提取公共依赖：module.exports = { optimization: { splitChunks: { chunks: 'all', cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, name: 'vendors', chunks: 'all' } } } }}将 node_modules 中的库打包到独立 chunk，利用浏览器缓存。动态 import() — 按需加载：const Home = React.lazy(() => import('./Home'));const About = React.lazy(() => import('./About'));路由级懒加载，首屏只加载当前路由代码。 splitChunks 是配置层面的自动提取，动态 import() 是代码层面的手动分割，两者配合使用。2. Tree Shakingmodule.exports = { mode: 'production', // 自动开启 optimization: { usedExports: true, minimize: true, }}前提条件：必须使用 ESM（import/export），不能用 CommonJS（require）babel-loader 配置 "modules": false 防止转译为 CJSpackage.json 标记 "sideEffects": false 告知安全移除未使用导出为什么需要 ESM？ ESM 的 import/export 是静态声明，编译时可确定依赖关系；CommonJS 的 require 是运行时调用，可以在 if 中使用，打包工具无法静态分析。3. Scope Hoisting（作用域提升）module.exports = { optimization: { concatenateModules: true, // 生产模式默认开启 }}将模块合并到同一个闭包中，减少函数声明和闭包数量，体积可减小 5%-10%。4. 压缩JS：terser-webpack-plugin（Webpack 5 生产模式默认启用）CSS：css-minimizer-webpack-pluginconst CssMinimizerPlugin = require('css-minimizer-webpack-plugin');module.exports = { optimization: { minimizer: [ new CssMinimizerPlugin(), ], }}5. externals 排除大型库module.exports = { externals: { react: 'React', 'react-dom': 'ReactDOM' }}将 React、Lodash 等通过 CDN 引入，不打包进 bundle，显著减小产物体积。6. 图片与资源优化小于 8KB 的图片转 base64 内联（Webpack 5 的 asset/inline）大图使用 image-webpack-loader 压缩或转 WebP{ test: /\.(png|jpg)$/, type: 'asset', parser: { dataUrlCondition: { maxSize: 8 * 1024 } // 8KB 以下内联 }}7. IgnorePlugin 排除无用模块new webpack.IgnorePlugin({ resourceRegExp: /^\.\/locale$/, contextRegExp: /moment$/})忽略 moment.js 的 locale 文件，体积减少约 200KB。构建分析工具| 工具 | 用途 ||------|------|| webpack-bundle-analyzer | 可视化分析产物体积，找出大依赖 || speed-measure-webpack-plugin | 统计各 loader/plugin 耗时 || webpack --profile --json > stats.json | 导出构建统计数据 |Webpack 5 新特性补充Module Federation：跨应用共享模块，实现微前端，避免重复打包公共依赖持久化缓存：替代 DLL 方案，配置更简单Asset Modules：内置资源模块，替代 url-loader/file-loader更好的 Tree Shaking：支持嵌套的 Tree Shaking 和内部模块的 Tree Shaking追问splitChunks 和动态 import 有什么区别？splitChunks 是 Webpack 配置层面的自动优化，根据策略提取公共依赖（如 node_modules 中的库），开发者无需手动干预。动态 import() 是代码层面的手动分割，由开发者决定哪些模块按需加载。两者互补：splitChunks 处理共享依赖，动态 import 处理路由级懒加载。Tree-Shaking 为什么需要 ESM？ESModule 的 import/export 是静态声明，在编译阶段就能确定模块的依赖关系和哪些导出被使用。CommonJS 的 require 是运行时调用，可以写在 if 语句、循环或函数中，打包工具无法在编译时判断哪些代码会被执行，因此无法安全移除未使用的代码。此外，需确保 Babel 不将 ESM 转译为 CJS（配置 "modules": false），并在 package.json 中声明 "sideEffects": false。webpack 的 cache 缓存了什么？为什么能加快构建？缓存了每个模块的 loader 处理结果和编译产物。首次构建后写入磁盘（node_modules/.cache/webpack），二次构建时 Webpack 检查文件时间戳和内容 hash，只重新编译变化的模块及其依赖链上的模块，未变化的模块直接使用缓存。典型场景：修改一个组件文件，只重新编译该文件和引用它的文件，其余数千模块跳过，构建时间从 30s 降到 5s 以内。Webpack 5 的 filesystem 缓存相比 Webpack 4 的 memory 缓存，重启开发服务器后缓存不丢失。Module Federation 解决了什么问题？多个独立构建的应用之间共享模块，避免重复打包相同依赖。典型场景：微前端架构中，主应用和子应用都依赖 React，传统方案各自打包 React，用 Module Federation 可以在运行时共享一份 React，减少总体加载量。核心配置是 exposes（暴露模块）和 remotes（消费远程模块），实现应用间的模块级复用。

基本用法：CustomEvent 三步走自定义事件的核心流程就三步：创建 → 监听 → 触发。// 1. 创建事件const event = new CustomEvent('user-login', { detail: { userId: 42, role: 'admin' }, // 携带数据 bubbles: true, // 是否冒泡 cancelable: true // 能否被 preventDefault() 取消});// 2. 监听element.addEventListener('user-login', (e) => { console.log(e.detail); // { userId: 42, role: 'admin' }});// 3. 触发element.dispatchEvent(event);detail 是 CustomEvent 独有的字段，用于携带任意数据，和 Event 构造函数的唯一区别就在这里。Event 只能表示"某件事发生了"，CustomEvent 还能告诉你"发生了什么"。事件的冒泡与委托bubbles: true 让事件沿 DOM 树向上冒泡，这意味着你可以在父元素上统一监听子元素发出的自定义事件：// 子元素派发child.dispatchEvent(new CustomEvent('item-delete', { detail: { id: 1 }, bubbles: true}));// 父元素委托监听parent.addEventListener('item-delete', (e) => { console.log('删除了:', e.detail.id); e.stopPropagation(); // 阻止继续冒泡});这是事件委托在自定义事件上的直接应用——不需要给每个子元素绑定监听器，一个父元素就够了。手写 EventEmitter：脱离 DOM 的事件系统自定义事件依赖 DOM，但面试常考的是纯 JS 的发布订阅实现。核心就是一个事件名到回调数组的映射：class EventEmitter { constructor() { this.events = new Map(); } on(event, handler) { if (!this.events.has(event)) { this.events.set(event, []); } this.events.get(event).push(handler); return this; // 支持链式调用 } off(event, handler) { const handlers = this.events.get(event); if (handlers) { this.events.set(event, handlers.filter(h => h !== handler)); } return this; } emit(event, ...args) { const handlers = this.events.get(event); if (handlers) { handlers.forEach(h => h(...args)); } return this; } once(event, handler) { const wrapper = (...args) => { handler(...args); this.off(event, wrapper); }; this.on(event, wrapper); return this; }}once 的实现要点：用包装函数代替原函数注册，触发后自动解绑。面试写到这里基本够用。自定义事件 vs 发布订阅：何时选谁| 维度 | CustomEvent | EventEmitter ||------|-------------|--------------|| 依赖 | DOM 元素 | 纯 JS，无依赖 || 事件传播 | 冒泡/捕获，支持委托 | 无传播机制 || 数据传递 | detail 字段 | 直接参数 || 内存管理 | 移除元素自动清理 | 需手动 off || Shadow DOM | composed: true 可穿透 | 不涉及 |简单判断：需要 DOM 层级传播用 CustomEvent，纯数据流用 EventEmitter。无框架组件通信没有 Vue/React 时，自定义事件就是组件通信的基础设施：// 子组件：触发事件class MyInput extends HTMLElement { connectedCallback() { this.addEventListener('input', () => { this.dispatchEvent(new CustomEvent('value-change', { detail: { value: this.value }, bubbles: true })); }); }}// 父组件：监听子组件事件parent.querySelector('my-input') .addEventListener('value-change', (e) => { console.log(e.detail.value); });这就是 Web Components 通信的基本模式，也是浏览器原生组件化方案的核心机制。Shadow DOM 边界与 composedShadow DOM 默认隔离事件。composed: true 让 CustomEvent 穿透 Shadow DOM 边界，否则事件被封闭在 Shadow DOM 内部：// Shadow DOM 内部派发shadow.dispatchEvent(new CustomEvent('inner-action', { detail: { data: 1 }, bubbles: true, composed: true // 关键：穿透 Shadow DOM}));composedPath() 方法可以查看事件经过的完整路径，调试 Shadow DOM 事件传播时很有用。内存泄漏防护自定义事件常见的内存陷阱：移除元素前没解绑监听器，或者闭包引用了大对象。// 错误示范：匿名函数无法解绑el.addEventListener('my-event', (e) => { /* ... */ });// 无法 off，因为匿名函数没有引用// 正确做法：保存引用const handler = (e) => { /* ... */ };el.addEventListener('my-event', handler);// 用完解绑el.removeEventListener('my-event', handler);更安全的方案是用 AbortController：const controller = new AbortController();el.addEventListener('my-event', handler, { signal: controller.signal});// 批量清理controller.abort();一个 abort() 就能清理同一 controller 下的所有监听器，比逐个 removeEventListener 方便得多。追问自定义事件和发布订阅有什么区别？自定义事件绑定在 DOM 元素上，有冒泡/捕获机制、事件委托、stopPropagation 等 DOM 事件系统的完整能力。发布订阅（EventEmitter）是纯 JS 模式，没有 DOM 树概念。需要跨层级通信、事件委托时用自定义事件；需要纯数据流、完全与 DOM 无关时用发布订阅。不用框架（Vue/React）怎么用自定义事件做组件通信？父组件给子组件传一个 DOM 元素引用，子组件在这个元素上 dispatchEvent(new CustomEvent('change', { detail: value }))，父组件监听这个元素的 change 事件。这是 Web Components 的通信基础。也可以用自定义元素的属性变化回调 observedAttributes + attributeChangedCallback 配合事件派发做双向通信。自定义事件可以跨 Shadow DOM 吗？可以。composed: true 的 CustomEvent 会穿透 Shadow DOM 边界，不设置则封闭在 Shadow DOM 内部。用 event.composedPath() 可以查看事件传播的完整路径，这对调试 Shadow DOM 内的事件流向很有帮助。

什么是柯里化？柯里化（Currying）是将一个接受多个参数的函数，转换成一系列每次只接受一个参数的函数。转换后的函数会逐步收集参数，直到参数齐全才执行原函数。// 普通函数function add(a, b, c) { return a + b + c;}add(1, 2, 3); // 6// 柯里化后function curryAdd(a) { return function(b) { return function(c) { return a + b + c; }; };}curryAdd(1)(2)(3); // 6核心价值是参数复用和延迟执行——你可以先固定部分参数，得到一个更具体的函数，等剩余参数就位再调用。手写通用 curry 函数面试中最常考的是手写一个通用的 curry，它能将任意多参数函数转为柯里化形式：function curry(fn) { return function curried(...args) { // 收集的参数数量 >= 原函数参数数量，直接执行 if (args.length >= fn.length) { return fn.apply(this, args); } // 否则返回新函数继续收集 return (...nextArgs) => curried.apply(this, args.concat(nextArgs)); };}验证：function sum(a, b, c) { return a + b + c;}const curriedSum = curry(sum);curriedSum(1)(2)(3); // 6curriedSum(1, 2)(3); // 6 —— 支持一次传多个参数curriedSum(1)(2, 3); // 6关键点：利用 fn.length 判断原函数期望的参数个数，利用闭包在调用链中持续传递已收集的参数。柯里化的实际使用场景参数复用：创建预设函数function log(level, timestamp, message) { console.log(`[${level}] ${timestamp}: ${message}`);}const curriedLog = curry(log);const errorLog = curriedLog('ERROR'); // 预设 levelconst errorLogNow = errorLog(Date.now()); // 预设 timestamperrorLogNow('接口超时'); // [ERROR] 1748400000000: 接口超时errorLogNow('数据解析失败'); // 复用前两个参数bind 方法的本质Function.prototype.bind 就是偏函数应用——预设 this 和部分参数，返回新函数：const obj = { x: 42 };function getX(extra) { return this.x + extra;}const boundGetX = getX.bind(obj, 8); // 预设 this + 第一个参数boundGetX(); // 50Redux 中间件的函数链Redux 中间件签名 store => next => action => {} 就是三级柯里化：const logger = store => next => action => { console.log('dispatching', action); const result = next(action); console.log('next state', store.getState()); return result;};第一层拿到 store，第二层拿到 next（下一个中间件），第三层处理 action。分层柯里化使得每层的职责清晰，也方便测试——你可以只传入部分参数来测试中间件的某一步。React 事件处理中的参数绑定// 方式一：bind 预设参数<button onClick={handleClick.bind(null, item.id)}>删除</button>// 方式二：高阶函数（本质也是柯里化）const handleClick = (id) => (e) => { e.stopPropagation(); deleteItem(id);};<button onClick={handleClick(item.id)}>删除</button>柯里化与偏函数的区别两者容易混淆，核心区别在于参数接收方式：柯里化：将函数转为一系列一元函数，每次只接受一个参数（f(a)(b)(c)）偏函数：预先填充部分参数，返回的函数仍可接受多个参数（f(a, b) → f'(c, d)）// 柯里化：每次一个参数const curriedAdd = curry((a, b, c) => a + b + c);curriedAdd(1)(2)(3); // 6// 偏函数：一次传剩余参数function partial(fn, ...presetArgs) { return (...laterArgs) => fn(...presetArgs, ...laterArgs);}const addFive = partial((a, b) => a + b, 5);addFive(3); // 8bind 是偏函数，不是严格柯里化——因为 bind 返回的函数可以一次接收多个参数。柯里化的局限与注意事项性能开销：每次柯里化调用都会创建新的闭包和函数对象，在性能敏感场景（如高频事件处理、大循环内）应避免过度使用。只处理显式参数：fn.length 无法识别默认参数、rest 参数。带默认值的函数柯里化后行为可能不符合预期：function greet(name, greeting = 'Hello') { return `${greeting}, ${name}`;}greet.length; // 1，只有 name 是显式参数curry(greet)('Alice'); // 直接返回 "Hello, Alice"，跳过了 greeting 的柯里化步骤调试困难：柯里化链越长，调用栈越深，错误堆栈的可读性越差。生产代码中应控制嵌套层级。追问柯里化和偏函数有什么区别？柯里化将函数拆成一元函数链（f(a)(b)(c)），偏函数预设部分参数但返回函数仍可多参（f(a, b) → f'(c, d)）。bind 是偏函数不是严格柯里化。能手写一个通用的 curry 函数吗？利用闭包持续收集参数，用 fn.length 判断参数是否齐全，齐全则执行，否则返回新函数继续收集。见上方"手写通用 curry 函数"部分。柯里化在 React 中有什么应用？事件处理器的参数预绑定：onClick={handleClick(id)} 用高阶函数延迟执行；Hooks 中的自定义 Hook 参数分步传入也是类似思路。

JavaScript 的继承方式有以下七种，按演进顺序理解更容易记住：原型链继承、构造函数继承、组合继承、原型式继承、寄生式继承、寄生组合继承、ES6 class extends。面试中重点掌握组合继承的问题和寄生组合继承的优化思路。原型链继承将子类的原型指向父类的实例：function Parent() { this.name = 'parent'; this.colors = ['red', 'blue'];}Parent.prototype.getName = function() { return this.name;};function Child() {}Child.prototype = new Parent();const child1 = new Child();const child2 = new Child();child1.colors.push('green');console.log(child2.colors); // ['red', 'blue', 'green'] — 共享了！核心问题：所有子实例共享父实例的引用类型属性，一个实例修改了 colors，其他实例也受影响。构造函数继承在子类构造函数中调用父类构造函数：function Parent() { this.colors = ['red', 'blue'];}function Child() { Parent.call(this); // 借用构造函数}const child1 = new Child();child1.colors.push('green');console.log(new Child().colors); // ['red', 'blue'] — 不共享了解决了引用属性共享的问题，但新的问题出现了：方法只能定义在构造函数里，每次创建实例都会重新创建方法，无法复用。而且根本访问不到父类原型上的方法。组合继承把上面两种方式组合起来——属性用构造函数继承，方法用原型链继承：function Parent(name) { this.name = name; this.colors = ['red', 'blue'];}Parent.prototype.getName = function() { return this.name;};function Child(name, age) { Parent.call(this, name); // 第二次调用 Parent this.age = age;}Child.prototype = new Parent(); // 第一次调用 ParentChild.prototype.constructor = Child;这是最常用的经典方案，但有一个效率问题：Parent 被调用了两次。第一次 new Parent() 在子类原型上创建了 name 和 colors，第二次 Parent.call(this) 又在实例上创建了同名的属性，原型上的那份其实是多余的。原型式继承不定义构造函数，直接基于已有对象创建新对象：function createObj(o) { function F() {} F.prototype = o; return new F();}// ES5 标准化了这个模式Object.create(proto, propertiesObject);和原型链继承有同样的共享问题——引用类型的属性会被所有派生对象共享。适用于不需要单独创建构造函数、只想让一个对象类似于另一个对象的场景。寄生式继承在原型式继承的基础上，增强对象后返回：function createChild(original) { const clone = Object.create(original); clone.sayHi = function() { console.log('hi'); }; return clone;}通过封装函数给对象添加能力，但和构造函数继承一样——每个实例都会重新创建方法，无法复用。寄生组合继承组合继承的优化版，也是目前公认的最优继承方案：function Parent(name) { this.name = name; this.colors = ['red', 'blue'];}Parent.prototype.getName = function() { return this.name;};function Child(name, age) { Parent.call(this, name); // 只调用一次 Parent this.age = age;}// 关键：用 Object.create 代替 new Parent()Child.prototype = Object.create(Parent.prototype);Child.prototype.constructor = Child;和组合继承相比，只改了一行：把 Child.prototype = new Parent() 换成了 Child.prototype = Object.create(Parent.prototype)。这一改做到了两件事：只调用一次父类构造函数，子类原型上不会出现多余的实例属性。ES6 的 class extends 经 Babel 编译后，底层就是寄生组合继承。ES6 class extendsclass Parent { constructor(name) { this.name = name; this.colors = ['red', 'blue']; } getName() { return this.name; }}class Child extends Parent { constructor(name, age) { super(name); // 必须在 this 之前调用 this.age = age; }}语法糖，底层仍然是原型链 + 寄生组合继承，但做了额外约束：不用 new 调用会报错（内置 new.target 检查）类方法不可枚举extends 同时继承静态属性和原型方法super 作为关键字比 Parent.call(this) 更安全，确保父类构造函数在访问 this 之前执行七种方式对比| 方式 | 引用属性共享 | 方法复用 | 父类调用次数 | 适用场景 ||------|:---:|:---:|:---:|------|| 原型链继承 | 共享 | 可以 | 1 | 不含引用属性的简单继承 || 构造函数继承 | 不共享 | 不可以 | 1 | 只需继承属性不需方法 || 组合继承 | 不共享 | 可以 | 2 | 传统项目，兼容性要求高 || 原型式继承 | 共享 | 可以 | 0 | 基于对象快速派生 || 寄生式继承 | 共享 | 不可以 | 0 | 给对象添加增强能力 || 寄生组合继承 | 不共享 | 可以 | 1 | ES5 环境下最优选择 || ES6 class extends | 不共享 | 可以 | 1 | 现代开发首选 |追问寄生组合继承为什么是最优方案？只调用一次父类构造函数，避免了组合继承中子类原型上出现冗余实例属性的问题。原型链保持干净——子类原型是通过 Object.create(Parent.prototype) 创建的空对象，只包含指向父类原型的方法，不包含父类实例属性。这是 ES5 环境下兼顾效率和正确性的最佳方案。ES6 class 和寄生组合继承有什么本质区别？class 不只是语法糖，它在语义层面做了额外约束：1) 不用 new 调用直接报错（new.target 检查）；2) 类方法默认不可枚举；3) extends 同时继承静态属性，寄生组合继承做不到这点需要手动处理；4) super 是关键字而非函数调用，引擎保证父类构造函数在子类访问 this 之前执行，比 Parent.call(this) 更安全。Object.create 和 new 有什么区别？Object.create(proto) 创建一个新对象并将其 __proto__ 指向 proto，不执行任何构造函数逻辑。new Constructor() 会执行构造函数，将函数体内的 this 绑定到新对象，执行初始化逻辑后返回该对象。寄生组合继承用 Object.create 替代 new Parent()，目的就是避免多执行一次父类构造函数中的初始化逻辑。为什么组合继承中父类被调用了两次？第一次是 Child.prototype = new Parent()，这一步在子类原型上创建了 name、colors 等实例属性。第二次是 Parent.call(this, name)，在子类实例自身上又创建了同名属性。实例访问属性时先找自身再找原型，所以原型上那些属性虽然存在但永远不会被访问到，属于冗余创建。寄生组合继承用 Object.create 绕过了第一次调用，只保留实例属性的正确初始化。

直接用 setInterval 有一个经典问题：如果回调执行时间超过了间隔时间，回调会在事件队列中堆积。用 setTimeout 递归模拟能解决这个痛点——每次回调执行完再设置下一次定时器，确保上一次执行完毕才开始下一轮计时。function mySetInterval(fn, delay) { let timer = null; function loop() { fn(); timer = setTimeout(loop, delay); } timer = setTimeout(loop, delay); return () => clearTimeout(timer);}const cancel = mySetInterval(() => console.log('tick'), 1000);// cancel(); 需要停止时调用核心思路：在回调函数末尾递归调用 setTimeout，使得下一次定时器只有在上一次回调执行完毕后才会被注册。返回一个取消函数，调用时 clearTimeout 清除当前等待中的定时器，递归链就此中断。setInterval 的回调堆积问题setInterval(fn, 100) 的行为是：每隔 100ms 向任务队列放入一个 fn，不管前一个 fn 是否执行完毕。如果 fn 执行需要 150ms：100ms：第一个回调进入队列，开始执行200ms：第二个回调进入队列（第一个还没执行完）300ms：第三个回调进入队列结果是回调不断排队，等当前任务执行完后，队列中的回调会连续执行，间隔远小于预期。这不是"跳过间隔"，而是"堆积后连续执行"。setTimeout 模拟的优势与局限优势：不会回调堆积，每次执行完才开始计时下一轮间隔更可控，实际间隔 ≈ delay + 回调执行时间局限：仍然不精确——setTimeout 只保证"至少延迟 delay 毫秒"，受事件循环和主线程阻塞影响如果回调本身执行时间很长，实际间隔会远大于设定值带错误处理的增强实现基础版本有个隐患：回调抛异常时，递归链中断，定时器静默停止。加上 try-catch 可以保证异常不会打断后续执行：function mySetIntervalSafe(fn, delay) { let timer = null; function loop() { try { fn(); } catch (e) { console.error('定时器回调异常:', e); } timer = setTimeout(loop, delay); } timer = setTimeout(loop, delay); return () => clearTimeout(timer);}支持 this 绑定和参数传递原生 setInterval 支持 setInterval(fn, delay, arg1, arg2) 的参数传递和 this 绑定。补全这两个能力：function mySetIntervalFull(fn, delay, ...args) { let timer = null; const context = this; function loop() { try { fn.apply(context, args); } catch (e) { console.error('定时器回调异常:', e); } timer = setTimeout(loop, delay); } timer = setTimeout(loop, delay); return () => clearTimeout(timer);}// 用法：传递参数mySetIntervalFull((name, count) => { console.log(`${name}: ${count}`);}, 1000, 'tick', 42);追问如果需要真正精确的定时循环怎么办？setTimeout 模拟解决的是回调堆积问题，不能解决定时精度问题。精确计时需要其他方案：requestAnimationFrame + performance.now()：适合动画循环，每帧检查时间戳决定是否执行Web Worker 定时器：在独立线程运行，不受主线程阻塞影响时间戳补偿：记录预期执行时间和实际已执行次数，根据偏差动态调整下一轮 delay能不能用 setInterval 模拟 setTimeout？可以，执行一次后立即 clearInterval：function mySetTimeout(fn, delay) { const id = setInterval(() => { fn(); clearInterval(id); }, delay);}但实际中没人这么做——setTimeout 本身就是更合适的 API，这个追问考查的是对两个定时器语义的理解。递归 setTimeout 会不会导致栈溢出？不会。setTimeout 的回调是宏任务，每次执行时调用栈已经清空，递归是通过事件循环调度的，不是真正的函数递归调用，调用栈深度始终为 1。

MVVM 是 Model-View-ViewModel 的缩写，是一种将 UI 表现层与业务逻辑层分离的架构模式。三层的职责：Model：数据与业务逻辑，包括数据模型、API 请求、数据校验等View：UI 展示层，负责渲染界面和接收用户交互ViewModel：连接 Model 与 View 的桥梁，通过数据绑定让两者自动同步MVVM 要解决的核心问题是 View 与 Model 之间的直接耦合。在传统 MVC 中，View 可能直接读取 Model 数据，Model 变化后手动通知 View 更新，随着业务增长，Controller 膨胀成 Massive View Controller，View 和 Model 互相引用导致维护困难。MVVM 通过 ViewModel 把两者彻底解耦——View 只依赖 ViewModel，Model 完全不知道 View 的存在，通信通过数据绑定自动完成。Vue 是典型的 MVVM 实践：template 是 View，data/computed 是 Model，Vue 实例充当 ViewModel。通过响应式系统（Vue 2 的 Object.defineProperty / Vue 3 的 Proxy）拦截数据变化，配合模板编译和虚拟 DOM diff，实现 View 与 Model 的自动同步，开发者不再需要手动操作 DOM。双向绑定的实现原理双向绑定是 MVVM 的核心机制，Vue 的实现分为三个关键部分：数据劫持（Observer）：递归遍历 data 对象，用 Object.defineProperty（Vue 2）或 Proxy（Vue 3）拦截属性的 get/set，每个属性对应一个 Dep（依赖收集器）模板编译（Compiler）：解析模板中的指令（v-model、插值语法、v-bind 等），为每个绑定创建一个 Watcher依赖收集与派发更新（Watcher + Dep）：get 时收集依赖（Watcher 订阅 Dep），set 时通知 Dep 派发更新，Watcher 触发视图重新渲染以 v-model 为例：编译时为 input 元素添加 input 事件监听，用户输入时将值赋给数据属性（View 到 Model）；同时为该属性创建 Watcher，属性变化时更新 input 的 value（Model 到 View），由此形成双向数据流。MVVM 与 MVC、MVP 的区别| 对比项 | MVC | MVP | MVVM ||--------|-----|-----|------|| 通信方式 | View 和 Model 可直接通信 | View 和 Model 通过 Presenter 通信 | View 和 Model 通过 ViewModel + 数据绑定通信 || 中间层职责 | Controller 处理路由和输入 | Presenter 包含业务逻辑 | ViewModel 暴露视图状态 || View 与 Model 耦合 | 可能直接引用 | 完全解耦 | 完全解耦 || 手动同步 | 需要手动更新 View | Presenter 手动调用 View 接口 | 数据绑定自动同步 || 可测试性 | 较低 | 较高 | 最高（ViewModel 无 UI 依赖） |MVC 适合服务端渲染场景（如 Rails），MVP 适合 Android 早期开发，MVVM 适合数据驱动的 UI 框架（Vue、WPF）。选择哪种模式取决于项目复杂度和框架特性。Vue 严格来说是 MVVM 吗？不完全。尤雨溪明确表示 Vue 受 MVVM 启发但不是严格的 MVVM 实现，原因如下：Model 不是独立层：Vue 的 Model 是普通 JS 对象（data），而非独立的领域模型抽象ViewModel 不是独立可测试层：Vue 实例同时包含响应式数据、生命周期钩子、方法等，与组件耦合提供了 $refs：$refs 允许直接操作 DOM 子组件，打破了 ViewModel 与 View 的隔离原则组件化优先于架构模式：Vue 的核心思想是组件化组合而非严格的分层架构所以 Vue 更准确的定位是响应式组件化框架，MVVM 只是它的灵感来源和教学标签。为什么现在新框架很少强调 MVVM 了？因为框架的竞争维度变了：2012-2016 年：框架竞争点是架构模式——AngularJS 推 MVC，Knockout 推 MVVM，Backbone 推 MVP，开发者需要被教怎么组织代码2016 年至今：架构模式已成共识，竞争点转向组件化、响应式粒度、编译优化、开发体验。React Hooks 让函数式组件替代 Class，Vue 3 Composition API 让逻辑复用更灵活，Svelte 用编译时抹掉运行时MVVM 作为概念依然存在（数据绑定仍是所有现代框架的基石），但不再是框架的卖点，而成了底层实现细节。面试中被问到时，重点是理解其解决耦合问题的思路，而非背诵定义。追问MVVM 的缺点是什么？调试困难：数据绑定是隐式的，数据流向不如命令式代码直观，Bug 定位需要追踪绑定链路内存开销：每个绑定都创建 Watcher，大量绑定会占用更多内存过度绑定风险：双向绑定容易导致数据流混乱，特别是跨组件通信时状态变更难以追溯不适合简单 UI：对于静态展示页面，引入 MVVM 框架是过度设计Vue 3 为什么从 Object.defineProperty 改用 Proxy？Object.defineProperty 有三个缺陷：无法监听属性的新增和删除（所以 Vue 2 需要 Vue.set / Vue.delete）无法监听数组索引和 length 变化（Vue 2 通过重写数组方法修补）需要递归遍历对象的每个属性，初始化性能差Proxy 可以代理整个对象，一次性解决以上所有问题，且是惰性响应式（只在访问时才递归代理子对象），初始化性能更好。这也是 Vue 3 大型项目性能提升的关键因素之一。面试中如何简洁地回答什么是 MVVM？三句话结构：MVVM 是 Model-View-ViewModel 架构模式，通过 ViewModel 的数据绑定让 View 和 Model 自动同步它解决了传统 MVC 中 View 和 Model 直接耦合的问题，用 ViewModel 把两者彻底解耦Vue 是典型实践，通过响应式系统拦截数据变化配合模板编译实现双向绑定，但 Vue 并非严格 MVVM（有 $refs 等例外）

bind 是 JavaScript 中显式绑定 this 的三种方式之一，与 call、apply 不同，bind 不会立即执行函数，而是返回一个绑定了 this 和预设参数的新函数。面试中考察 bind 的实现，重点在于：this 绑定、参数柯里化、new 调用兼容、原型链维护。最简实现：绑定 this + 预设参数bind 的核心行为只有两件事：绑定 this 上下文，预设部分参数。Function.prototype.myBind = function(context, ...args) { const fn = this; return function(...newArgs) { return fn.apply(context, [...args, ...newArgs]); };};这段代码保存了原函数引用 fn，返回的新函数在调用时将预设参数 args 和新传入参数 newArgs 合并，通过 apply 将 this 绑定到 context 执行。验证：const obj = { name: 'Alice' };function greet(greeting, punctuation) { return `${greeting}, ${this.name}${punctuation}`;}const bound = greet.myBind(obj, 'Hello');console.log(bound('!')); // "Hello, Alice!"兼容 new 调用上面的实现在 new bound() 时会出错——new 创建的实例本应作为 this，但被 bind 的 context 覆盖了。bind 的规范要求：new 的优先级高于 bind 绑定的 this。Function.prototype.myBind = function(context, ...args) { const fn = this; return function bound(...newArgs) { // new 调用时 this instanceof bound 为 true，应使用 new 创建的实例 return fn.apply( this instanceof bound ? this : context, [...args, ...newArgs] ); };};this instanceof bound 是判断是否通过 new 调用的关键：当 new bound() 执行时，this 指向新创建的实例对象，该实例的原型链上有 bound.prototype，因此 instanceof 返回 true。验证：function Person(name) { this.name = name;}const BoundPerson = Person.myBind({ name: 'ignored' });const p = new BoundPerson('Bob');console.log(p.name); // "Bob"，而非 "ignored"维护原型链上面的实现仍有一个问题：通过 new bound() 创建的实例无法访问原函数原型上的属性和方法。Person.prototype.sayHi = function() { return `Hi, I'm ${this.name}`;};const p2 = new BoundPerson('Carol');console.log(p2.sayHi()); // TypeError: p2.sayHi is not a function原因是 bound 函数的 prototype 并没有指向 fn.prototype。需要用一个空对象作为桥接：Function.prototype.myBind = function(context, ...args) { if (typeof this !== 'function') { throw new TypeError('Bind must be called on a function'); } const fn = this; const fNOP = function() {}; const bound = function(...newArgs) { return fn.apply( this instanceof bound ? this : context, [...args, ...newArgs] ); }; // 维护原型链：让 bound 的实例能访问原函数的原型 fNOP.prototype = fn.prototype; bound.prototype = new fNOP(); return bound;};为什么用 fNOP 做中介而不是直接 bound.prototype = fn.prototype？因为直接赋值后，修改 bound.prototype 会同步影响 fn.prototype，这不符合预期。中介对象隔断了这种引用关系。验证：const p3 = new BoundPerson('Dave');console.log(p3.sayHi()); // "Hi, I'm Dave"console.log(p3 instanceof Person); // true边界情况与细节this 不是函数时抛出错误原生 bind 在非函数值上调用会抛出 TypeError，实现中应当对齐这一行为，已在上面的完整实现中包含。箭头函数的 bind 无效箭头函数没有自己的 this，其 this 由外层词法作用域决定。对箭头函数调用 bind 虽然不会报错，但绑定的 this 不会生效。const arrow = () => this;const boundArrow = arrow.myBind({ x: 1 });console.log(boundArrow()); // 仍是外层 this，而非 { x: 1 }bind 返回的函数没有 prototype 属性原生 bind 返回的绑定函数 prototype 为 undefined，不能作为构造函数使用（虽然通过 new 仍可调用，但原型链由内部 [[Constructor]] 处理）。这一点在深度追问时需要注意。多次 bind 不会叠加 thisbind 返回的函数内部 this 已固定，再次 bind 无法改变。但预设参数会叠加。function fn(a, b, c) { return [a, b, c]; }const bound1 = fn.bind({ x: 1 }, 1);const bound2 = bound1.bind({ x: 2 }, 2);console.log(bound2(3)); // [1, 2, 3]，this 仍是 { x: 1 }追问bind 返回的函数再用 new 调用会发生什么？new 优先级高于 bind。new 创建的新对象会作为 this，bind 指定的 this 被忽略，但预设参数仍然生效。这是 ES5 规范明确规定的优先级：new > bind > apply/call > 默认绑定。call、apply、bind 三者区别？call(thisArg, arg1, arg2, ...)：逐个传参，立即执行apply(thisArg, [arg1, arg2])：数组传参，立即执行bind(thisArg, arg1, arg2)：预设 this 和参数，返回新函数，不立即执行三者的核心差异在于执行时机和传参方式。实际开发中 bind 常用于事件回调保留上下文，call/apply 常用于借用方法或类数组转数组。为什么要用 fNOP 做中介而不是直接赋值 prototype？直接 bound.prototype = fn.prototype 会导致两者引用同一个对象，后续对 bound.prototype 的修改（如添加属性）会污染原函数的原型。fNOP 中介创建了一个以 fn.prototype 为原型的新对象，既保证 instanceof 正确，又隔离了修改影响。

前端删除 Cookie 的核心思路是让浏览器判定它已过期，浏览器会在下次清理时自动移除。JavaScript 没有原生的 deleteCookie API，只能通过 document.cookie 重新设置同名 Cookie 来"覆盖"并使其失效。方法一：设置 expires 为过去时间document.cookie = 'key=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/';这是最经典的做法，兼容所有浏览器。expires 接收一个 HTTP 日期格式的字符串，只要时间早于当前时间，浏览器就会删除该 Cookie。方法二：设置 max-age 为 0document.cookie = 'key=; max-age=0; path=/';max-age 是 HTTP/1.1 的属性，单位为秒。设为 0 表示立即过期。现代浏览器优先使用 max-age，当 expires 和 max-age 同时存在时，max-age 优先生效。IE9 以下不支持 max-age，但这类浏览器已基本退出市场。删除失败的常见原因这是面试中最容易踩坑的地方，也是区分"背答案"和"真正理解"的分水岭。path 和 domain 必须匹配Cookie 的唯一标识是 name + domain + path 三元组。删除时这三项必须与原 Cookie 完全一致，否则浏览器会创建一个新 Cookie 而非删除旧的：// 原 Cookie 设置时指定了 path=/ 和 domain=.example.com// 删除时也必须带上相同的 path 和 domaindocument.cookie = 'key=; max-age=0; path=/; domain=.example.com';// 错误示例：漏掉 path，默认使用当前路径（如 /user）// 这会在 /user 下创建一个新 Cookie，原来的 Cookie 仍在document.cookie = 'key=; max-age=0'; // 删除失败面试中经常追问：如果不指定 path，默认值是什么？ 答案是当前页面的路径（location.pathname），不是 /。这是很多人删除 Cookie 失败的首要原因。HttpOnly 的 Cookie 前端无法删除HttpOnly 标记的 Cookie 对 JavaScript 完全不可见，document.cookie 读取不到，自然也无法删除。只能由服务端通过 Set-Cookie 响应头来删除：Set-Cookie: key=; max-age=0; path=/; HttpOnly子域名与父域名的权限隔离浏览器的安全策略规定：子域名页面无法删除父域名设置的 Cookie。如果 Cookie 的 domain 是 .example.com，在 sub.example.com 页面上删除时必须指定 domain=.example.com：// 在 sub.example.com 页面执行document.cookie = 'key=; max-age=0; path=/; domain=.example.com';反过来，父域名页面也无法删除子域名专属的 Cookie（即 domain 设为 sub.example.com 的 Cookie）。这是浏览器的域隔离机制，防止跨域篡改。服务端删除 Cookie当 Cookie 设置了 HttpOnly 或者需要确保一定删除成功时，应该由服务端通过 Set-Cookie 响应头操作：// Node.js / Express 示例res.setHeader('Set-Cookie', 'key=; max-age=0; path=/; HttpOnly; Secure; SameSite=Lax');服务端删除的好处是可以操作所有属性的 Cookie，包括 HttpOnly 和 Secure 标记的。退出登录场景通常由后端统一清除认证 Cookie，前端只负责跳转。批量删除当前域所有 Cookie实际开发中有时需要清除当前域名下所有 Cookie（如退出登录、切换账号）：function clearAllCookies() { const cookies = document.cookie.split(';'); for (const cookie of cookies) { const name = cookie.split('=')[0].trim(); // 尝试多种 path 组合，确保能匹配到 document.cookie = `${name}=; max-age=0; path=/`; document.cookie = `${name}=; max-age=0`; }}注意这个方法只能删除非 HttpOnly 的 Cookie，且如果 Cookie 设置了特定 domain，单纯遍历 document.cookie 是拿不到 domain 信息的，可能删不干净。追问Secure Cookie 前端能操作吗？HTTPS 环境下可以。Secure 属性只限制传输层面——Cookie 不会随 HTTP（非加密）请求发送，但 document.cookie 的读写是 JavaScript 层面的操作，与传输协议无关。在 HTTPS 页面上，JS 可以正常读取和删除带 Secure 的 Cookie。SameSite 属性对删除有影响吗？没有。SameSite 控制的是 Cookie 在跨站请求中是否发送（防 CSRF），不影响 JS 对 Cookie 的删除操作。删除时不需要指定 SameSite 属性。但需要注意：Chrome 80+ 将未设置 SameSite 的 Cookie 默认视为 Lax，这影响的是请求发送行为，与删除无关。会话 Cookie（Session Cookie）怎么删除？会话 Cookie 没有设置 expires 或 max-age，浏览器关闭后自动消失。但如果想在当前会话中主动删除它，方法一样——设置 max-age=0 或 expires 为过去时间即可。会话 Cookie 和持久化 Cookie 的删除方式没有区别。删除 Cookie 时 value 要留空吗？推荐留空但不强制。document.cookie = 'key=; max-age=0' 和 document.cookie = 'key=deleted; max-age=0' 都能删除。留空只是语义更清晰。真正触发删除的是 max-age=0 或过去的 expires，与 value 无关。

核心场景React 组件卸载后，与之关联的副作用如果没有同步清除，就会产生内存泄漏。实际项目中主要分四类：异步操作更新已卸载组件的状态在组件内发起 fetch 请求，组件卸载了请求才回来，此时 setState 会触发 React 的 warning（React 18 下已移除该 warning，但逻辑上的泄漏仍然存在）。setTimeout/setInterval 同理——组件卸载了定时器还在跑，回调里访问了过期的 state 或调用 setState。// 泄漏写法useEffect(() => { fetch('/api/data').then(res => res.json()).then(setData);}, []);// 修复：用 AbortController 取消请求useEffect(() => { const controller = new AbortController(); fetch('/api/data', { signal: controller.signal }) .then(res => res.json()) .then(setData) .catch(err => { if (err.name !== 'AbortError') throw err; }); return () => controller.abort();}, []);事件监听未移除在 useEffect 里给 window、document 或 DOM 节点添加了 resize、scroll、keydown 等监听，但 cleanup 里没有 removeEventListener。监听回调持有组件作用域的引用，组件实例无法被 GC 回收。useEffect(() => { const handleResize = () => setWidth(window.innerWidth); window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize);}, []);闭包持有大对象引用useCallback/useMemo/useRef 的闭包里引用了不再需要的大对象（比如接口返回的完整列表、Blob 数据等），只要闭包还在，这些对象就无法被回收。常见于列表页缓存整个数据集却只展示部分。// 泄漏：闭包引用了全量数据const filteredList = useMemo(() => largeList.filter(fn), [largeList]);// 优化：只保留需要的字段，尽早释放原引用const filteredList = useMemo( () => largeList.map(item => ({ id: item.id, name: item.name })).filter(fn), [largeList]);未清理的订阅与第三方实例WebSocket、EventSource、IntersectionObserver、ResizeObserver、MutationObserver 这些 API 都需要手动 close()/disconnect()。第三方库（如 Redux 的 subscribe、RxJS 的 Observable.subscribe、ECharts 实例）同理，组件卸载时必须调用对应的销毁方法。useEffect(() => { const ws = new WebSocket('wss://example.com'); ws.onmessage = (e) => setMessage(JSON.parse(e.data)); return () => ws.close();}, []);修复思路核心原则：useEffect 的 setup 和 cleanup 必须对称——setup 里获取了什么资源，cleanup 里就要释放什么。具体做法：异步请求用 AbortController 取消定时器用 clearTimeout/clearInterval 清除DOM 事件用 removeEventListener 移除订阅类 API 调用 close()/disconnect()/unsubscribe()大对象引用用 useRef 配合手动置 null 释放追问useEffect 的 cleanup 什么时候执行？组件卸载时，或者下一次 effect 执行前（依赖项变化时先跑旧 cleanup 再跑新 effect）。React 18 StrictMode 下开发模式会额外执行一次 setup+cleanup 来暴露遗漏的清理逻辑。怎么排查 React 内存泄漏？Chrome DevTools → Memory 面板 → 取 Heap Snapshot。操作组件（挂载→卸载→挂载→卸载），对比两次 snapshot。如果 Detached DOM 节点或组件实例数量持续上升，说明有泄漏。也可以用 React DevTools Profiler 观察 React 组件树是否出现已卸载组件仍存在的现象。React 18 对内存泄漏有什么影响？React 18 移除了 "Can't perform a React state update on an unmounted component" 的 warning，但泄漏本身并未消失——未清理的闭包引用和事件监听仍然存在。同时 StrictMode 在开发模式下双重挂载组件，更容易暴露 cleanup 遗漏的问题。此外并发特性（Suspense、useTransition）引入了组件挂载-卸载-重新挂载的新生命周期，对 cleanup 的正确性要求更高。

Vue 2 里用一个空 Vue 实例做中央事件通道，组件通过它发事件和听事件：// event-bus.jsimport Vue from 'vue';export const EventBus = new Vue();发送端 EventBus.$emit，接收端 EventBus.$on，销毁前必须 EventBus.$off 解绑——忘了这一步就是内存泄漏。典型场景：登录弹窗成功后通知导航栏更新头像，两个组件隔了好几层，props 传递不现实，EventBus 几行代码搞定。Vue 3 移除了 $on/$off，官方推荐用 mitt 替代，写法几乎一样：import mitt from 'mitt';export const bus = mitt();// 发送bus.emit('login-success', { user: 'xxx' });// 监听bus.on('login-success', handler);// 移除bus.off('login-success', handler);追问Vue 3 为什么移除 $on/$off？Vue 3 的响应式体系更推崇单向数据流和显式状态管理。EventBus 是隐式依赖——组件 A emit 一个事件，组件 B 在哪监听的完全不知道，出了 bug 追踪困难。Vue 团队认为这种模式弊大于利，干脆砍掉。如果确实需要事件模式，mitt 只有 200 字节，功能够用。EventBus 和 Pinia 怎么选？EventBus 适合"通知型"通信——A 告诉 B 发生了什么事，不需要持久化数据。Pinia 适合"状态型"通信——多个组件共享同一份数据，需要 devtools 调试和变更追溯。事件一多就别用 EventBus，散落在各组件里的 on/off 根本理不清，直接上 Pinia。为什么必须 $off？忘了会怎样？组件销毁了但 EventBus 实例还活着，回调引用还在，下次 emit 还会执行——操作一个已销毁组件的 this，轻则报错重则数据错乱。更严重的是 EventBus 持有回调闭包，闭包引用了组件实例，GC 无法回收，这就是内存泄漏。Vue 2 里如果用了箭头函数做 handler，$off 时传引用也解不掉，必须用命名函数。EventBus 事件名冲突怎么办？大型项目里十几个组件各自 emit/on，事件名撞了根本不会报错——只是 A 的数据莫名其妙到了 B。解法：统一在常量文件里定义事件名，禁止硬编码字符串。更好的做法是如果事件超过 5-6 个就别用 EventBus 了，换 Pinia。TypeScript 下 mitt 怎么做类型安全？mitt 支持泛型约束事件 map：type Events = { 'login-success': { user: string }; 'logout': undefined;};const bus = mitt<Events>();bus.emit('login-success', { user: 'xxx' }); // ✓bus.emit('wrong-name', {}); // ✗ 类型报错这样事件名和 payload 类型都有编译期检查，比 Vue 2 的 EventBus 安全得多。