2026.08.21-字节抖电前端一面面经与复盘

八股

HTTP响应码

• 1xx信息响应
  • 100 Continue：客户端在POST大量数据之前先询问是否可以发送，此时服务器返回100意为准许发送
  • 101 Switching Protocols：协议切换，例如在使用WebSocket建立长连接时，HTTP握手阶段服务器就会返回101，表示接下来使用WebSocket通信
  • 102 Processing：DAV协议扩展，表示服务器已收到并正在处理该请求，但是当前没有响应可用
  • 103 Early Hints：用于让浏览器预连接站点或者预加载资源，消除服务器在准备响应数据时的空闲网络等待
• 2xx成功响应：
  • 200 OK：标准的成功响应
  • 201 Created：成功且创建了新资源，例如POST增加了新用户的时候，规范做法即为返回201
  • 202 Accepted：表示请求已被成功接收，但可能未处理完成或者尚未开始处理，并不承诺结果，相关任务操作仍可能失败或被拒绝
  • 203 Non-Authoritative Information：表示请求成功，但是返回的成功响应头已经被中间代理篡改或者替换过。但在实际开发中通常仍是用200 OK，只是在响应头中添加一个Warning: 214字段表示相同语义
  • 204 No Content：请求成功，但是响应体内没有数据，常用于DELETE请求
  • 205 Reset Content：用于重置用户端的文档，比如当用户发送表单内容后，服务端返回205以表示表单需重置
  • 206 Partial Content：当从客户端发送Range范围标头以只请求数据的一部分时，使用该响应码。例如请求一个2GB的视频文件，如果整个请求，将会消耗大量时间用于完整下载，而使用Range标头则可以定向请求对应区间；同样可以应用于大文件断点续传、多线程/分块并行下载
  • 207 Multi-Status：DAV协议扩展，用于在一次响应中返回对多个独立资源的不同操作结果，例如请求a.txt成功返回200 OK，请求b.jpg未找到返回404 Not Found，这些响应结果在207响应的请求体中呈现
  • 208 Already Reported：DAV协议扩展，与207响应结合使用，当多次使用不同的路径请求相同资源时，只有第一次请求会返回200 OK，而其他请求会在207响应的响应体中响应208状态码，不会产生冲突且响应时间更短
  • 226 IM Used：用于实现增量传输，比如当客户端本地已有旧版本缓存，发GET请求时带上对应响应头，服务器若发现该文件已经改变，且支持增量计算，于是只计算并返回对应Diff补丁，客户端再在本地合成出新的完整文件，但由于用服务器算力换流量不划算，且大部分主流浏览器以及中间代理并没有对应实现，以及应用层有更好的实现，所以实际中使用较少
• 3xx重定向消息：
  • 300 Multiple Choices：表示请求资源有多个候选版本，交还给客户端进行选择，服务器可以通过生成一个Location首部用于提供一个优先选择
  • 301 Moved Permanently：永久重定向，资源彻底迁移
  • 302 Found：表示请求资源的URI已经暂时更改，但是不将原有URL的SEO值传给新的URL
  • 303 See Other：与302类似，只是强制了客户端需要使用GET去请求新的URL
  • 304 Not Modified：协商缓存，当请求资源未改变时，返回304响应
  • 305 Use Proxy：用于指定应当使用对应代理，但由于安全和设计问题已被废弃
  • 306：保留字
  • 307 Temporary Redirect：与302类似，但是用户代理不能修改请求方法
  • 308 Permanent Redirect：与301类似，但是用户代理不能修改请求方法
• 4xx客户端错误响应：
  • 400 Bad Request：表示服务器认为对应请求是出于客户端的错误，例如语法错误、无效请求消息格式或者欺骗性请求路由从而无法处理该请求作出的响应
  • 401 Unauthorized：真实含义应为Unauthenticated即未经身份验证，例如没有凭证、凭证无效或者过期、格式错误
  • 402 Payment Required：保留以供将来使用，最初目的是用于构建数字支付系统，但是较少使用且无标准约定
  • 403 Forbidden：与401不同，此时服务器知道客户端的身份，但是没有权限访问对应资源
  • 404 Not Found：找不到请求的资源
  • 405 Method Not Allowed：目标资源不支持该方法，例如API可能不允许调用DELETE删除资源
  • 406 Not Acceptable：客户端发送请求时可以在请求头中写明自己能够接收什么格式/语言/编码，但是服务端无法提供所要求的资源格式时，返回该响应码
  • 407 Proxy Authentication Required:类似401，区别在于此响应码代表代理服务器未验证
  • 408 Request Timeout：表示服务器想要将某个没有在使用的连接关闭
  • 409 Conflict：表示请求与服务器当前的资源状态冲突，拒绝执行。例如唯一用户名约束，尝试向数据库中插入一个新用户，但是该用户名已被使用，服务端返回409
  • 410 Gone：请求内容已在服务器中被永久删除且没有转发地址。将返回此响应，客户端删除对应缓存和指向内容的链接
  • 411 Length Required：Content-Length字段未在请求中定义但是服务端需要它
  • 412 Precondition Failed：当请求头中的条件不满足时服务端返回该响应码，用于解决并发冲突和盲目覆盖
  • 413 Payload Too Large：请求实体大于服务器定义的限制
  • 414 URI Too Long：URI过长
  • 415 Unsupported Media Type：不支持请求的媒体格式
  • 416 Range Not Satisfiable：无法满足请求中Range标头字段指定的范围
  • 417 Expectation Failed：表示服务端无法满足Expect请求标头字段所指示的期望
  • 418 I’m a teapot：保留的愚人节彩蛋^^
  • 421 Misdirected Request：错误地将请求发送给了一个不应该响应该请求的服务器
  • 422 Unprocessable Entity：DAV协议扩展，请求格式正确，但是语义错误，区别于400，它更接近业务级校验
  • 423 Locked：DAV协议扩展，资源已锁定
  • 424 Failed Dependency：DAV协议扩展，前一个请求失败导致该请求失败
  • 425 Too Early：表示服务器不愿冒险处理可能被重播的请求
  • 426 Upgrade Required：服务端拒绝使用当前协议执行请求，但升级到其他协议后可能愿意
  • 428 Precondition Required：服务端要求发送条件请求
  • 429 Too Many Requests：给定时间内发送太多请求
  • 431 Request Header Fields Too Large：请求头太大
  • 451 Unavaliable For Legal Reasons：请求了无法合法提供的资源
• 5xx服务端错误响应：
  • 500 Internal Server Error：服务器遇到了不知道如何处理的情况
  • 501 Not Implemented：服务器不支持对应的请求方法，服务器必须支持的请求方法只有GET和HEAD
  • 502 Bad Gateway：在这种情况下，所请求的服务器充当一个中间人的角色，去请求对应的后端应用时未获得合法响应
  • 503 Service Unavaliable：服务器当前服务不可用，可能为服务器正在停机维护或者已超载
  • 504 Gateway Timeout：当请求服务器充当网关且无法及时获得响应时返回该响应码
  • 505 HTTP Version Not Supported：HTTP版本不支持
  • 506 Varient Also Negotiates：服务器内部配置错误，所选变体资源被配置为参与透明内容协商本身
  • 507 Insufficient Storage：DAV协议扩展，无法在该资源上执行该方法，表示服务器资源耗尽
  • 508 Loop Detected：DAV协议扩展，在处理请求时检测到无限循环
  • 510 Not Extended：在客户端请求声明了应使用HTTP扩展来处理请求，但服务器不支持该扩展时发送
  • 511 Network Authentication Required：表示请求在局域网处被拦截，需要先进行网络登录

这里面重点有200, 204, 206, 301, 302, 304, 400, 401, 403, 404, 409, 429, 500, 502, 504，也许以后会用另外一篇文章深入研究一下

HTTP/2相较于HTTP/1.1的优势

大致可以分为下面四个方面：

在HTTP/1.1中，报文由纯文本的Header以及二进制体混合组成，针对纯文本报头的解析既容易出错效率又低，于是在HTTP/2引入了二进制分帧

HTTP/2在应用层的HTTP以及传输层的TCP中间引入了一个二进制分帧层，此时对于原来的应用层，仍然处理请求和响应

而分帧层则将所有的传输内容包括报头和消息体拆分成一个个极小的二进制帧，这些帧的种类有多种，包括HEADERS和DATA之类

同时HTTP/2引入了 流(Stream) 的概念，这也是实现多路复用的核心

HTTP/2的每个帧都有固定的9字节帧头，大致结构如下：

关于流，可以认为它是HTTP/2中单个TCP连接中的一个专属虚拟通道，来自不同响应/请求的帧都在同一个TCP连接上传输，每个帧又拥有唯一的Stream ID，接收端通过ID重新拼装，从而实现了多路复用，解决了原来的队头阻塞问题

关于HPACK标头压缩算法，它的核心机制大致可以分为三大部分

• 静态表：RFC规范预定义的一个只读查表，包含61个常用键对，例如索引2代表:method: GET
• 动态表：在连接建立后，客户端和服务端各自在内存中维护一份状态字典，双方在传输过程中，把出现过的非静态表Header追加到动态表中，采用FIFO淘汰策略
• 霍夫曼编码：对于表内没有的全新字符串，HAPCK使用针对HTTP Header预先训练好的固定霍夫曼树进行比特级压缩

关于HPACK，会用另一篇文章详细讲解

CSSem和px的区别

• px：绝对单位，1px就是一个像素点
• em：相对单位，大小计算基于父元素或者自身的font-size

对于px，它其实并不是物理意义上的像素点，而是逻辑像素，在移动端或者Retina高分屏下，1px对应的是设备独立像素(DIP)

em具有双重参照机制：

• 当用在font-size时，参照的是父元素的font-size
• 用在非字体属性上的时候，比如padding, margin之类，参照的是当前元素自身的font-size

同时em具有缺陷，即嵌套滚雪球效应，假设有下面的HTML代码：

<div class="level-1"> <!-- font-size: 1.2em (16px -> 19.2px) -->
  <div class="level-2"> <!-- font-size: 1.2em (19.2px * 1.2 = 23.04px) -->
    <div class="level-3"> <!-- font-size: 1.2em (23.04px * 1.2 = 27.648px) -->
      文字发生膨胀
    </div>
  </div>
</div>

只要多层组件嵌套，font-size就会以指数级的方式放大或者缩小，导致样式不可预测

于是后来引入了rem，以根节点<html>的font-size为基准的大小属性

最后把各种单位拉出来对比一下