# 第185题什么是服务器端渲染（SSR）？SSR 的原理是什么

服务器端渲染 (SSR) 是一种网页渲染技术，它在服务器端生成完整的 HTML 页面，然后将页面发送给浏览器。与客户端渲染 (CSR) 不同，SSR 在服务器端完成页面渲染，浏览器只需解析和显示 HTML 页面即可。

SSR 的工作原理：当用户请求一个页面时，服务器会执行以下步骤：

获取页面数据和模板。
使用数据和模板生成完整的 HTML 页面。
将 HTML 页面发送给浏览器。
浏览器解析和显示 HTML 页面。

SSR 的优势：

更快的首屏加载速度：由于浏览器无需等待 JavaScript 下载和执行，SSR 可以提供更快的首屏加载速度。
更好的 SEO：搜索引擎可以更容易抓取和索引 SSR 生成的页面，从而提高网站的 SEO 排名。
更易于访问： SSR 生成的页面无需 JavaScript 即可访问，这对于禁用 JavaScript 的用户或低带宽连接的用户来说非常有用。

流式渲染是指将 HTML 文档分块传输给客户端，客户端收到每一段内容时进行分批渲染。与一次性发送整个 HTML 文档相比，流式渲染可以更早地向用户展示内容，提升页面加载速度和用户体验。

流式渲染适用于各种需要快速展示内容的场景，例如：

大型电商网站的商品列表页面
社交媒体的动态消息流
实时数据更新的仪表盘

流式渲染可以通过多种技术实现，例如：

HTTP/1.1 的分块传输编码
WebSockets

# 第184题假如有几十个请求，如何去控制并发

众所周知，浏览器发起的请求最大并发数量一般都是6~8个，这是因为浏览器会限制同一域名下的并发请求数量，以避免对服务器造成过大的压力

首先让我们来模拟大量请求的场景

const ids = new Array(100).fill('')

console.time()
for (let i = 0; i < ids.length; i++) {
  console.log(i)
}
console.timeEnd()

@前端进阶之旅: 代码已经复制到剪贴板

一次性并发上百个请求，要是配置低一点，又或者带宽不够的服务器，直接宕机都有可能，所以我们前端这边是需要控制的并发数量去为服务器排忧解难

什么是队列？

先进先出就是队列，push一个的同时就会有一个被shift。我们看下面的动图可能就会更加的理解：

我们接下来的操作就是要模拟上图的队列行为

定义请求池主函数函数

export const handQueue = (
  reqs // 请求数量
) => {}

@前端进阶之旅: 代码已经复制到剪贴板

接受一个参数reqs，它是一个数组，包含需要发送的请求。函数的主要目的是对这些请求进行队列管理，确保并发请求的数量不会超过设定的上限

定义dequeue函数

const dequeue = () => {
  while (current < concurrency && queue.length) {
    current++
    const requestPromiseFactory = queue.shift() // 出列
    requestPromiseFactory()
      .then(() => {
        // 成功的请求逻辑
      })
      .catch((error) => {
        // 失败
        console.log(error)
      })
      .finally(() => {
        current--
        dequeue()
      })
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

这个函数用于从请求池中取出请求并发送。它在一个循环中运行，直到当前并发请求数current达到最大并发数concurrency或请求池queue为空。对于每个出队的请求，它首先增加current的值，然后调用请求函数requestPromiseFactory来发送请求。当请求完成（无论成功还是失败）后，它会减少current的值并再次调用dequeue，以便处理下一个请求

定义返回请求入队函数

return (requestPromiseFactory) => {
  queue.push(requestPromiseFactory) // 入队
  dequeue()
}

@前端进阶之旅: 代码已经复制到剪贴板

函数返回一个函数，这个函数接受一个参数requestPromiseFactory，表示一个返回Promise的请求工厂函数。这个返回的函数将请求工厂函数加入请求池queue，并调用dequeue来尝试发送新的请求，当然也可以自定义axios，利用Promise.all统一处理返回后的结果。

实验

const enqueue = requestQueue(6) // 设置最大并发数
for (let i = 0; i < reqs.length; i++) {
  // 请求
  enqueue(() => axios.get('/api/test' + i))
}

@前端进阶之旅: 代码已经复制到剪贴板

我们可以看到如上图所示,请求数确实被控制了，只有有请求响应成功的同时才会有新的请求进来，极大的降低里服务器的压力

// 全部代码
export const handQueue = (
  reqs // 请求总数
) => {
  reqs = reqs || []

  const requestQueue = (concurrency) => {
    concurrency = concurrency || 6 // 最大并发数
    const queue = [] // 请求池
    let current = 0

    const dequeue = () => {
      while (current < concurrency && queue.length) {
        current++
        const requestPromiseFactory = queue.shift() // 出列
        requestPromiseFactory()
          .then(() => {
            // 成功的请求逻辑
          })
          .catch((error) => {
            // 失败
            console.log(error)
          })
          .finally(() => {
            current--
            dequeue()
          })
      }
    }

    return (requestPromiseFactory) => {
      queue.push(requestPromiseFactory) // 入队
      dequeue()
    }
  }

  const enqueue = requestQueue(6)

  for (let i = 0; i < reqs.length; i++) {
    enqueue(() => fetch.get('/api/test' + i))
  }
}

@前端进阶之旅: 代码已经复制到剪贴板

# 第183题 Hooks闭包陷阱问题

import { useEffect, useState } from 'react'

function App() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    setInterval(() => {
      console.log(count)
      setCount(count + 1)
    }, 1000)
  }, [])

  return <div>{count}</div>
}

export default App

@前端进阶之旅: 代码已经复制到剪贴板

通过定时器不断的累加 count，setCount 时拿到的 count 一直是 0。useEffect 的依赖数组是 []，也就是只会执行并保留第一次的 function。而第一次的 function 引用了当时的 count，形成了闭包，这就是闭包陷阱问题

解法1

useEffect(() => {
  setInterval(() => {
    // 每次的 count 都是参数传入的上一次的 state，没有形成闭包
    setCount((count) => count + 1)
  }, 1000)
}, [])

@前端进阶之旅: 代码已经复制到剪贴板

解法2

useEffect(() => {
  console.log(count)

  const timer = setInterval(() => {
    setCount(count + 1)
  }, 1000)

  return () => {
    clearInterval(timer)
  }
}, [count])

@前端进阶之旅: 代码已经复制到剪贴板

依赖数组加上了 count，这样 count 变化的时候重新执行 effect，那执行的函数引用的就是最新的 count 值。

解法3

const updateCount = () => {
  setCount(count + 1)
}
const ref = useRef(updateCount)

ref.current = updateCount

useEffect(() => {
  const timer = setInterval(() => ref.current(), 1000)

  return () => {
    clearInterval(timer)
  }
}, [])

@前端进阶之旅: 代码已经复制到剪贴板

通过 useRef 创建 ref 对象，保存执行的函数，每次渲染更新 ref.current 的值为最新函数。

这样，定时器执行的函数里就始终引用的是最新的 count。

useEffect 只跑一次，保证 setIntervel 不会重置，是每秒执行一次。

执行的函数是从 ref.current 取的，这个函数每次渲染都会更新，引用着最新的 count。

# 第182题 Suspense 有哪些使用场景，使用 Suspense 的好处有哪些？

使用场景有：

Suspense + lazy
Suspense + 异步数据加载
Suspense + use
Suspense + useTransition
Suspense + streaming

好处有：

更优雅的写法。使用 Suspense 可以避免写出下面这种代码：

function App() {
  // 其它逻辑
  if (loading) {
    return <Loading />
  }
  return xxx
}

@前端进阶之旅: 代码已经复制到剪贴板

解决 Race Condition 问题：React Suspense 天然可以解决 Race Condition，这来源于两部分原因：
- 1. 当异步请求发生时 UI 会立即渲染 fallback 状态；
- 1. 数据请求与组件渲染逻辑分离。
更好的性能：通常我们会将异步请求写在 useEffect 中，这需要等待渲染结束后才会发出请求，而使用 Suspense 可以把这部分前置到渲染时。
更好的用户体验：借助 useTransition 和 Suspense 可以降低此次的更新优先级以及延迟渲染，这样可以避免卡顿以及带来更好的用户体验。
流式渲染：Suspense 允许推迟某些内容的渲染，直到数据加载完毕。这样使得页面加载更快，无需等到数据准备好即可开始渲染和 hydration，降低 TTFB、FCP、TTI 等性能指标，从而用户可以更早地看到内容和进行交互

# 第181题怎么理解 React 并发更新特性

并发更新是 React18 最主要的特性，同时由于并发机制的特性给社区带来了新的活力，当然也产生了一些新的问题，例如 React Tearing。

为什么我们需要并发更新？

我们看的电影和动画是由许多静态图像（帧）快速播放组成的，人眼的反应速度有限，当这些帧足够快地切换时，我们看到的就是流畅的动画。对于人眼来说，大约 16-24 帧/秒就足以形成连续动画的感觉，但更高的帧率会提供更流畅、自然的效果。

因此我们需要并发更新，也就是把连续的、不可中断的执行过程变成一小块、一小块的切片去执行，那在执行空隙期间自然有机会得到渲染。

同时在渲染的间隙我们也有机会去判断渲染优先级，从而优先执行高优先级的任务。

# 第185题 什么是服务器端渲染（SSR）？SSR 的原理是什么

# 第184题 假如有几十个请求，如何去控制并发

# 第183题 Hooks闭包陷阱问题

# 第182题 Suspense 有哪些使用场景，使用 Suspense 的好处有哪些？

# 第181题 怎么理解 React 并发更新特性

# 第185题什么是服务器端渲染（SSR）？SSR 的原理是什么

# 第184题假如有几十个请求，如何去控制并发

# 第181题怎么理解 React 并发更新特性

前端高频面试题-每日一题

前端高频面试题-每日一题