前端

服务端

计算机基础

React Fiber 是 React 框架的一个核心算法重写版本，它是 React 16 版本中引入的。Fiber 架构的主要目标是增强 React 在处理动画、布局、手势等方面的能力，并且让这些任务的执行变得更加平滑，不会引起应用程序的卡顿。这种架构的引入是为了优化渲染过程，使之能够利用浏览器的空闲时间执行，从而提高应用程序的性能并使用户界面更加流畅。

### React Fiber 架构的主要优势有：

1. **增量渲染**：Fiber 架构的主要功能之一是能够将渲染工作拆分成多个小任务，并将这些任务分散到多个帧中。这个特点允许 React 暂停和恢复渲染任务，这种“可中断”的渲染过程意味着主线程可以更响应用户操作，从而提高了应用的性能。

2. **任务优先级**：Fiber 架构可以为更新分配优先级。一些任务（如动画）比其他任务（如数据的后台同步）更为紧急。React Fiber 可以区分这些任务，并且先执行更高优先级的任务，再在空闲时处理低优先级的任务。

3. **更好的错误处理**：Fiber 引入了新的错误边界概念，使得组件能够更好地捕获子组件的错误，并且定义备用 UI，从而提供更好的用户体验。

4. **更平滑的动画和过渡**：由于 React Fiber 可以利用浏览器的空闲时间执行渲染任务，因此可以更平滑地执行动画和过渡，降低了卡顿的可能性。

5. **更好的适配未来的变化**：Fiber 架构为将来 React 框架的可能更新和改变打下了基础，比如并发模式（Concurrent Mode）和 Suspense 等新特性。

### 示例：

**优先级调度**：想象一下一个用 React Fiber 构建的聊天应用。用户正在输入消息，同时应用正在后台同步接收新消息。使用 Fiber 架构，React 可以给用户输入的响应分配更高的优先级，从而保证输入的流畅，而消息同步的任务可以在浏览器空闲时进行，用户体验因此得到提升。

通过这些改进，React Fiber 架构使得开发者可以构建出更加响应快速、用户体验更好的应用程序。

React Fiber 架构是什么？有什么优势？

### 实现二分查找

```python
def binary_search(arr, target):
    left, right = 0, len(arr) - 1
    
    while left <= right:
        mid = left + (right - left) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid - 1
    
    return -1
```

### 分析时间复杂度

二分查找算法的时间复杂度是 O(log n)。下面我将解释为什么是这样的。

二分查找算法的基本思想是在一个有序数组中不断地将搜索区间减半。具体来说，算法从数组的中间元素开始，如果中间元素正好是目标值，则搜索结束；如果目标值大于中间元素，则在数组的右半部分继续搜索；如果目标值小于中间元素，则在数组的左半部分继续搜索。

每次比较都会将搜索区间减半，因此我们可以说在最坏的情况下（即目标值不在数组中或者在数组的末端），算法需要执行的步骤数与数组长度 n 的对数成正比。这是因为每次操作减少一半的搜索空间，那么经过 k 次操作后，数组的大小将是原来的 1/2^k。要找出 k，我们设置 n/(2^k) = 1，并解出 k。通过对数运算，我们得到 k = log2(n)。因此算法的时间复杂度是 O(log n)。

举例来说，假设我们有一个包含 1 到 1024（包含）的数组，我们要查找数字 1024。二分查找会经历以下步骤：

1. 比较中间的数（大约 512），1024 大于它，因此我们去右边的子数组里查找。
2. 再取右子数组的中间数（大约 768），1024 仍然大于它，再次去右边的子数组里查找。
3. 这样的过程会持续进行，每次我们都排除了一半的数字，直到最后找到 1024。

在这个例子中，1024 是2的10次幂，所以我们需要10步来找到正确的数字，这符合我们的 O(log n) 时间复杂度分析。

实现二分查找并分析时间复杂度

### Node.js 的优点

#### 1. 高性能
Node.js 使用 V8 引擎，这是 Google Chrome 的 JavaScript 运行时，它将 JavaScript 代码编译成机器代码。这意味着 Node.js 能够提供高性能的网络应用。由于其非阻塞 I/O 和事件驱动架构，Node.js 特别适合处理大量并发连接，这对于实时应用程序（如游戏、聊天服务）和高流量服务是非常有利的。

#### 2. 单一语言开发
使用 Node.js，开发人员可以使用 JavaScript 编写前端和后端代码。这简化了开发流程，因为只需掌握一种语言和一套代码库即可。这也有助于前后端的高效协作。

#### 3. 强大的生态系统
Node.js 有一个庞大的生态系统，npm（Node.js 包管理器）是世界上最大的软件注册表。开发人员可以轻松地找到和共享各种库和工具，这有助于加快开发速度并减少重复造轮子的需要。

#### 4. 易于学习
由于 JavaScript 是最受欢迎的编程语言之一，许多开发人员已经熟悉它。这使得 Node.js 相对容易学习，尤其是对于那些已经有 JavaScript 经验的前端开发人员。

#### 5. 跨平台
Node.js 可以在多种平台上运行，包括 Windows、macOS、Linux，甚至在 Docker 容器中也能良好运作，这使得它非常灵活。

### Node.js 的缺点

#### 1. 单线程
虽然 Node.js 的单线程模型有助于处理高并发和简化开发，但它也意味着所有 I/O 密集型操作可能会阻塞事件循环，影响应用程序的整体性能。对于计算密集型任务，Node.js 可能不是最佳选择。

#### 2. 不稳定的API
Node.js 核心 API 的频繁变动曾经是一个问题，尽管现在已经相对稳定了。但开发者仍然需要留意 API 变动对项目的影响。

#### 3. 异步编程模型
Node.js 大量依赖异步代码，虽然这有助于提高性能，但也可能导致回调地狱（callback hell），使得代码难以理解和维护。尽管现在有 Promise 和 async/await 这样的解决方案，但对于新手来说，异步编程仍然可能是一个挑战。

#### 4. 性能瓶颈
Node.js 的性能虽然在处理 I/O 密集型任务时很出色，但在 CPU 密集型任务上可能就不那么理想。虽然可以通过创建子进程等方式来缓解这个问题，但这增加了复杂性。

#### 5. 年轻的工具
尽管 npm 生态系统非常庞大，但一些库和工具相对于其他语言的生态系统而言可能还不够成熟。这可能意味着更多的漏洞和不稳定性。

#### 实例
以性能为例，LinkedIn 将其后端服务从 Ruby on Rails 迁移到 Node.js，据报道提升了应用程序的性能，并显著减少了服务器需求。这展示了 Node.js 处理大规模网络服务时的性能优势。

nodejs 的优点和缺点？

HTTP (超文本传输协议)和TCP (传输控制协议)都是网络协议，用于在互联网上发送和接收数据，但它们在网络通信中具有不同的角色。在解释二者的区别之前，请先简要理解每个协议的基本概念。

> HTTP (超文本传输协议)

HTTP是应用层协议，被设计用来获取web服务器上的信息。它基于请求/响应模型，在客户端-服务器编程模型中，HTTP客户端发送请求到服务器，服务器处理这些请求并返回响应。这些请求和响应都以文本形式发送，通常为HTML格式。

> TCP (传输控制协议)

TCP是传输层协议，用于在网络中建立可靠的、有序的和错误检测机制的数据传输通道。TCP通过确认数据包已正确接收并通过流量控制和拥塞控制来保证数据的顺利传输。

> HTTP和TCP之间的主要区别

1. **协议类型**：HTTP是应用层协议，对网络通信的具体应用进行了规范（如在web浏览器和服务器之间如何通信）。而TCP是传输层协议，用于确保数据从发送方到接收方的可靠传输。
2. **连接类型**：HTTP连接是无状态的，这意味着服务器不保存关于客户端请求的任何信息。TCP连接是有状态的，这意味着服务器保存连接状态信息（如发送和接收的数据包）。
3. **数据传递方式**：HTTP用于传输超文本，如HTML文档。TCP在传输层中进行数据传输，这的数据可能来自应用层的各种协议（如HTTP、FTP等）。
4. **数据可靠性**：HTTP依赖于TCP来确保数据的可靠性。实际上，大多数HTTP通信都是通过TCP进行的。
5. **使用场景**：HTTP广泛用于网页请求，包括许多用于数据传输的web服务。而TCP用于许多网络通信场景，包括电子邮件（SMTP、POP、IMAP协议）、文件传输（FTP协议）和web浏览（HTTP）等。


HTTP和TCP的区别

在移动端Web开发中，我们有很多方法可以实现画一条0.5px的线。以下是一些典型的方法：

1. **使用 viewport**

   可以将页面的视口设置为设备宽度的一般，然后布局以这个新的视口宽度为基准进行。当设置 `border-width: 1px` 时，其实际显示出来结果就是物理像素的0.5px。

   ```html
   <meta name="viewport" content="width=device-width,initial-scale=.5, maximum-scale=.5, user-scalable=no">
   <div style="border-bottom: 1px solid #ccc"></div>
   ```
2. **使用 CSS transform 属性**

   这种方法通常适用于大部分场景，主要思路是添加一个 1px 的 border，然后通过 scaleY(.5)/scaleX(.5) 进行缩放。需要注意的是，在利用这种方法画线时，应该以伪元素进行缩放，避免影响容器本身的布局。

   ```html
   <div class="line"></div>
   ```
   ```css
   .line {
       position: relative;
       height: 20px;
   }

   .line::after {
       content: '';
       position: absolute;
       left: 0;
       bottom: 0;
       width: 100%;
       border-bottom: 1px solid #ccc;
       transform: scaleY(.5);
   }
   ```
3. **使用 SVG.** 

   SVG 是一种基于 XML 语法的图像格式，全部是由代码生成，所以可以精确到0.5px。具体实现就是改变SVG中的 `stroke-width`属性。

   ```html
   <svg width="100%" height="1" version="1.1" xmlns="http://www.w3.org/2000/svg">
       <line x1="0" y1="0" x2="375" y2="0" stroke="#000" stroke-width="0.5" />
   </svg>
   ```
4. **使用 Canvas**

   canvas 的API为我们提供了更底层的画图能力，同样能实现这个需要。

   ```html
   <canvas id="canvas"></canvas>

   <script>
     var canvas = document.getElementById('canvas');
     var ctx = canvas.getContext('2d');
     ctx.beginPath();
     ctx.moveTo(0, 0);
     ctx.lineTo(300, 0);
     ctx.lineWidth = 0.5;
     ctx.stroke();
   </script>
   ```


移动端Web如何画一条 0.5px 的线

事件总线是一种模式，可以通过一个中央通道分发事件，让不同的系统部分实现解耦。在Vue.js中，事件总线通常是通过一个空的Vue实例来实现的。 

以下是我如何在Vue项目中实现一个事件总线，以及我可能会用到它的一个场景：

### 实现事件总线

1. 创建事件总线：

```javascript
// event-bus.js
import Vue from 'vue';
export const EventBus = new Vue();
```

2. 在组件中使用事件总线：

**发射事件**:

```javascript
// 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>
```

**监听事件**:

```javascript
// 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`来在组件间共享状态。

结合 Vue 项目实现事件总线 Event Bug

### 什么是 JS Bridge？

JS Bridge，即JavaScript Bridge，是一种在不同环境或者平台之间进行通信的技术，尤其是在Web视图（如WebView）中嵌入的JavaScript与宿主应用（通常是移动应用）之间的通信桥梁。通过JS Bridge，可以使得原生应用可以调用JavaScript代码，JavaScript代码也能调用原生应用的API，从而实现混合开发，充分利用原生应用的性能优势与Web技术的灵活性。

### JSB 有哪些实现方式？

实现JS Bridge的方式通常取决于所使用的平台和具体的需求，以下是一些常见的实现方式：

1. **URL Scheme：**
   这是一种较为简单的实现方式。原生应用可以通过拦截WebView中的URL跳转请求来实现与JavaScript的通信。当JavaScript需要与原生应用通信时，它会尝试跳转到一个特殊的URL（如 `myscheme://someaction?param1=value1`），原生应用拦截这个URL请求，并解析出相应的行为和参数，然后执行相应的原生代码。
2. **注入API对象：**
   通过原生代码将一些对象或者方法注入到WebView中的JavaScript环境里。Injected API可以直接在JavaScript代码中被调用，从而实现JavaScript对原生功能的调用。这种方式可以提供更加丰富和直接的接口给JavaScript。
3. **消息通道（如postMessage）：**
   现代的Web视图组件（如iOS中的WKWebView）支持使用类似于HTML5中定义的 `postMessage` API的消息通道，可以实现双向通信。JavaScript可以通过这个API发送消息给原生代码，并且原生代码也可以返回消息给JavaScript。
4. **Native Modules：**
   在一些JavaScript框架中，如React Native，可以创建特定的Native Modules来扩展原生应用的功能。这些模块可以被JavaScript代码直接调用，原生代码也可以向JavaScript环境发送事件。

#### 示例：

假设我们需要实现一个简单的功能，让WebView中的JavaScript能够打开原生应用的摄像头并拍照。使用URL Scheme的方式实现可能如下：

在JavaScript中，你可能会有这样的调用代码：

```javascript
function openNativeCamera() {
  window.location.href = 'myapp://camera/open';
}
```

在原生应用中（以iOS为例），你可能需要实现如下的拦截逻辑：

```objective-c
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType {
  NSURL *URL = [request URL];
  if ([[URL scheme] isEqualToString:@"myapp"]) {
    if ([[URL host] isEqualToString:@"camera"] && [[URL path] isEqualToString:@"/open"]) {
      // 调用原生摄像头的代码
      [self openCamera];
      return NO;
    }
  }
  return YES;
}

- (void)openCamera {
  // 打开摄像头的逻辑
}
```

以上示例展示了如何通过URL Scheme拦截WebView中的跳转来调用原生功能。其他实现方式会有不同的代码示例，但核心思想都是建立一个通信通道，让JavaScript与原生代码能够互相调用。


什么是 js bridge？jsb 有哪些实现方式？

AMD（Asynchronous Module Definition）和CommonJS是两种流行的JavaScript模块化规范，它们都被设计来允许代码分割成可重用的模块。但是，它们在模块定义、加载机制和使用场景上有所不同。

### AMD（Asynchronous Module Definition）

**主要特点：**
- **异步加载：** AMD被设计用于浏览器环境，可以异步加载模块，不会阻塞页面渲染。
- **定义模块：** 使用`define`函数定义模块，可以显式声明依赖，并在所有依赖加载完成后运行模块的工厂函数。
- **依赖前置：** 依赖需要在模块开始加载之前声明，这样可以并行加载依赖。
  
**示例：**
```javascript
define(['dependency1', 'dependency2'], function (dep1, dep2) {
    // 定义模块内容
    var moduleName = function () {
        // 一些功能
    };
    return moduleName;
});
```

**实现库：** RequireJS 是最著名的实现AMD规范的库。

### CommonJS

**主要特点：**
- **同步加载：** CommonJS被设计用于服务器环境，如Node.js，通常假设模块是在本地文件系统中，因此可以同步加载，不会造成浏览器卡顿。
- **定义模块：** 使用`exports`对象或`module.exports`定义模块的对外接口。
- **后置依赖：** 依赖关系通常是在模块的代码体内通过`require`调用来声明的。

**示例：**
```javascript
var dep1 = require('dependency1');
var dep2 = require('dependency2');

function moduleName() {
    // 一些功能
}

module.exports = moduleName;
```

**实现环境：** Node.js 原生支持CommonJS模块规范。

### 总结区别

- **加载方式**：AMD为异步加载，适合浏览器环境；CommonJS为同步加载，适合服务器环境如Node.js。
- **定义模块**：AMD使用`define`方法，CommonJS使用`exports`或`module.exports`。
- **依赖声明**：AMD的依赖声明是前置的，而CommonJS依赖通常在需要时才声明。
- **实现和适用环境**：AMD的典型实现是RequireJS，主要用在浏览器端；CommonJS的实现是Node.js的模块系统，主要用在服务器端。

在实际应用中，如果是开发面向浏览器的应用，并且需要异步加载模块，可能会倾向于使用AMD规范。如果是开发Node.js服务器端应用，CommonJS会是一种更加自然的选择。现代开发中，也有越来越多的工具和语法（如ES6模块）被用来跨越这两种规范的限制，实现更统一的模块化开发体验。

AMD 和 Commonjs 的区别是什么？

XSS攻击，全称是跨站脚本攻击（Cross-Site Scripting），它是一种网站应用程序的安全漏洞攻击，攻击者通过这种方式可以在用户浏览器端执行恶意脚本。这些恶意脚本一旦在用户浏览器上运行，就可以窃取用户信息、篡改网站内容、无意间欺骗用户执行某些操作等。

XSS攻击通常分为三种类型：

1. 存储型XSS（Persistent XSS）：恶意脚本被永久存储在目标服务器，如数据库、消息论坛、访客留言等地方。当用户浏览相关页面时，恶意脚本就会被执行。例如，攻击者在社交媒体网站上发表带有恶意JavaScript代码的评论，当其他用户查看该评论时，此脚本便会在他们的浏览器上执行。
2. 反射型XSS（Reflected XSS）：恶意脚本不会被存储在服务器上，它是通过诸如URL、电子邮件、即时消息等传达给用户的，用户点击链接后，由服务器动态生成带有攻击代码的页面返回给用户，恶意脚本随即在用户浏览器上执行。比如一个搜索引擎的搜索结果页面包括了用户输入的搜索关键词，如果这个关键词没有被恰当地处理，攻击者可以构造一个特殊的URL，当用户点击这个链接时，搜索关键词处的恶意脚本就会执行。
3. DOM型XSS（DOM-based XSS）：这种类型的攻击中，恶意代码并没有直接在服务器的响应中反映出来，而是在页面已经加载到用户浏览器后，由于DOM环境中的数据流动不安全，攻击脚本得以在客户端运行。例如，一个网页根据URL的参数来决定内容展示，如果没有对参数进行合适的处理，攻击者可以修改URL参数，使页面执行恶意脚本。

防御XSS攻击的常用方法包括：

- 对用户输入进行验证和过滤，避免直接输出未经处理的用户输入。
- 使用HTTP-only Cookie，防止JavaScript访问敏感Cookie。
- 实施内容安全策略（CSP），限制页面可以加载和执行的资源类型和来源。
- 对重要的操作使用CSRF令牌，确保请求是由用户自愿发起的。

以上就是XSS攻击的概述和防御策略。


什么是XSS攻击？

CRSF攻击，全称是跨站请求伪造（Cross-Site Request Forgery），是一种网络攻击方式，它允许攻击者在用户不知情的情况下，以该用户的身份执行非授权的命令或更改用户账户信息。CRSF攻击通常利用用户已经认证的身份，例如在网站的认证机制中，用户通常通过输入密码等方式登录之后，会获得一个认证标记（如Cookie），后续的操作就不需要重复进行身份认证。

CRSF攻击的典型场景如下：

1. 用户登录到银行网站，并在浏览器中保存了登录凭证（如Cookie）。
2. 在不退出银行网站的情况下，用户在另一个标签页中访问了一个恶意网站。
3. 恶意网站包含了一个指向银行网站的请求（例如，一个图片的链接或一个自动提交的表单），这个请求中包含了转账操作的命令。
4. 当用户的浏览器加载恶意网站时，此请求被发出，并且由于用户在银行网站上已经登录，请求中携带了用户的认证凭证。
5. 银行网站接收到请求后，误认为是用户自愿发起的操作，从而执行了转账。

这种攻击的危险之处在于，用户完全不知情，而攻击者却可以执行诸如转账、密码更改、购买商品等操作。如果网站没有适当的防御机制，CSRF攻击可以对用户造成重大的财务或数据损失。

防御CSRF攻击的常见措施包括：

- 使用Anti-CSRF Token：服务器生成一个随机的、不可预测的token，并在每次敏感操作请求时要求客户端提交这个token，服务器验证此token后才执行操作。
- 双重验证：对于重要操作，要求用户重新输入密码或进行其他形式的认证。
- 设置Cookie的SameSite属性：通过设置Cookie的SameSite属性为Strict或Lax，可以限制Cookie不随跨站请求发送，从而减少CSRF攻击的风险。
- 检查Referer和Origin头：服务器可以通过检查HTTP请求头部的Referer或Origin来验证请求的合法性。

以上就是对CSRF攻击的简要说明以及如何防御这类攻击的方法。

面试题手册