前端面试题手册

事件总线是一种模式，可以通过一个中央通道分发事件，让不同的系统部分实现解耦。在Vue.js中，事件总线通常是通过一个空的Vue实例来实现的。 以下是我如何在Vue项目中实现一个事件总线，以及我可能会用到它的一个场景：实现事件总线创建事件总线：// event-bus.jsimport Vue from 'vue';export const EventBus = new Vue();在组件中使用事件总线：发射事件:// ComponentA.vue<template> <!-- 组件模板 --></template><script>import { EventBus } from './event-bus.js';export default { methods: { someMethod() { EventBus.$emit('my-event', { someData: 'Some data to send' }); } }}</script>监听事件:// ComponentB.vue<template> <!-- 组件模板 --></template><script>import { EventBus } from './event-bus.js';export default { mounted() { EventBus.$on('my-event', this.handleMyEvent); }, beforeDestroy() { EventBus.$off('my-event', this.handleMyEvent); }, methods: { handleMyEvent(payload) { console.log('Event received', payload); // 处理事件 } }}</script>在这个例子中，ComponentA 发射了一个事件 my-event，并传递了一些数据。ComponentB 监听这个事件，并定义了一个方法 handleMyEvent 来处理接收到的事件。例子：事件总线的使用场景假设我们有一个应用，其中有一个组件负责用户的认证（例如登录状态的显示），而另一个组件是一个模态框，用于登录。这两个组件位于不同的层级，也可能不直接相关。我们不希望在每个需要知道登录状态的组件中都直接与模态框组件通信，因为这会导致高耦合和难以维护的代码。在这种情况下，事件总线就派上了用场：当用户在模态框中登录成功后，模态框组件可以发射一个事件，比如 login-success。认证组件可以监听 login-success 事件，并据此更新用户的显示状态。这样，我们就可以保持组件间的解耦，同时使它们能够有效地沟通。注意事项Vue 2.x中支持使用 $on, $emit, 和 $off 这样的实例方法来实现事件总线。然而，在Vue 3.x中，这种模式已经不再推荐，因为它违背了Vue 3推崇的Composition API的设计原则。在Vue 3中，推荐使用 provide/inject、Vuex或者Vue Composition API中的 reactive、ref以及 watchEffect来在组件间共享状态。

XSS攻击，全称是跨站脚本攻击（Cross-Site Scripting），它是一种网站应用程序的安全漏洞攻击，攻击者通过这种方式可以在用户浏览器端执行恶意脚本。这些恶意脚本一旦在用户浏览器上运行，就可以窃取用户信息、篡改网站内容、无意间欺骗用户执行某些操作等。XSS攻击通常分为三种类型：存储型XSS（Persistent XSS）：恶意脚本被永久存储在目标服务器，如数据库、消息论坛、访客留言等地方。当用户浏览相关页面时，恶意脚本就会被执行。例如，攻击者在社交媒体网站上发表带有恶意JavaScript代码的评论，当其他用户查看该评论时，此脚本便会在他们的浏览器上执行。反射型XSS（Reflected XSS）：恶意脚本不会被存储在服务器上，它是通过诸如URL、电子邮件、即时消息等传达给用户的，用户点击链接后，由服务器动态生成带有攻击代码的页面返回给用户，恶意脚本随即在用户浏览器上执行。比如一个搜索引擎的搜索结果页面包括了用户输入的搜索关键词，如果这个关键词没有被恰当地处理，攻击者可以构造一个特殊的URL，当用户点击这个链接时，搜索关键词处的恶意脚本就会执行。DOM型XSS（DOM-based XSS）：这种类型的攻击中，恶意代码并没有直接在服务器的响应中反映出来，而是在页面已经加载到用户浏览器后，由于DOM环境中的数据流动不安全，攻击脚本得以在客户端运行。例如，一个网页根据URL的参数来决定内容展示，如果没有对参数进行合适的处理，攻击者可以修改URL参数，使页面执行恶意脚本。防御XSS攻击的常用方法包括：对用户输入进行验证和过滤，避免直接输出未经处理的用户输入。使用HTTP-only Cookie，防止JavaScript访问敏感Cookie。实施内容安全策略（CSP），限制页面可以加载和执行的资源类型和来源。对重要的操作使用CSRF令牌，确保请求是由用户自愿发起的。以上就是XSS攻击的概述和防御策略。

CRSF攻击，全称是跨站请求伪造（Cross-Site Request Forgery），是一种网络攻击方式，它允许攻击者在用户不知情的情况下，以该用户的身份执行非授权的命令或更改用户账户信息。CRSF攻击通常利用用户已经认证的身份，例如在网站的认证机制中，用户通常通过输入密码等方式登录之后，会获得一个认证标记（如Cookie），后续的操作就不需要重复进行身份认证。CRSF攻击的典型场景如下：用户登录到银行网站，并在浏览器中保存了登录凭证（如Cookie）。在不退出银行网站的情况下，用户在另一个标签页中访问了一个恶意网站。恶意网站包含了一个指向银行网站的请求（例如，一个图片的链接或一个自动提交的表单），这个请求中包含了转账操作的命令。当用户的浏览器加载恶意网站时，此请求被发出，并且由于用户在银行网站上已经登录，请求中携带了用户的认证凭证。银行网站接收到请求后，误认为是用户自愿发起的操作，从而执行了转账。这种攻击的危险之处在于，用户完全不知情，而攻击者却可以执行诸如转账、密码更改、购买商品等操作。如果网站没有适当的防御机制，CSRF攻击可以对用户造成重大的财务或数据损失。防御CSRF攻击的常见措施包括：使用Anti-CSRF Token：服务器生成一个随机的、不可预测的token，并在每次敏感操作请求时要求客户端提交这个token，服务器验证此token后才执行操作。双重验证：对于重要操作，要求用户重新输入密码或进行其他形式的认证。设置Cookie的SameSite属性：通过设置Cookie的SameSite属性为Strict或Lax，可以限制Cookie不随跨站请求发送，从而减少CSRF攻击的风险。检查Referer和Origin头：服务器可以通过检查HTTP请求头部的Referer或Origin来验证请求的合法性。以上就是对CSRF攻击的简要说明以及如何防御这类攻击的方法。

Object.defineProperty 方法是 JavaScript 中的一个非常重要的方法，它允许精确地添加或修改对象的属性。通过这个方法，我们可以控制属性的各种特性，如它们是否可写、可枚举或可配置，甚至定义存取器属性（getter 和 setter）。Object.defineProperty 方法接受三个参数：要在其上定义属性的对象。将被定义或修改的属性的名称。描述符对象，它定义了属性的具体行为和特征。属性描述符对象可以包含以下键：value：属性的值。writable：如果为 true，则属性的值可以被重写。configurable：如果为 true，则该属性的描述符可以被改变，也可以从对象上删除该属性。enumerable：如果为 true，则该属性会出现在对象的枚举属性中。get：作为属性的 getter 函数，当访问属性时触发。set：作为属性的 setter 函数，当属性值被修改时触发。以下是一个使用 Object.defineProperty 的例子：const person = {};Object.defineProperty(person, 'name', { value: '张三', writable: false, enumerable: true, configurable: true});console.log(person.name); // 输出 '张三'person.name = '李四'; // 由于 writable 是 false，这里的赋值操作不会成功console.log(person.name); // 仍然输出 '张三'在上面的例子中，我们定义了一个对象 person 并使用 Object.defineProperty 给它添加了一个名为 name 的属性。这个属性被设置为不可写，所以尝试更改它的值将不会有任何效果。需要用到 Object.defineProperty 的情况包括：控制属性特性：当你需要精细地控制一个对象属性的可枚举性、可配置性、可写性等。创建只读属性：当你希望对象的某些属性是只读的，不允许修改。定义存取器属性：如果你想通过 getter 和 setter 控制属性的访问和赋值。保护对象结构：在对象创建后保护其结构不被意外改变，比如防止属性被删除。这些特性使得 Object.defineProperty 成为在创建具有特定行为的对象属性时非常有用的工具，特别是在模块和库的开发中，我们经常需要确保对象的接口行为符合预期，防止意外的修改。

JavaScript 中的定时器包括 setTimeout 和 setInterval，这两个函数通常用于延迟执行或定期执行某些代码。但是，它们的执行时间并不精确，原因主要有以下几点：单线程和事件循环：JavaScript 是单线程执行的，它依赖于事件循环来处理异步事件。当你设置一个定时器时，你实际上是告诉事件循环在未来的某个时间点上执行一段代码。但是，如果事件循环在处理其他任务时被阻塞，例如执行一个耗时的同步操作，那么定时器的代码执行将会被推迟直到主线程空闲为止。Web 浏览器的定时器分辨率：出于性能和节能的考虑，Web 浏览器的定时器分辨率不会非常高。这意味着定时器的回调函数可能不会在预期的精确毫秒数后立即执行。不同的浏览器和不同的环境（比如浏览器后台运行或系统睡眠）可能会对定时器的精度有不同的影响。最小延迟时间：在 HTML5 标准中，规定了 setTimeout 和 setInterval 的最小延迟时间通常不得低于4ms（若之前调用了5次以上的定时器，则最小延迟10ms）。这意味着即使你请求更短的时间间隔，执行也会被推迟到这个最小值。浏览器标签页的背景化：当用户将包含JavaScript定时器的浏览器标签页置于后台时，大多数现代浏览器会减少定时器的执行频率以节约资源和电池寿命。这可能导致后台标签页中的定时器变得非常不精确。垃圾回收：JavaScript的垃圾回收机制可能会暂时阻塞主线程，从而延迟定时器的执行。例如，假设你有一个使用 setTimeout 指定在10ms后执行的回调函数，但是此时主线程正在处理一个复杂的计算任务，这可能需要100ms才能完成。在这种情况下，即使定时器的时间到了，回调函数也必须等到计算任务完成后，事件循环才能调用它。所以实际上回调函数的执行时间将晚于预期的10ms。综上所述，由于单线程的特性、事件循环的机制、Web浏览器的实现细节和环境限制，JavaScript定时器的执行时间就不能保证绝对精确。开发者在使用定时器时，应该考虑到这些因素，并且不应该依赖定时器来进行精确的时间控制。

内存泄露通常是指在程序运行过程中，分配的内存未能及时释放，导致随着时间的推移，系统可用内存逐渐减少。当我们在JavaScript中处理原生DOM事件时，如果不正确移除这些事件监听器，很容易导致内存泄露。在详细解释原因之前，先来了解一下事件监听器和内存泄露的基本概念。事件监听器是我们绑定到DOM元素上的函数，用来响应特定的事件，比如点击或者键盘按键。而内存泄露则是指已经不再需要的内存，由于各种原因，没有被及时回收，使得应用程序占用的内存越来越多。现在，让我说明为什么不移除原生事件监听器会导致内存泄露：事件监听器与DOM元素的引用关系：当你给一个DOM元素添加事件监听器时，浏览器会创建一个引用，指向该监听器的函数。即使你从DOM树中移除了这个元素，如果事件监听器没有被移除，那么浏览器的事件处理系统仍然会保留一个对该函数的引用，这导致了DOM元素和监听器函数无法被垃圾回收机制回收，因为从技术上讲，它们依旧是可达的。闭包：在JavaScript中，闭包是一个常见的功能，它允许函数访问并操纵函数外部的变量。如果事件监听器是一个闭包，它可能会引用其他外部变量或对象。只要这个监听器存在，所有它引用的对象也都无法被回收，即使这些对象已经没有其他用途。复杂的引用链：在大型的web应用程序中，DOM元素、事件监听器、以及其他相关对象可能会构成复杂的引用链。这些引用链使得垃圾回收变得复杂，如果链中的某一部分没有被正确管理和解除引用，就可能导致整个链条上的对象都不能被回收。让我举一个例子来说明这个问题：假设我们有一个简单的网页应用，它有一个按钮，当用户点击时会弹出一个警告框：function setup() { var button = document.getElementById('myButton'); button.addEventListener('click', function handleClick() { alert('Button clicked!'); });}setup();如果我们某个时刻决定移除这个按钮：var button = document.getElementById('myButton');button.remove();虽然DOM元素被移除了，但是我们没有移除与之绑定的handleClick事件监听器。这意味着handleClick依然保留着对button元素的引用，因此即使我们从DOM中移除了这个元素，它也不会被垃圾回收。如果我们的应用中有很多这样的操作，随着时间的推移，内存消耗将不断增加，这就是内存泄露。解决这个问题的一个方法是在移除DOM元素之前，显式地移除事件监听器：var button = document.getElementById('myButton');button.removeEventListener('click', handleClick);button.remove();这样，我们就手动断开了事件监听器与DOM元素之间的引用关系，使得这些对象可以被垃圾回收。这是为什么在处理原生DOM事件时，开发者需要注意正确地添加和移除事件监听器，以避免不必要的内存

LocalStorage 是 Web Storage API 的一部分，它允许网页在用户浏览器本地存储数据。下面是 LocalStorage 对象常用的 API 方法：setItem(key, value): 该方法用于在 LocalStorage 中存储数据。它接收两个参数，key（键）表示存储数据的名称，而 value（值）则是实际存储的数据。例如：localStorage.setItem('username', 'JohnDoe');getItem(key): 通过 key（键）检索存储在 LocalStorage 中的值。如果指定的键不存在，它将返回 null。例如：let userName = localStorage.getItem('username');console.log(userName); // 输出: JohnDoeremoveItem(key): 删除 LocalStorage 中的指定 key（键）的数据。例如：localStorage.removeItem('username');clear(): 清除 LocalStorage 中的所有数据。例如：localStorage.clear();length: 一个只读属性，返回 LocalStorage 中的数据项数。例如：let numberOfItems = localStorage.length;console.log(numberOfItems);key(index): 根据索引来获取 LocalStorage 中的键。索引从 0 开始。如果索引超出了范围，将返回 null。例如：let firstKeyName = localStorage.key(0);console.log(firstKeyName);LocalStorage 的数据会以字符串的形式存储，即使你存储的是数字或是对象。如果需要存储对象，通常会使用 JSON.stringify 方法将对象转换为字符串格式存储，检索时再用 JSON.parse 方法将字符串转换回对象。例如：let user = { name: 'John', age: 30 };localStorage.setItem('user', JSON.stringify(user));let retrievedUser = JSON.parse(localStorage.getItem('user'));console.log(retrievedUser); // 输出: { name: 'John', age: 30 }以上就是 LocalStorage 对象的主要 API。需要注意的是，虽然 LocalStorage 提供了方便的本地存储机制，但它并不适合存储敏感信息，因为这些信息是以明文形式存储的，且没有到期时间，容易受到跨站脚本（XSS）攻击的影响。

WebP 图片简介：WebP 是一种现代图像格式，由Google在2010年发布。它是一种旨在为网页图像压缩提供优异的压缩比的格式，其目标是减小图像的文件大小，而在视觉上保持高质量。WebP 支持无损压缩和有损压缩，同时还支持透明度（Alpha通道）和动画。WebP 的优势：更小的文件大小： 相较于传统的JPEG和PNG格式，WebP图像通常可以在不牺牲视觉质量的情况下提供更小的文件大小。这意味着更快的加载时间和更低的带宽消耗，这对于移动设备用户和带宽有限的环境尤其重要。支持有损和无损压缩： WebP既可以提供有损压缩以减少文件大小，也可以提供无损压缩来保持图像质量。这使得它比只能提供一种压缩方式的格式更为灵活。支持动画： WebP可以替代传统的GIF格式，提供更优的动画压缩效果，同时文件尺寸比GIF更小。支持透明度： 除了对颜色的压缩外，WebP还支持8位的透明通道，即使是在有损压缩的情况下也能处理透明度，这对于网页设计中的图标和图形元素非常有用。色彩表现： WebP支持广色域，这意味着它能够展现更丰富的颜色和更平滑的色彩过渡。WebP 的缺点：兼容性问题： 尽管WebP的支持正在增加，但一些旧的浏览器和图像编辑软件还不支持WebP格式。这可能导致必须为不同的用户提供不同格式的图片。编辑软件支持有限： 相较于JPEG和PNG，WebP格式在图像编辑软件中的支持较少，可能需要使用特定的工具来编辑或转换这些图像。用户认知： 普通用户可能不熟悉WebP格式，对于需要用户上传图片的网站来说，可能需要额外的工作来确保用户上传的图片是支持的格式。转换成本： 对于已经有大量存量图片的网站，将图片转换为WebP格式可能需要消耗一定的时间和资源。例子：为了说明WebP格式的优势，我们可以考虑一个在线商城。该商城的页面包含了大量的产品图片，如果这些图片使用WebP格式而不是JPEG或PNG，那么页面加载速度可能会显著提高，从而改善用户体验和提升转化率。在一个实际测试中，转换JPEG图片到WebP格式，可能会看到文件大小减少25%以上，而视觉上的差异几乎察觉不到。这对于用户来说意味着更快的加载时间，对于商城运营者来说，则意味着更低的数据传输费用。然而，为了确保所有用户都能正常浏览图片，商城可能需要保留JPEG或PNG格式的备份，以便不支持WebP的浏览器也能显示图片。

移动设备的Android和iOS平台在软键盘弹出的处理方式上确实存在一些差异，主要反映在以下几个方面：1. 视图调整Android:Android平台上，当软键盘弹出时，默认情况下会重新调整活动(Activity)的大小，以确保当前获得焦点的输入字段可见。开发者可以通过设置AndroidManifest.xml中Activity的windowSoftInputMode属性来调整这一行为。例如，adjustResize会调整Activity的大小，而adjustPan会上移整个视图。例子：<activity android:name=".MainActivity" android:windowSoftInputMode="adjustResize"></activity>iOS:在iOS上，软键盘的弹出默认不会引起视图的调整，除非开发者主动编写代码来处理键盘事件。开发者通常需要监听键盘的UIKeyboardWillShow和UIKeyboardWillHide通知，并据此调整视图，比如通过更改底部视图的约束或者滚动视图的contentInset。例子：NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow), name: UIResponder.keyboardWillShowNotification, object: nil)NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillHide), name: UIResponder.keyboardWillHideNotification, object: nil)@objc func keyboardWillShow(notification: NSNotification) { // 调整视图以适应键盘}@objc func keyboardWillHide(notification: NSNotification) { // 恢复视图}2. 第三方键盘支持Android:Android系统在较早时候就开放了对第三方键盘应用的支持，因此Android上的应用需要能够适应多样的键盘布局和行为。iOS:iOS开始对第三方键盘支持是从iOS 8开始的，iOS平台上的应用也需要适应不同的键盘行为，虽然Apple提供了一套相对统一的界面风格。3. 输入法切换Android:Android设备通常会在软键盘上提供一个方便的输入法切换按钮，允许用户快速切换不同的键盘。iOS:iOS设备通常需要用户通过点击全局的键盘切换键或者长按地球标志键来切换输入法。4. API和框架支持Android:Android提供了InputMethodManager等API来管理软键盘的显示和隐藏。iOS:iOS通过UIKit框架中的UITextField、UITextView等组件与键盘进行交互，同时提供了相关的API来控制键盘的行为。5. 软键盘定制Android:Android允许开发者相对更深层次地定制软键盘，例如通过创建自定义输入法编辑器（IME）。iOS:iOS对于键盘的定制性较低，对于标准的键盘行为有着较严格的界面指南。总结：Android和iOS在软键盘弹出的处理方式上体现出的差异主要是由于两个平台的设计哲学和开发者工具的不同。Android提供了更多的自动调整视图的选项和对第三方键盘的支持，而iOS则要求开发者更加主动地管理键盘事件和视图调整。开发者在开发跨平台应用时，需要了解这些差异，并确保提供适合各自平台的用户体验。

防抖（Debouncing）原理：防抖是一种控制方法，用于减少函数调用的频次。具体而言，当一个动作频繁触发时，防抖会确保该函数在指定的时间内只被执行一次。如果在这个延迟时间内再次触发了该动作，计时器会被重置，直到延迟时间结束后，才会执行函数。应用：举个例子，假设你在一个搜索框中键入文本，为了减少请求服务器的次数，你可以利用防抖技术。这意味着用户停止键入一段时间（比如500毫秒）之后，才会发送搜索请求。如果用户在500毫秒内继续输入，计时器会重置，直到用户停止输入后过了500毫秒，才会执行搜索。节流（Throttling）原理：节流是另一种控制方法，它同样用于减少函数调用的频次。与防抖不同的是，节流会强制函数以固定的时间间隔执行。即便动作频繁触发，函数也只会按照这个间隔执行，不会像防抖那样完全等待动作停止。应用：以滚动事件为例，如果我们需要在用户滚动页面时进行一些计算或更新界面元素，不加控制的话可能会导致性能问题。此时我们可以应用节流技术，比如设置每100毫秒执行一次更新操作，无论在这100毫秒内滚动事件被触发了多少次，更新函数都只会执行一次。区别触发频率：防抖函数会在动作结束后才执行，而节流函数会按照预定的频率执行，不管动作是否结束。目的：防抖通常用于确保某些计算密集型或高延迟的任务不会因为用户的高频操作而频繁执行，节流则用于控制函数的执行频率，保持性能的平稳。使用场景：防抖适用于诸如输入框内容自动完成、窗口大小调整（resize）、提交按钮（防止多次提交）等场景。节流适用于滚动加载、用户滚动监听、动画的持续触发等场景。总结来说，防抖和节流都是优化高频事件触发后的回调执行频率的技术。防抖是通过延迟执行来合并频繁的触发，而节流是通过减少执行的频率来降低触发的次数。根据具体的应用场景和需求选择合适的优化策略，可以显著提升应用的性能和用户体验。