今天想到很多内容，想简单写出来，主要是关于今后发展方向的，我从事前端工作2年半左右了，学的东西算是比较多的，但是我想找一个稍微明确的方向，我这里以2/3年后新加坡或者国内一线大厂的高级工程师的水平衡量。

前端分好几个领域，其中有一个领域就是应用实现层，这也是国内大部分前后端做的事情；前端举例子，你只需要会js，css，所谓的几个ui框架或者视图库你就可以完成需求。如果你初具工程化思想，那么你也会去着手设计一些组件，用到一些第三方技术，比如说lit或者ejs等等周边的插件或者工具。还有应用实现层其他的方面，小程序/轻应用/native平台，平台不同，技术也有不同。但是都脱离不了“应用实现”。我一直想摆脱这一层束缚，之前就经常看到知乎或者微信群都在讨论初级工程师和中级工程/高级工程师有什么区别类似的问题时，我就自己默默给我自己划分；现在看来还是很傻的表现，一个程序员的技术不仅仅要看你的编码能力，还有工程能力，架构能力，沟通能力甚至产品运营能力。

跑题了，继续说领域相关的事情。

纯表现层就不说了，这个从字面意思都懂，就是css和canvas类似的特效视觉。

应用架构层，一听这个名字就经常和大神程序员联想在一起，每一个程序员的终极梦想就是架构师/cto，架构层非常考验一个开发人员的广度和深度，在这个领域的程序员你能看到大多数都是年龄比较大的，92后，80后居多。编译原理，算法这些cs的东西将会派上用场，你将会去制定规范，底层优化，应用架构，框架架构等等，解决的是真正的技术问题。这个领域我现在涉及的太浅太浅，但是仍然在往这个方向去靠拢。

基础设施层，这两年尤其是字节在各个大会分享的东西，基础设施占大部分，且非常重头戏。通常这个领域的程序员你必定是在大公司见得多。在这一层就有关，自动化构建，加载，性能优化，代码质量，如何做帮助开发的工具或者平台等等。而我目前也是接触的非常浅的一层，自动化构建和性能优化以及代码质量，都是小团队或者个人的小打小闹。但是确实是在做，没有好的环境条件，做基建很难做。

我的专业之外，我在学习ruby和一部分的node以及serverless这种东西，还有运维相关的等等，包括组建开源团队，从小事做起慢慢做大，去做产品，做运营，做前后端导致我方向现在有点纠结说实话，但是写这篇文章我就能想通了。首先我不忘初心，前端仍然是我主打，去朝架构->基础设施全面发展，英语一定要学好....

晚安睡觉咯

前言

某个普通的一天的早晨，水友群的小姐姐和我聊前端架构，因为她们组最近要筹备一些新项目，在做架构的中途出现了很多问题，所以我拿到了她们的架构项目脚手架代码。拿到代码之后我发现深圳那边的前端团队普遍做的很好，有先进的架构思想，也把ts用的很纯粹，最后没帮人家解决问题，反倒是自己学到了不少。最后我们聊到了前后端全栈开发，如何动态校验协议参数等问题，因为熟悉我开源项目（剑指题解）的朋友都知道，我的后端代码尤其是动态校验那块写的是真差，为了ts而用ts，这也是目前很多用ts的小伙伴的通病，所以我一直打算重构我的一部分后端代码，这个时候见多识广的小姐姐就推荐给我了一个框架，这个框架也是[see how]系列第一篇教程的主角，这个框架就叫做TSRPC

关于专栏

关于see how是什么，说来很巧，这也是TSRPC作者王大大对我的seho这个名字的猜测，其实我的一个名字也没那么多深意，然后被大佬解读成了see how，所以我感觉这是一个不错的idea，那么本来就是想要出一个tsrpc的系列教程，和大家一起学习这个优秀的框架，就正好作为see how 专栏的第一篇文章吧。

关于TSRPC

在正文开始之前，我希望大家可以去自行先去简单快速的浏览相关知识，tsrpc是一个ts的开源rpc框架，它是为了全栈项目而生的，从我上手的第一天开始，我就对这个框架有了以下的第一印象:

1. 天然二进制传输
2. 纯粹的ts，规避了极大部分开发中的错误
3. 强大的运行时复杂检测
4. 这种前后端开发模式，我闻所未闻

官方文档
视频教程

前期准备

学习tsrpc需要你有一些前置知识和其他准备:

1. 熟悉typescript基本语法
2. 准备一个mongodb数据库

开发

使用tsrpc开发全栈应用简单到没朋友，可以从官方提供的cli快速创建前后端一体项目:

npx create-tsrpc-app@latest

按照指引选择浏览器应用，等待完成安装之后，你的目录中会出现2个目录:

- backend 后端
- frontend 前端

我们直接一睹为快，在前端项目根目录运行

npm run dev

官方的脚手架为我们准备了一个简单的todolist应用

整个前后端的目录结构（摘抄官网）

|- backend --------------------------- 后端项目
    |- src
        |- shared -------------------- 前后端共享代码（同步至前端）
            |- protocols ------------- 协议定义
        |- api ----------------------- API 实现
        index.ts

|- frontend -------------------------- 前端项目
    |- src
        |- shared -------------------- 前后端共享代码（只读）
            |- protocols
        |- index.ts

诶，你可能会疑问了，为啥会有一个莫名其妙的shared目录，还要给前端项目去分享这个目录。是因为在shared这个目录我们要定义协议，啥玩意是协议呢？我们通过一个小小的接口来给大家解释什么是协议；

// PtlAddPost.ts

export interface ReqAddPost {
  newPost: {
     name: string;
  };
}

export interface ResAddPost {
  insertedId: string;
}

我们可以在shared/protocols中新建了一个文件PtlAddPost.ts，我们必须以Ptl进行开头定义协议，协议是用来描述一个接口的请求和响应的结构体的文件，你可以这么理解。协议文件通过shared目录共享到前端，你知道会发生什么事情吗？造成了我们前端在对接口的时候，全程代码提示以及严格和请求和返回类型校验。

那么我们接着后端继续聊，协议定义之后该如何做呢？

npm run proto 每当协议更改后，需要重新运行这个命令

tsrpc的设计是协议和api分离，我们必须要清楚，api在我的认知里就是一个异步函数，tsrpc可以帮助我们根据我们刚刚写的协议生成api，比如刚刚我们实现的PtlAddPost.ts，我们运行

npm run api 新协议生成一个新的api

在api目录中会多出一个ApiAddPost.ts

import { ApiCall } from "tsrpc";
import { ReqAddPost, ResAddPost } from "../shared/protocols/PtlAddPost";

export async function ApiAddPost(call: ApiCall<ReqAddPost, ResAddPost>) {
  
}

我们通过call这个方法获取请求参数以及响应给客户端一些信息，我们来一个简单的例子:

export async function ApiAddPost(call: ApiCall<ReqAddPost, ResAddPost>) {
  if(call.req.newpost.name){
     call.success({
         msg: "hello," + call.req.newpost.name
     })
  }else{
     call.error('Invalid name');
  }
}

我们的第一个api已经写完了，我们需要正常的过一次test，然后我们在让前端去调用。

tsrpc使用的是mocha这个测试框架。

// /test/api/**.test.ts

import { HttpClient } from "tsrpc";
import { serviceProto } from "../../src/shared/protocols/serviceProto";

// 1. EXECUTE `npm run dev` TO START A LOCAL DEV SERVER
// 2. EXECUTE `npm test` TO START UNIT TEST

describe("api 测试", async function () {
  let client = new HttpClient(serviceProto, {
    server: "http://127.0.0.1:3000",
    logger: console,
  });
  let ret = await client.callApi("AddTest", {
    newPost: {
      name: "seho"
    },
  });
});

这是我们后端的一个简单的测试用例，在运行这个测试用例之前，您必须要开启后端的服务:

npm run dev

然后可以再开启一个窗口运行npm run test，如果一切正常，你可以看到下面的控制台输出:

粗略计算了一下，我们从开始定义协议到api测试完成，一个简单的接口不到5分钟就已经完成。

这个时候我们可以把这个接口放到前端再继续测试一下。

当然在此之前，我们需要运行以下命令:

npm run sync

我们之前提到过，前后端有一个共享的目录，运行此命令我们就可以把协议等信息同步过来，这个时候我们可以在前端的index.ts文件中，可以获得非常完善的代码提示。

// frontend/src/index.ts

import { HttpClient } from "tsrpc-browser";
import { serviceProto } from "./shared/protocols/serviceProto";

// This is a demo code file
// Feel free to modify or clear it

// Create Client
let client = new HttpClient(serviceProto, {
  server: "http://127.0.0.1:3000",
  logger: console,
});

client.callApi("AddTest", {
  newPost: {
    name: "hello, seho"
  },
});

当我们回到浏览器前端页面上时，这个请求就会发出，如果你仔细观察控制台，会看到以下的场景:

我们的请求体被二进制序列化了，这也是tsrpc的特点之一，我们会在稍后的段落中对tsrpc各个特性做介绍，但是此时此刻我们已经完成了一个api的后端开发->test测试->前端调用。

完善我们的程序

上一个部分相信大家已经学会了如何使用tsrpc开发第一个api，这个部分结合了tsrpc的视频教程中的案例，我们需要做一个简单的CRUD，使用mongoDB。

我们需要在本地启动我们的mongoDB服务，然后我们需要添加一些代码到后端backend项目中。

代码开始之前，我们需要安装mongoDB的依赖，我们可以更方便的引入类型定义以及各种数据库方法。

npm install mongodb -s

为了和视频教程统一，我们的工具类/架构方式，将直接挪用视频教程中的代码:

• 写一个数据库的表模型，名为Post.ts

// shared/protocols/models/Post.ts

export interface Post {
  _id: string;
  author: string;
  title: string;
  content: string;
  visitedNum: number;

  create: {
    uid: string;
    time: Date;
  };

  update?: {
    uid: string;
    time: Date;
  };
}

我们的数据库模型是需要共享到前端的，方便前端工程能够复用，但是为了确保后端的类型安全，我们需要在模型上多做一层处理。mongodb的id属性不是string，而是ObjectID，所以我们需要在后端对模型进行类型重写（只重写id字段）。

关于为什么要在后端多做一层封装是因为不可能在前端引入mongodb中的objectID

// shared/protocols/models/dbItems/DbPost.ts

import { ObjectID } from "mongodb";
import { Overwrite } from "tsrpc";
import { Post } from "../Post";

export type DbPost = Overwrite<Post, {
    _id: ObjectID
}>

我们使用tsrpc提供的Overwrite泛型对刚刚写的Post类型进行改写，将mongodb中的objectID类型引入进来进行替换，然后我们后端工程就要使用这个Dbpost类型，而不是刚刚我们写的Post类型。

• 数据库相关配置

// 配置文件
// shared/protocols/models/BackConfig.ts (models文件夹是新建的)
export const BackConfig = {
  // 替换数据库url，数据库名test
  mongoDb: "mongodb://localhost:27017/test",
};

• 定义数据库初始化类

// 全局一个类，里面写了初始化数据库的内容
// shared/protocols/models/Global.ts

import { Collection, Db, MongoClient } from "mongodb";
import { Logger } from "tsrpc";
import { BackConfig } from "./BackConfig";
import { DbPost } from "./dbItems/DbPost";

export class Global {
  static db: Db;

  static async init(logger?: Logger) {
    logger?.log(`Start connecting db...`);
    const client = await new MongoClient(BackConfig.mongoDb).connect();
    logger?.log(`Db connected successfully...`);
    this.db = client.db();
  }

  static collection<T extends keyof DbCollectionType>(
    col: T
  ): Collection<DbCollectionType[T]> {
    return this.db.collection(col);
  }
}

export interface DbCollectionType {
  Post: DbPost;
}

• 改写后端index.ts

// backend/index.ts 添加如下内容

import { Global } from "../src/shared/protocols/models/Global";

async function main() {
    // Auto implement APIs
    await server.autoImplementApi(path.resolve(__dirname, 'api'));
    // TODO：在这里初始化了数据库
    await Global.init(server.logger);
    await server.start();
};

ok,截止到目前,我们把第一张表的相关配置已经搞定了,请确保数据库已打开且配置正确，然后我们直接运行
一下服务器:

npm run dev

如果你运气好（狗头），那么你应该是成功开启这个服务器，并且控制台能看到连接成功的信息:

然后我们快速开发一下新增API，其他的更新和删除API，希望能大家举一反三，自行开发。

// shared/protocols/PtlAddPost.ts

import { Post } from "./models/Post";

export interface ReqAddPost {
  newPost: Omit<Post, "_id" | "create" | "update" | "visitedNum">;
}

export interface ResAddPost {
  insertedId: string;
}

我们规定的请求类型是只能让客户端传递除了id，create，update，visitedNum的Post类型。
然后我们还是运行那几个熟悉的命令:

npm run proto
npm run api

// api/ApiAddPost.ts

import { ApiCall } from "tsrpc";
import { Global } from "../shared/protocols/models/Global";
import { ReqAddPost, ResAddPost } from "../shared/protocols/PtlAddPost";

export async function ApiAddPost(call: ApiCall<ReqAddPost, ResAddPost>) {
  let op = await Global.collection("Post").insertOne({
    ...call.req.newPost,
    create: {
      uid: "xxx",
      time: new Date(),
    },
    visitedNum: 0,
  });
  call.succ({
    insertedId: op.insertedId.toHexString(),
  });
}

这一part完成～

如何做到动态类型校验

之前我们就提到过，前端在调用后端的api时候，会给出完整的代码提示，从api名称到api的请求体类型等等，那么这一定程度上杜绝了开发中常见的接口联调不细心的问题。在传统的前后端开发中，尤其是分离模式，有一个非常常见的问题就是动态类型校验。每个语言/框架都有自己类型校验的手段，比如springmvc我们可以通过注解的方式来校验(下面展示了控制器中的校验，还有其他校验手段):

@Controller
@RequestMapping("valid")
@Slf4j
public class ValidateController {
 private static final String BASE_PATH = "/valid/";
 @RequestMapping("index")
 public String index(@Validated() Student student,BindingResult result){ 
        return BASE_PATH + "index";
    }
}

那么tsrpc是如何保证数据传输的正确性的呢，首先我们如果在前端使用tsrpc的浏览器请求包，我们调用api时候不仅会在开发中提示开发者这个字段是错误的，而且会在请求发出之前做前端方面的遏制。在后端请求到达异步函数之前，也会去做第三次校验；所以我们在后端异步函数中使用到的参数一定是类型安全，完全不需要担心安全问题。

市面上有很多js领域解决动态校验的方案；最常见应该就是json schema，可以基于json自己实现一套校验方法可以在运行时来做校验。但是仍然有很多缺点，比如不能在前端进行运行时提示且可能重复写很多类型定义。那么tsrpc核心中使用到了一个库（这个库也是同个作者开发的）:

tsrpc-buffer

为了实现ts动态类型校验，不可能把整个ts加进去，因为那有足足60m多，这是不现实的。所以作者开发了这个库。tsrpc依赖了这个库，它对ts的语法进行了兼容，目前支持了大部分的ts的写法，包括我们常用的string，number等，还支持一些复杂的泛形。

如果你想细细了解这方面，可以看一下文档支持的ts类型有哪些

当然，随着ts的更新，这个buffer也会支持更多的ts类型，可以做更完善的全栈应用。而且我们可以使用tsrpc进行原汁原味的ts开发，市面上的第三方工具/框架需要借助另外编程语言/DSL，tsrpc-buffer完全让你使用ts，你不会感觉到一丝违和感。

二进制序列化

tsrpc的二进制序列化机制是由我们上文中提到的tsrpc-buffer中实现的，那么这个特性带给我们的是比json更小的传输体积且支持更多的数据类型，ArrayBuffer, Date等。这意味着使用tsrpc的全栈应用在应对上传图片这种业务的时候简直就像是小儿科，我们可以用一个例子来证明。

// 定义一个协议在后端，PtlUpload.ts
export interface ReqUpload {
    fileName: string,
    fileData: Uint8Array
}

export interface ResUpload {
    url: string;
}

我们通过刚刚学到的一些命令，来生成协议以及api

npm run proto
npm run api

// api实现, 先提前把uploads文件夹建立好，或者使用mkdir方法
import { ApiCall } from "tsrpc";
import { ReqUpload, ResUpload } from "../shared/protocols/PtlUpload";
import fs from "fs/promises";

export async function ApiUpload(call: ApiCall<ReqUpload, ResUpload>) {
  await fs.writeFile("uploads/" + call.req.fileName, call.req.fileData);
  call.succ({
    url: "http://127.0.0.1:3000/uploads/" + call.req.fileName,
  });
}

为了让前端调用，同步shared下的协议

npm run sync

写一个简单的file选择器在index.html中

<input type="file" id="fileInput">

// index.ts
import { HttpClient } from "tsrpc-browser";
import { serviceProto } from "./shared/protocols/serviceProto";

// Create Client
let client = new HttpClient(serviceProto, {
  server: "http://127.0.0.1:3000",
  logger: console,
});

const input = document.getElementById("fileInput") as HTMLInputElement;

input.addEventListener("change", async () => {
  if (input.files) {
    const fileData = await loadFile(input.files?.[0]);
    upload(fileData, input.files?.[0].name);
  }
});

const upload = async (fileData: Uint8Array, fileName: string) => {
  const fr = new FileReader();
  client.callApi("Upload", {
    fileData,
    fileName,
  });
};

function loadFile(file: File): Promise<Uint8Array> {
  return new Promise((rs) => {
    let reader = new FileReader();
    reader.onload = (e) => {
      rs(new Uint8Array(e.target!.result as ArrayBuffer));
    };
    reader.readAsArrayBuffer(file);
  });
}

// 同步到前端
npm run sync

开发完毕，我们可以仔细看一下控制台:

尽管我们在日常开发中会用到一些组件库，组件库帮助我们做了上传的大部分工作，所以我们写原生的上传可能在代码量上更多，但是省去了前后端转换Formdata的时间。

向后兼容http(json)和WebSocket

tsrpc也向后支持json，我们可以在客户端进行一个简单的配置，发送的请求就是json啦:

// Create Client
let client = new HttpClient(serviceProto, {
  server: "http://127.0.0.1:3000",
  json: true,
  logger: console,
});

我其实暂时没有想到非要使用json的场景，使用二进制序列化比json体积更小传输更快，本地开发的日志也在控制台随时打印，所以我还是建议大家使用默认的二进制序列化的传输模式。

tsrpc设计之初是为了游戏，因为传输特性能让websocket更高效，我们可以用tsrpc简单做一个websocket-demo，具体实现我参考了官网的实现，如果你想直接了解官网的这一part的内容，直接移步:

websocket实时服务-tsrpc

tsrpc的实现和协议无关，意味着咱们之前写的代码都可以用，仅仅做一个简单的调整替换即可。

websocket的消息是tsrpc传输中最小单元，我们需要用另外一个方法去定义协议，我们的websocket例子如下:

客户端发起一个请求，服务端接收并且向所有客户端发送一个消息

首先我们需要定义一个MsgHello.ts这样的协议:

// shared/protocols/MsgHello.ts

export interface MsgHello {
  time: Date;
  content: string;
}

这个协议规定了前后端通讯的请求体。

我们需要改写后端backend中的index.ts，将原先的HTTP服务，改成Websocket服务

import { HttpServer, WsServer } from "tsrpc";

export const server = new WsServer(serviceProto, {
    port: 3000,
    logMsg: true
});

这里导出server是有用意的，我们将在之后的代码中会用到这个server。

改写frontend前端中的index.ts

import { HttpClient, WsClient } from "tsrpc-browser";

let ws = new WsClient(serviceProto, {
  server: "ws://127.0.0.1:3000",
  logger: console,
});

const init = async () => {
  // 与后端webscoket服务建立连接
  let result = await ws.connect();
};

init();

我们需要一个api来触发后端给client发送websocket消息:

// shared/protocols/PtlSend.ts

export interface ReqSend {
  content: string;
}

export interface ResSend {
  time: Date;
}

定义成功后，我们运行以下几个命令:

npm run proto
npm run api

运行成功，我们可以在api文件夹下的ApiSend.ts中写入以下内容：

import { ApiCall } from "tsrpc";
// 这里引入banckend/index.ts 导出的server
import { server } from "..";
import { ReqSend, ResSend } from "../shared/protocols/PtlSend";

export async function ApiSend(call: ApiCall<ReqSend, ResSend>) {
  const time = new Date();
  call.succ({
    time,
  });
  // 广播给所有客户端
  server.broadcastMsg("Hello", {
    content: call.req.content,
    time,
  });
}

我们的后端逻辑写完了，我们运行以下命令，将协议同步到前端

npm run sync

我们进一步改写前端frontend/src/index.ts:

import { HttpClient, WsClient } from "tsrpc-browser";
import { serviceProto } from "./shared/protocols/serviceProto";

let ws = new WsClient(serviceProto, {
  server: "ws://127.0.0.1:3000",
  logger: console,
});

const init = async () => {
  let result = await ws.connect();
  console.log(result)
  if (result.isSucc) {
    // ws.callApi
    ws.callApi("Send", {
      content: "hello websocket",
    });
  }
};

init();

我们在页面初始化的时候，向后端发送刚刚写好的SendApi，这个时候我们既能收到api的返回，也能收到websocket的消息推送。

可以看到websocket传输也是二进制的，我们在开发中，也能发现，无论是callApi和发送websocket通知，从始至终都有类型推导，永远不会在传输中出现类型上的错误，这就是tsrpc的强大之处。

多平台

tsrpc支持多个平台，支持浏览器/小程序/原生ios 安卓/nodejs，甚至它还支持serverless，可以使用tsrpc开发基于阿里云/腾讯云的云函数；在后续我也会对tsrpc生态开发更多插件，使其兼容uniapp&unicloud，让他严格严格意义上跨多端，我相信tsrpc可以改变unicloud的开发习惯，让全栈应用更简单。

结语

本篇文章所有的知识点均在官网&视频教程有体现，视频教程在文章开始之前就有链接，非常希望大家能够先去看一下那个视频。tsrpc的教程还会出，下一篇关于tsrpc文章主要还是讲一下如何和serverless（unicloud）融合。这篇文章正在写大纲，相信也会在这个月之内能和大家见到。

数据类型

1. string
2. number
3. boolean
4. array
5. hash

以上是常见的数据类型

命名规则

常量，全部是大写字母

VERSION = "v1"

普通变量，如果不算@，@@等，我们一般直接以小写字母表达就可以了

age = 12;
user_name = "seho";

class和module只需要首字母大写和驼峰表达即可

class Apple

方法名，小写字母开头，结束可以用=，？结尾

def show
end

def index=
end

class写法

在ruby中，ruby的任何变量，string，number等都是object

class Api
  def show
    @article = "hello";
    color = "red";
    render_ajax_success({ msg: "123", text: color, age: age, name: name })
  end

  def index
    @article = "hello"
  end
end

名字首字母大写；class开头，end结尾；文件名称和类名一样，只不过改成小写和_拼接

如果我们要声明一个成员变量在类中，我们有一个更简单的方法去声明，并且自动写好了get和set方法：

attr_accessor "color"
attr_accessor "age"
attr_accessor "name"

类中同样有一个initialize方法，在initialize中我们可以定义class被实例化之后做的事情

同样的，ruby也有私有和公有方法

private
def getName

end

private标注一个方法为私有，那么没有标注的就是公有方法，在class中，一般私有方法是在公有方法的下方

赋值

ruby不像java，赋值需要声明一个变量的类型，直接赋值即可

age = 13;
name = "seho";

插值表达式

在js中，我们可以使用+来拼接变量达到组合的目的，ruby同样也可以

age = "13"
name = "seho"
puts age + name;

但是如果两个不同类型的变量拼接就会报错，因为ruby不知道如何转换，这个时候就需要用到插值表达式了

age = 13
puts "name: #{age}"

各种变量

类变量

# 多个实例都会共享的变量
@@age = 123;
A.new.@@age; # 123
B.new.@@age; # 123

实例变量

# 作用域是class类中，在ruby中广泛使用
@name = “seho”;

普通变量

# 作用域是在方法内
name = "seho"

全局变量

# 全局都可以使用的变量，不常用
$version = "v1";

方法

类方法

class A
    def A.show
    @article = "hello";
  end
end

实例方法

class A
    def show
    @article = "hello";
  end
end

他们的调用方法不一样

A.show
A.new.show

symbol

js在es6也有这个数据类型，ruby也表示内容永远不变，一般用于表达hash的key，声明只需要前面加冒号就可以了。

:age = number;
# 声明一个hash，最需要用到symbol
time = {
    :name: "seho"
}

数组

num = [1,2,3,4]
# 数据类型混合着来
test = ["1",2, "1", :name, {:name: "seho"}]

Hash

hash有3种写法

jim = {
    :name => "jim",
    :age => 20
}

# 1.9之后产生的新写法
jim = {
    name: "hello",
    age: 20
}

# 也可以写成
jim = {}
jim[:name] = "jim"
jim[age] = 20

hash的key，string和symbol不同，例如

jim = {
    :name: 1,
    name: 2
}

a[:name] #=> 1
a["name"] #=> 2

条件判断语句

# if else end是最常见的
a = 1;
if a == 1
    puts "a is 1"
elseif a == 2
    puts "a is 2"
else
    puts "is not"
end

同样还有case分支语句

a = 1;
case a
    when 1 then puts "a is 1"
    when 3,4,5 then puts "a is [3,4,5]"
    else puts "a is not in there"
end

三元表达式

a = 1
puts a == 1 ? "one" : "not one"

循环

# for
[1,2,3].each { |e| 
    puts e;
}

# 等同于下方
for e in [1,2,3]
    puts e
end

for和each几乎一样，for是关键字，而each是数组的一个函数；高手都用each，因为ruby和js有相像之处，for中的e变量，是全局的，循环之外，仍然可以访问到它，而each可以说是局部变量；

# loop
loop do
 # code
 break if 表达式
end

# while
begin
 # code
end while 表达式

更推荐使用loop，因为可读性更强，我不熟悉ruby，我都要使用loop是因为它能给我带来最直观的语义，而while的语义明显拗口。

2021年前端面经

目前本人已经有了新的起点，之前在博客的求职贴也就作废了，这是我第一次写面经，写这个面经的目的希望大家能了解:

1. 不要当作面试题背诵，因为题解仅仅是思路你会发现我的题解都比较浅甚至是有很多错误。
2. 不要拿此题去面试其他人，因为好的面试官我认为不应该是行走的题库，应该考虑候选人是否符合团队技术栈和用人需求，不应该拘泥于业务题目，我认为多问问项目比问100道题解要有用的多。
3. 分享出来也是记录自己的心路历程，希望大家对西安目前的招聘要求有一个大概的了解，如果你觉得我的题解有哪些错误，那就来打我吧（写评论区，我们探讨一下，我会改正的呢）
4. 题目有些是我面试的时候必问的，有些是来自于沃趣，腾讯云，狼人杀团队的面试题，目前题主所在的公司问的题目不属于以下范畴，仅仅当作学习交流使用。
5. 有些题目的题解我的博客也有文章（比如vue3和vite），所以大家可以去博客中看一下～

在mark一下我的博客和我现在在做的开源项目:

因卓诶-爱分享爱原创的技术博客 ~ 个人博客

最近在做的项目:

swordCodePractice/InternetQuestionBank

项目名字叫：剑指题解，业务题库app，帮助程序圈子的小伙伴们利用碎片化时间进行自我提升的小程序。

JS

事件循环模型，同异步，阻塞非阻塞，消息队列，调用栈，GUI渲染

JS虽然是一个单线程（主线程）的语言，但是它有很多工作线程，比如Ajax，定时器等等。那么同步和异步在分布式系统中来讲就是一种消息通讯机制罢了，关注的是是否能立即返回结果。它不能和阻塞和非阻塞概念混为一谈。阻塞指的是等待结果返回之前影响接下来的任务，非阻塞是不影响。当JS引擎执行异步任务的时候，会把这个任务注册成一个函数，通过事件循环模型通知对应的工作线程（比如Ajax），然后主线程会继续执行当下的任务，等到工作线程完成了任务，事件循环模型会将这个异步任务的回调放到消息队列中，当主线程的调用栈为空（有空闲了）就执行消息队列最前面的消息。那么主线程从消息队列中去取任务和执行任务回调的过程就是事件循环模型的特点。

HTML到DOM是由GUI线程控制的，GUI线程和JS线程是互斥的，GUI线程会在JS的调用栈为空的情况下才会执行，因此当JS中有大量的逻辑需要处理是会影响到GUI渲染的。

闭包，作用域（词法环境）

当我们在js创建一个函数的时候，会创建一个闭包，这个闭包像是一个气泡一样，包含了创建时作用域中的变量，闭包不会随着作用域的销毁而无效，闭包保存在内存中，我们可以任何时候可以访问到闭包中的变量（除非js认定它要销毁了才会销毁），我们可以使用闭包来做很多事情，比如实现私有变量，回调函数，包括实现柯里化；关于作用域，JS中有全局作用域和函数作用域以及块级作用域，其中全局作用域和函数作用域不难理解，就是直接写在window和脚本顶级位置的代码都处于全局，函数作用域就是在函数声明中的代码处于函数作用域，而块级作用域是es6新增的let const声明的代码（或者with语句以及trycatch），只能在{}这样的块级作用域中使用。

临时性锁区 TDZ

TDZ不仅仅是日常熟知的let,const情况下可能造成的问题，我们在很多地方都可能会出现TDZ。我们先来理解TDZ是什么：我们拿let和const举例子，我们在let声明之前去使用变量会得到ReferenceError这样的错误，而var不会报这样的错。因为es6规定，let声明的变量在他们的词法环境被实例化时候才会被创建，但是当它们词法绑定的时候才可以被访问（词法绑定换句话来说，没有对变量进行运算）；如果在词法绑定之前就访问就会报错；那么从词法环境实例化之后到词法绑定完成这中间的过程就叫做TDZ临时锁区

变量提升是JS的变量最基本的特性，不管是let，const，var都有提升特性。let和const在词法绑定（运算）中，如果未赋值，则就是undefined；那么TDZ其他表现，会在typeof，包括函数参数预设值等场景出现。那么TDZ的作用就是让我们能够用正常的数据流去编写代码，所以我们在写代码应该要注意变量声明顺序，还有避免多个变量是同名情况。这些开发恶习是我们不提倡的。

原型链，原型

JS中的原型链是数据结构中链表的最佳体现，JS中的每个对象都有一个__proto__属性，JS中的函数中有一个原型属性prototype。

function foo(){};
foo.prototype.test = "this is test";
// a是foo的实例，a是一个对象，它有一个隐式原型指向了构造函数的原型对象
let a = new foo();
a.test; // this is test 隐式原型可以访问构造函数上的原型方法

Function也是对象，对象的隐式原型是什么呢？隐式原型指向的都是构造函数的原型，Funtion的构造函数还是Function，那么它的隐式原型就是Funtion.prototype;

Funtion.prototype中的__proto__指向了Object，Object的原型指向了Null，按照规定Null没有原型对象，所以Null是所有原型链的最终点，这个链表我们就称之为为原型链。当对象自身找不到属性的时候会去原型链上的每一个原型去找或者返回null；

总结：

1.对象有属性__proto__,指向该对象的构造函数的原型对象。

2.方法除了有属性__proto__,还有属性prototype，prototype指向该方法的原型对象。

函数

函数是JS的第一等公民，函数的大部分核心内容都在以上的章节提到过，那么这个part我们将简单说一下IIFE。

IIFE指得就是立即执行函数，这个概念js的初学者都知道，我们会通常这么写:

(function(){
    console.log("helllo world");
})()

IIFE起到了这样的作用，我们在匿名函数中声明的变量不会被外部访问即不会污染全局。

脚本异步加载

在HTML5之前我们在HTML中加载script脚本的时候，是遇到脚本然后会理解执行的，它是可以阻碍下面的DOM渲染的。其次呢就是在H5加入的2个属性，async指的就是，我们异步加载了这个脚本文件并且执行了它，这个过程是不会阻塞下面的DOM渲染的。defer也是同理，但是和async在执行时间上有区别，defer会在DOM渲染完毕执行。所以总结来说，defer更适合我们常理的加载JS的方式。

Promise

在JS的远古时代，我们假设要调用一个接口或者是做一个异步的操作，我们通常会使用回调函数来resolve结果，比如这样：

request(data, (res) => {
    // 我们要通过res中的值进行下一步操作会这样写
    request(res, (res1) => {
        console.log("fuck is so hard!!")
    })
})

当我们进行多个任务嵌套，这就造成了回调地狱，这是非常不优雅的写法，那么Promise就就解决这个问题，我们通过Promise来给返回值一个“诺言”，就像下面这样:

const a1 = new Promise((resolve, reject) => {
    // resolve将会从then中获取
    // reject将会从catch中获取
});
a1.then(res => {}).catch(err => {});

那么我们需要知道，promise有几个状态:

1. fulfilled（resolve之后）
2. reject（reject之后）
3. pending（还未决定，还在等）

那么Promise有哪些特性呢？比如这个状态一改变就不能在改变了，同一时间只能存在一种状态。那么async和await和promise有什么区别呢，async是es7引入的语法糖，专门处理promise的对象，它在写法上更精简了，使得异步代码彻底的变成了同步代码的视觉样子，比我们promise.then这样链式调用更容易阅读和理解。

待补充：Promise A+规范有哪些？

this的理解

在绝大多数的情况下，函数的调用方式决定了this的值，es5里面通过apply, bind, call来执行函数，此时的this就是他们的第一参数。那么后续又引入了箭头函数，箭头函数不提供this绑定，所以当前如果在箭头函数上出现，那么this指向的就是创建函数的词法环境。

Proxy

Proxy是es6的新语法，熟悉Vue2的盆友都知道，vue2的响应式是基于

Object.defineProperty()

而vue3的响应式是用proxy的，但是并不是ref,computed都是用proxy实现的。那么proxy主要的作用有什么呢？proxy可以创建一个对象的代理，实现查找，拦截以及自定义的其他功能。

const target = {};
const proxy = new Proxy(target, {
   get (target, key, receiver) {
       return 567567;
   }
});
console.log(proxy.getData);

proxy可以代理所有ProxyHandler定义的型位，也可以代理13种对象行为；

proxy和object.defineProperty的区别：

1. 对于深层嵌套的对象，defineProperty需要遍历让每一层代理，这也就是vue2为什么watch的钩子中有一个deep的选项，开启deep就遍历。
2. 对于数组，defineProperty不能监听关于它的操作，所以vue中.push一个数据到数组中，template不会变就是这个原因，我们必须要concat返回一个新的数组才能被访问到。
3. defineProperty比proxy兼容性好。

数据类型/引用类型

基本数据类型有7种：number, string, obejct, null, undefined, boolean, symbol

引用数据类型：统称为object：

let a1 = {};
let a2 = {};
console.log(a1 == a2);
console.log(a1 === a2);

引用数据类型的比较是比较在堆内存中的引用；引用数据类型的真实数据是存在堆中，而基础数据类型存在于栈中。

那么这块就是老生常谈的就是==，===的区别，这个说了太多次了，==有隐式转换不严谨，我们在开发中应当使用===进行严格的判断，能够区分不同的数据类型；

我们需要注意的事情是，在堆中的对象是可变的，在栈中的变量是不可变的，我们如果更改了栈中的变量会重新在栈中划分一块区域。

深拷贝和浅拷贝

根据我们上面提到的数据类型相关知识，我们这里的深拷贝和浅拷贝只针对引用数据类型即object。我们知道引用数据类型虽然在栈中有自己的一个区域存储变量，但是同时又在堆中存储了栈中变量的引用，由于其特殊性，我们在对“对象”和“对象”进行浅拷贝操作的时候，仅仅会复制对象的指针，也就是他们还是指向同一个堆内存；但是深拷贝就不一样了，他会从内而外的复制一个新的对象，指向一个新的堆内存，2个对象互不干扰。这就是深拷贝和浅拷贝的区别。

那么浅拷贝和直接赋值有哪些区别呢？

首先赋值操作，肯定就是复制了栈中的对象，赋值之后此刻就是联动状态，a变b也变；浅拷贝唯一的区别就是第一层是否是基本数据类型。浅拷贝不会改变基础数据类型，但是如果对象其中有子对象（object,array）这个时候子对象变，那么浅拷贝之后的对象也会变。

常用的深拷贝和浅拷贝的操作？

浅拷贝就concat, splice, object.assign(这个深拷贝也可以用)等等

深拷贝就最简单的json.stringify或者写一个递归；

柯里化

柯里化的意思就是在计算机科学中，可以把一个函数多个参数的写法转换一系列一个参数的技术。

var curry = fn =>
    judge = (...args) =>
        args.length === fn.length
            ? fn(...args)
            : (arg) => judge(...args, arg)

上面这个是高颜值写法，柯里化通常用于函数式编程，意指提高代码复用，更容易阅读；

模块化

ES6的模块化解决了很多以前JS的依赖管理和开发全局变量污染的情况，这个part将简述几个模块化标准的特点以及区别。

commonJS：

const m = require("./m.js");
m(); // m.***();
// 屈居于模块中的module的export对象导出的是什么

commonjs会遇到require语句会执行并且运行这个脚本，而这个脚本中的内容都会被缓存到内存中，模块可以被多次加载，但是只有第一次加载才会被缓存；NodeJS就是参照了CommonJS的规范，但是NodeJS自己加了一点东西，就是把module.exports指向了一个变量exports；

特点：

1. 模块中的代码不会污染其他变量，是在模块作用域中。
2. 模块加载会被缓存，使用模块中的内容会直接从缓存中取，如果需要获取再次获取模块，需要清除缓存。
3. 模块加载顺序就是代码执行的顺序

AMD

commonjs非常好，但是它require之后需要立即执行这个特性不适合浏览器，所以AMD和CMD就是适合浏览器运行的模块解决方案，AMD是异步加载，加载完模块依赖的包之后，会有一个回调函数给开发者，我们在回调函数中才可以正常的使用模块中的方法，例如下面：

define({
  add: function(x, y){
    return x + y;
  }
});
// 使用它
require("math", (a) => {
    a.add(1, 2)
});
// 定义AMD模块其实有很多参数，我们只列举了最简单的写法

CMD

CMD的API和AMD很像，它支持AMD的所有API，但是CMD推荐的是：

define((require, exports, module) => {
// do something
})

CMD与AMD的区别就是：

1. AMD提倡依赖前置，即依赖提前执行，CMD推崇依赖就近，依赖是延迟执行

UMD

那么既然CMD和AMD以及CommonJS这么好，我们可以灵活地使用这些模块，就需要UMD了，UMD是一个通用的模块标准，在UMD的实现中，通过判断环境来决定使用哪种模块化，如果环境中AMD的不存在(define)就寻找commonjs，如果commonjs都不支持，那么会把模块暴漏在window或者global中。

ESModule

我们最熟悉的ESmodule来了，其实在esmodule之前，那些规范都是社区定义的，但是esmodule是真正的官方语言层面提出的模块解决方案，那么esmodule对比commonjs有什么优势呢？commonjs和AMD它们一样，都是在运行时才能确定依赖，但是esmodule能做到编译时就能确定模块依赖。

ESmodule是使用，export 和 import这两个关键语句来进行模块引入和导出的，官方定义的模块就是不一样，支持别名，默认引入等等，写法也非常精简，所以esmodule是我们目前开发web浏览器端的代码时最常用的模块标准。

Vue

Vue2核心理念和Vue3核心理念

1. Vue3的VDOM进行了重写，首先是体积更小了。
2. 响应式系统的升级，用proxy来劫持数据，使得Vue2响应式系统的一些坑得到了完善（具体什么坑可以看defineProperty的缺点）
3. 组件内不需要根节点了
4. DIFF算法更快，标记了所有的静态节点，只需要DIFF动态的内容
5. 使用组合API区别于传统的OptionAPI，原来的option将逻辑分散到各个地方不宜与维护和阅读，而组合API将同样逻辑的代码组合在一块，高内聚低耦合，阅读维护更加的方便。

style中的scoped原理

每个组件都会在postcss编译中产生一个Hash，在style中写scoped属性之后，在页面的表现就是使用css的选择器选择对应组件的hash。在这个选择器（组件）下的css是不会影响到外部的css的。

Vdom

VD本质就是一个JS对象，我们熟知的React和Vue都是使用VD进行页面渲染的，那么VD有哪些好处呢？我们都知道页面出现都要经过js运算，生成渲染树，绘制这几个阶段，那么组件中如果出现大量的变化是要经过重排/重绘的，为了避免这个情况，我们使用VDOM来表述DOM，它和DOM是一一对应的，然后经过在内存中我们Vdom和dom的比对，然后分批次的更新页面上的dom。那么页面渲染性能就可以得到很好的提升。

而且VD可以跨平台渲染，因为本质就是一个对象，不仅可以把对象编译成DOM，还可以编译成QQ,微信,ios,原生安卓。缺点也是显而易见的，我们需要创建额外的函数去做这个事情，但是也可以依赖工具比如vue-loader等。

domdiff是对比新旧虚拟dom一种算法，分两种情况：

• Components diff算法
• Element diff 算法

组件的diff则是查看组件的类型，类型不相同就新替换旧的，类型相同就更新组件属性，然后进入组件递归上述操作。

标签的diff则是查看标签名，如果标签名不同就直接替换，相同就只更新属性，之后进入标签内部递归上述操作。

MVVM（本来不想写）

如果要讨论MVVM，那么就要谈到MVC和MVP了，就简单的概述一下三种架构模式吧。

MVC

MVC是非常流行的架构模式，它分为view，model，controller层，它们都是单向的通信，由view去触发controller，controller再去触发model做数据处理，然后反方向返回给view层，在这个架构中controller层是最薄的，它只做了逻辑分发的作用，一个桥梁衔接。熟知的框架就是SpringMVC。

MVP

MVP是MVC的衍生的一种架构模式，它把controller变成了Presenter，各个部分的通信都是双向的，而这里的视图view则是被动的，在这个架构中，Presenter做了绝大部分工作，而view是最薄的。

MVVM

MVVM也是衍生的一种架构模式，它没有controller，新增了一个viewModel，它保证了view和数据的双向绑定，其中有一个绑定器去做这样的事情，view的变动会反应到viewModel，反之亦然。

谈谈Vite，为什么这么快，主要解决什么问题？

天下武功，唯快不破；Vite作为超现代的本地开发服务器而且是基于ESM的。那么现在很多开发服务器都是基于ESM的，比如SnowPack。Vite本地开发快主要使用ESM，对于TS和HMR使用的是ESbuild的插件，Esbuild是用GO语言原生编译的，所以Vite在TS和HMR都有出色的表现。vite在生产环境使用的是Rollup（和Vue-cli一样）。

Vite还有以下的特点：

1. 开箱即用，TS,jSX,CSS等
2. MPA应用或者库模式都是非常简单配置
3. SSR服务端渲染

想要具体了解vite是如何运作的，可以了解我以前写的一篇浅析vite的文章：

从0开始理解Vite的主要新特性（一）

Vue如何做依赖收集

我们需要事先了解观察者模式，观察者模式是一个观察者和目标组成的，观察者直接订阅目标，当目标做出改变，观察者也要立即做出回应。那么发布订阅模式和观察者模式有些许不一样，发布者只需要做好发布的任务，不关心订阅者有没有订阅。

在Vue的组件中有一个watch去监听set值，监听到set值之后会去调用render从而实现视图上的变化。那么Vue如何知道哪些变量使用了呢？我们在template中访问了这个变量，势必会被getter监听，在getter我们就可以对这个变量进行标识，从而实现变量被使用之后才能被组件中的watcher监听到。这个步骤就是Vue的依赖收集简单原理。

那么上述就是，一个一对多的例子，一个数据变更了，多个用到这个数据的地方都要做出改变，这就是观察者模式要做到的东西。那么在这个里面目标是data数据，观察者就是计算属性，侦听器，视图等。

• Keep-alive怎么做？原理是？

这个地方我们描述的是vue中内置的持久化状态的组件，而不是http里面的keep-alive，这个需要注意。如果熟悉vue的同学肯定写过这样的代码：

<keep-alive>
    <App/>
</keep-alive>

(keep-alive下文简称ka), ka 包裹了app组件，就代表了app组件中所有状态都会被缓存，它们不会重走生命周期函数，即create和mounted只执行一次，但是请注意vue并不会销毁被缓存的组件，ka本身也不会去渲染任何元素，它是一个抽象组件。业务需求中我们也需要对缓存组件做一些额外初始化处理，但是生命周期只执行一次就很难受，vue给我们提供了activated这样的钩子，当缓存的组件再次渲染之后我们依然可以做一些初始化的工作。

mounted(){
    // 第一次渲染被缓存的组件
},
activated(){
    // 当缓存再次渲染后触发的钩子，但是此时不会触发mounted
},
deactivated(){
    // 当缓存的组件被销毁，触发钩子
}

我们刚刚提到了ka是抽象组件的问题，vue内部是如何不渲染这个ka的呢，是因为在vue组件在初始化生命周期父子组件建立关系时，如果遇到abstract为true的组件则不渲染，而ka就是true；那vue内部实现中，keepalive是如何有缓存功能的？这一块我摘抄一篇文章提到的一段源码。

// src/core/vdom/patch.js
function createComponent (vnode, insertedVnodeQueue, parentElm, refElm) {
    let i = vnode.data
    if (isDef(i)) {
      const isReactivated = isDef(vnode.componentInstance) && i.keepAlive
      if (isDef(i = i.hook) && isDef(i = i.init)) {
        i(vnode, false /* hydrating */)
      }

      if (isDef(vnode.componentInstance)) {
        initComponent(vnode, insertedVnodeQueue)
        insert(parentElm, vnode.elm, refElm) // 将缓存的DOM（vnode.elm）插入父元素中
        if (isTrue(isReactivated)) {
          reactivateComponent(vnode, insertedVnodeQueue, parentElm, refElm)
        }
        return true
      }
    }
  }

作者：wilton
链接：https://juejin.cn/post/6844903837770203144
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

ka组件实例componentInstance是undefined但是keepAlive是true（所有被缓存过的组件keepAlive都是true），所以只执行到i(vnode, false / hydrating /)这一段代码，下一步的if没有执行。但是再次访问被缓存的组件的时候，componentInstance是上一次初始化的，所以我们能顺利的走完下一个if即insert(parentElm, vnode.elm, refElm)；将缓存的内容插入到dom中。

我们之前提到的ka只会执行一次完整的生命周期，这一块的逻辑和上述一样，组件实例componentInstance不为undefined且keepAlive为true就不会执行mounted。

这就是keep-alive组件的源码实现，我这个题解描述的非常片面，在写这部分的时候，我自身对于ka的理解没有达到源码级别，所以看了这篇文章之后才有一个全新的认识，我把文章po一下：

彻底揭秘keep-alive原理

nextTick原理？怎么用

nextTick是Vue官方提供的一组API，用于获取在vue中下一次更新DOM结束的回调。由于Vue的DOM更新是异步的，所以我们更改DOM之后需要使用这个API来获取最新的DOM。

原理待补充

router原理？

路由这个概念其实是web层面是服务端的概念，但是前端为什么引入了路由概念，是由于spa应用的流行，很多库都有自己的router实现，那么前端路由中的URL和视图有哪些特性呢？

1. 监听URL变化改变视图
2. 不会刷新页面

我们使用hash和history来简单构建一下router基于我们的上面两个特性：

1. hash指的就是URL中的锚点#之后的内容，锚点在HTML中常用于导航，在这个模式下，我们改变hash是不会刷新页面的。

window.addEventListener('hashchange', onHashChange);
function onHashChange(){
    // 通过判断hash来对页面进行变换
}

2. history模式在外表下和普通URL无异，但是在这个模式下要比hash做更多一层：popstate我们使用这个API来监听URL的变化，但是当直接改变URL或者a标签跳转是不会走popstate的，所以我们需要监听URL变化和a标签跳转：

window.addEventListener('popstate', onPopState)
// 我们通过拦截a标签的事件，自己绑定一个click事件，去写下面的代码
history.pushState(null, '', el.getAttribute('href'));
// 这样手动的更新URL，不会刷新页面
// 判断URL进行刷新试图
...

React

惭愧，react我只学了1-2天，而且直接接触的是hook，react这块只达到了能写的实战水平，但是水平完全够不到vue，因为知识有限，所以这块罗列的题目很少。

useState如何回调？

待补充

类组件 vs 函数组件

待补充

更新state是同步还是异步的？

待补充

hooks带来了什么？

待补充

Webpack/Vite/SnowPack/Babel

简单讲一下webpack的构建过程

1. 寻找入口文件
2. 通过入口文件，逐层识别模块依赖，commonjs，amd，esmodule都会被分析，然后获取代码中的依赖。
3. 然后webpack就要做分析代码 转换代码 编译代码 输出代码这几个重要阶段，在这几个阶段中webpack中的loader和plugin都会起作用。
4. 输出代码

常用的loader知道有哪些么？css-loader和style-loader是干嘛的？

loader就简单的用css-loader或者scss语法loader，那么题中的css-loader和style-loader都是出现率极高的loader，css-loader主要是分析语法中的@import语句的，还用于处理css和css文件的关联，style-loader会把css挂载到html中的style里面去。

常见的plugins有哪些知道么？

比如说:

1. htmlwebpackplugins：生成一个html并且自动引入入口文件
2. HMR plugins：热模块更新的插件

loader和plugins的区别？

loader主要是针对特定文件的分析和编译，而plugins是webpack生态的最重要支柱，它可以干loader干不了的事情，比如说在webpack执行中会广播很多事件，而plugin可以监听这些事件并且处理和改变输出结果。

简单讲一下sourceMap

“简单“讲一下，我也只能简单讲一下了，难的我也不会。首先我们通常前端在部署的时候，会将js，css这类文件进行压缩，通常这部分工作是打包器为我们做的。但是我们想要在生产环境中查看代码错误，而浏览器会将错误定位到我们压缩编译过后的js中，这对我们debug是不利的。所以我们可以使用sourcemap去解决这个问题，它本质是一个map文件，存储了编译过后的代码的位置信息，我们在编译过后的js中引入map文件即可，引入之后浏览器会根据map存储的位置进行反馈给控制台，我们就可以很快进行debug。那么在webpack中，sourcemap有几种的常见模式：

（省略7种常见的.....）我如果真的遇到问我哪7种模式的面试官我就会很无语，webpack成千上万的配置项我咋可能都能背出来，开发中就直接查文档就好了。eval构建速度很快，而且我们sourcemap不用存储很细致的位置信息，所以使用cheap就可以了，综合来看，一般都是下面这个配置：

开发环境：cheap-module-eval-source-map
生产环境: cheap-module-source-map

如何提升webpack打包速度呢？

Webpack: 从9个方面对打包速度提升（和Node.js的美好碰撞）

webpack的热模块更新怎么做的？

这个问题我说实话，就算不会webpack，也都知道热更新，就算不知道热更新这个词语也都知道我们通常在使用一些脚手架快速开发的时候，更改文件能在页面即时同步技术。那么webpack是如何做热更新的呢，webpack中有一个官方维护的plugin：

HotModuleReplacementPlugin | webpack

hmr之前有很多库比如我经常在vscode中用到的live server，能够监听文件的变化通知浏览器进行刷新，之所以hmr的出现风靡技术圈，原因就是以前的livereload机制太扯了。比如一个提交表单场景，你输了很多表单值，你准备进行测试，发现代码中有一个地方有错，你更改之后发现页面刷新，你之前输入的表单值全部没了。我对hmr工作原理理解非常浅，如果你要深入了解这个内容，我不妨推荐给你们一篇文章，我认为全网就这篇文章把hmr讲透彻了。

Webpack HMR 原理解析

简单说一下我的理解，我就是那种喜欢纸上谈兵的（狗头）:

1. 启动webpack时候有watch选项，即文件更改→重新打包→编译到内存中。
2. webpack-dev-server会监听静态文件变化，然后通知浏览器livereload（重新加载非hmr）
3. webpack-dev-server会和客户端建立websocket连接，推送给客户端不同类型的消息，比如上一步的静态文件信息，还有变化了的文件更改，还有新模块的hash，后续会根据hash值去和客户端本地文件做比对，达到热模块更新效果。
4. HotModuleReplacement拿到上述从服务端给的hash之后，hmr插件通过一个runtime模块去请求所有要更新的文件hash列表，再发起请求拿到要更新的所有文件
5. hmr插件将比对新旧模块区别，然后判断要不要替换，如果选择替换的话，将分析相关文件依赖，是要一起更新的，如果hmr热更新失败，那就触发livereload，刷新浏览器获取最新的文件。

我原本面试主要说的是建立websokect连接，balalalalala...，但是看了上面的分析文章之后，自己简单的概括了一下，收获非常大，hmr的难点应该是在于如何替换，其他倒是很容易理解。

webpack模块打包原理？

暂补充

webpack文件监听怎么做的？

—watch，webpack-dev-server是默认开启的，脱离webpack之后可以用nodemon做监听。

webpack代码分割本质，有什么意义？

应用越来越大，vendor也会变大，某个功能可能只依赖了vendor一点，但是也要把整个包加载，使用代码分割，可以将业务和业务隔离开，按需加载。避免了浏览器加载页面白屏或者加载功能模块性能的问题。

简单聊聊Babel原理吧

我对babel原理一窍不通，惭愧。babel我的理解就是js的翻译官，能够高效的把高级/实验性语法进行低版本兼容。

CSS

WebComponents

WC是现代组件化的一种技术，WC的核心理念就是：

1. 自定义元素Custom Element
2. ShadowDom
3. 模板Template

我们可以用这些技术构建出一个自定义组件，而这个组件的css和js逻辑都是独立于组件本身。

在这以下几种情况，容器不能承载ShadowDom：

1. 自身已经承载了Input，TextArea
2. 承载了Img标签的容器

如何让页面元素消失？

这个是我面试必考题，能够考验候选人的CSS方面的想象力，下面简单列举一下我的答案：

1. 宽高为0
2. 背景为白色，让用户看不到
3. 用posotion transform margin 一系列移动的方法把元素移出去看不到
4. css缩小，旋转可以把元素处理到看不见
5. 透明度和css可见，透明度可以用opacity和filter实现
6. 把字体设置为白色让用户看不到

重排和重绘？如何写组件优化重绘重排带来的开销？

重排和重绘是浏览器页面渲染的必经之路，我们在开发中的代码操作可能引出重排和重绘，那么关于重排和重绘，我们只需要记住一句话：我们页面的布局发生了改变就会引起重排，而重新排会影响到重新绘制，更改颜色文字大小等会引起元素重新绘制但是不会进行重排。在我们开发中，浏览器已经做了很多渲染优化，我们只能在特殊的场景能够发现重排和重绘优化带来的红利，但是我们仍然需要关注渲染性能的优化。比如在我们开发组件的时候，可以使用css contain content，让组件变化仅仅组件内部进行重排重绘，而不是影响整个页面。

transform中的translate会引起重排么？

不会的，GUI线程会开启一个新的图层，不会影响普通文档的图层，那么让线程开启一个新的图层的操作也有很多，比如说透明度，过渡动画，3D等等。定位虽然脱离了普通文档流，但是它还是默认图层，所以还是会影响到普通文档流。创建新的图层是要内存消耗的，所以好的东西不要贪杯。

如何更改组件内部样式？（深度选择器）

这个我就暂且默认为Vue的组件吧，我们也在上面提到了Vue组件如果做样式隔离的原理。

1. <<<选择器（记忆中，scss和less不支持）
2. 曲线救国，再写一个style，把组件内部的样式写到没scoped的style中
3. /deep/ 我一般用这个

css中如何获取html元素上的属性

这个题很简单啊，但是在开发中确实非常少用到，下面给大家上代码演示一下：

content:attr(href); // 必须在伪元素中写

有了解过calc么？

和上面那个题是一个智商的题，问出来的人其实我觉得水平不高，但是奈何我们的题解中预判它可能存在，就简单说一下：

width: calc(100px + 40vh - 100px); // 简单举个例子，计算各个属性的css值，运算符之间必须要空格隔开，要不然无效

CSS沙盒

css sandbox其实也是主要解决样式隔离的问题，那么样式隔离的问题，我们有以下几个方法去解决/设计：

1. namespace在acticle下面用，但是这个场景一般用在H5制作器上，多个组件移动到同一个区域中展示。
2. Iframe这个是真正意义上的沙盒，但是很多局限性，高度不能自适应等等，因为iframe是上古时代的产物，所以这里不太了解。
3. Webcomponent的实现之一ShadowDOM可以解决样式隔离的问题，但是如果care兼容性的话还是用第二种iframe的办法吧。

简单聊聊BFC？如何解决BFC造成的问题？

BFC（块级格式化上下文），指的就是在一个如果一个盒子是BFC盒子的话，那么在盒子里面的任何css都不会影响外部，它更像是一个css"作用域"，所以我们在css开发中遇到一些问题，包括BFC内的样式重叠等等，我们都可以用BFC把元素独立开，去解决这个问题。

如何触发BFC呢？(没见过没用过我不会写)

1. body元素就是天然BFC的盒子
2. overflow 除了auto其他的值都可以解决
3. 定位 固定定位 绝对定位
4. display inline-block flex
5. 浮动 float

清除浮动

清除浮动这种题，我感觉没有脑血栓10年问不出来。我的面试风格就是挑有用的问，浮动都是很老的题目了，清除浮动这样的题以前很常见，但是2021我觉得没人会问了（校招笔试题可能会看到）：

1. overflow: hidden;
2. 相邻的元素是clear:both
3. 或者父子都浮动（尽管脑血栓20年才会这么干）
4. 伪元素加clear:both(推荐)

HTML

有了解过PWA规范么？

pwa是一系列的技术/规范，是由谷歌提出的，我们都称之为渐进式应用（你也可以理解为国外小程序，个人觉得比我们国内小程序功能更实用，但是没有生态没有用户粘度），使用现代webAPI去构建原生一样的跨平台应用。那么这一块的内容有点多的，所以我们就简单讲解用的比较常见的几个：

1. servicewoker 离线使用
2. 像APP一样具体推送通知的功能
3. 像APP一样添加到主屏幕

这一块其实有蛮多内容的，感兴趣的可以自己搜一下。

简单说一下可替换元素吧

在HTML中有一部分元素就叫做可替换元素，它们不受CSS引擎控制，我们往往看到可替换元素的时候，这个元素就本身自己具备了一些普通元素没有特性，比如Img，Input，textArea等等；

就拿Img来说，img是行内元素，行内元素的定义就是不独立一行且无法设置宽高，但是img作为行内可替换元素是可以设置宽高的。

单页应用和多页应用（spa和mpa）的区别？

这两个概念，尤其是spa这个概念是最近几年非常流行的。spa对应的就是mpa，即多页应用；我们传统的前端页面，都是由一个一个html组成的，通过各种link来连接一个一个页面，那么意味着我们每请求一次都要去请求一个新的html进行响应。这个方案在pc端还尚可，但是在移动端中，用户每切换一次页面都是一次巨大的成本，所以spa应用而生，spa也促成了很多前端路由方案，通过url和页面进行绑定，然后由JS去控制显示的视图，这样做的好处就是，切换速度很快，用户体验感好。

那么spa也有一些缺点，比如说是SEO搜索收录不太好，因为搜索爬虫爬取mpa页面会记录每一个HTML的路径，而爬虫遇到spa页面的时候将会大大受限。mpa在首次加载的速度又优于spa，但是切换速度就不如spa了。所以综合来讲，我们web常见的官网，论坛是适合用mpa来做；移动端适合用spa来做；

SSR服务端渲染是什么？

在了解SSR需要了解浏览器部分的页面解析过程(下文就有)，SSR对应的是CSR，CSR即客户端渲染，在我们现在前端中，通常都是把HTML渲染，然后在渲染过程中去加载css和js，此时的HTML因为css和js可能没加载完会出现白屏，此时的HTML组装方式是在客户端。那SSR服务端渲染目前的模式是由服务端将css和js进行处理，然后纯粹的返回给客户端一个完整的html模板，此时HTML组装方式是在服务端。那么SSR和CSR各有什么优缺点呢？在我们了解spa的时候就讲到了SEO的例子，那么这边在延申一下，爬虫也分为高级和低级，目前百度谷歌等爬虫库里面存在着很多低级爬虫，低级爬虫只能爬解析url之后的HTML页面，而客户端渲染的spa应用返回的htm都是空的，所以只有高级爬虫才会对js和css文件进行加载然后爬取，所以SEO收录是spa的一个痛点。如果我们开启服务端渲染，那SEO的问题虽然会迎刃而解，但是要在服务端进行HTML的处理势必会造成大量的计算，开销/投入产出比都是我们应该考虑的。

等待补充，同构（即SSR和CSR共存）

浏览器和工程化

HTTP2带来了什么对于前端？

等待补充

输入一个URL到页面呈现中间经历了什么？

1. 解析URL
2. 查看浏览器中的缓存
3. DNS解析
4. 建立TCP/IP连接
5. 发送HTTP请求
6. 服务端处理请求返回报文
7. 浏览器解析HTML成DOM树
8. 异步解析css外链成css规则树
9. 遇到script标签，同步执行（分async和defer进行异步加载）
10. 将DOM树和css规则树构造成render树
11. 渲染render树

你如何去架构一个新的前端项目？

等待补充

浏览器如何优化重排和重绘的？

等待补充

如何在浏览器中进行标签页面的通信呢？

postmessage，等待补充

跨域（其实这题应该不会问了）是怎么造成的

等待补充

有开发过浏览器插件么？

我答的很好，但是之后会补充这一块

有了解过微前端么？

我答的很好，但是之后会补充这一块

有了解过serverless么？

我答的很好，但是之后会补充这一块