用户可能输入关键词：

苹果 手机

也可能直接表达需求：

推荐 5 款 2000 元以内的大存储苹果手机

这里面既有品牌、品类、价格、数量，也有“大存储”这种偏好。如果只靠关键词匹配，很容易漏掉用户真正想要的东西。

商品搜索通常可以分成三个阶段：

• 模糊搜索：提供稳定、可控的检索和筛选能力
• AI 结构化搜索：降低用户表达成本，提升搜索效率
• AI 结构化 + 向量库搜索：解决语义召回和 RAG 回答

一、模糊搜索：稳定可控的基础搜索​

模糊搜索不只是简单的关键词包含匹配。一个成熟的模糊搜索系统，本身也可以支持筛选、排序、分页、价格区间、品牌过滤、类目过滤等能力。

比如用户可以先搜索：

苹果 手机

再通过筛选条件缩小范围：

品牌：苹果
价格：2000 元以内
排序：价格从低到高
规格：大存储

这些能力并不依赖 AI。传统搜索系统完全可以通过规则、表单、筛选器和排序器完成，而且通常更稳定、更快、更可控。

模糊搜索的优点是：

• 简单
• 快
• 成本低
• 可解释
• 行为稳定
• 适合承接确定性过滤和排序

它真正的问题不是“不能筛选排序”，而是用户必须用系统能理解的方式表达需求。

比如：

• 用户要知道去哪里点价格筛选
• 用户要把多个条件拆开输入
• 用户要理解“排序”和“筛选”的区别
• 用户要不断调整关键词，才能逼近想要的结果

所以模糊搜索不是能力弱，而是交互成本高。它适合做底层检索能力，但不一定是最高效的用户入口。

二、AI 结构化搜索：提升搜索效率​

引入 AI 结构化搜索，主要不是为了证明传统搜索不行，而是为了让用户少操作几步。

用户不用再手动拆条件、点筛选、调排序，而是可以直接说完整需求。

例如：

推荐 5 款便宜点的苹果手机

可以被理解成：

这样，“5 款”就不再是关键词，而是返回数量；“便宜点”也不再是普通文本，而是排序偏好。

AI 在这里更像一个自然语言入口。它把用户一句话拆成系统可以执行的条件，再交给搜索、过滤和排序模块处理。

���提升的是：

• 输入效率：用户一句话表达多个条件
• 理解效率：系统自动识别数量、品牌、价格和偏好
• 交互效率：用户可以继续追问和修改条件

比如用户上一轮说：

推荐几款苹果手机

下一轮只说：

便宜点

系统如果能理解上下文，就应该在上一轮“苹果手机”的基础上调整排序或价格偏好，而不是把“便宜点”当成一次全新的搜索。

这就是 AI 搜索真正有价值的地方：它让搜索从“用户操作筛选器”变成“用户和系统对话”。

但它仍然有边界：AI 负责理解和转译，不应该替代底层搜索逻辑。

比如用户说：

apple 手机

模型可能理解出品牌是 Apple。但如果商品数据里品牌存的是“苹果”，普通文本匹配仍然可能搜不到。

所以 AI 结构化解决的是“查询理解”，不是“语义召回”。

向量概念​

举个例子，计算机如何理解“猫”和“狗”这两个词？

如果直接给它们编个号（猫=1，狗=2，汽车=3），计算机会认为 3 和 2 很近，从而得出“汽车和狗很像”的荒谬结论。为了解决这个问题，我们需要嵌入（Embedding）。

嵌入，就是把现实世界中离散的、人类能理解的实体（词语、图片、商品），映射（压紧）到一个连续的高维数字向量空间中的过程。

AI 模型的“嵌入层”会通过学习海量数据，自动给每个词分配几百甚至上千个特征维度（比如：是否有生命、体型大小、是否是宠物、是否会飞……）。

猫 可能会被转换成：[0.9, 0.2, 0.95, -0.8, ...]

狗 可能会被转换成：[0.85, 0.4, 0.98, -0.75, ...]

汽车 可能会被转换成：[-0.9, 0.8, -0.9, 0.1, ...]

你会发现，在 AI 自动提取的特征中，“猫”和“狗”的数字非常接近，而“汽车”和它们相差十万八千里。

向量搜索关注的不是两个文本是否完全一样，而是语义是否接近。

它依赖 embedding。embedding 可以把一段文本转换成一组数字，这组数字就叫向量。

可以把向量理解成文本在“语义空间”里的坐标。

普通地图里，一个地点可以用经纬度表示。两个地点的经纬度越接近，说明它们在地理位置上越近。

向量也是类似的思路：一段文本会被放到一个高维语义空间里。两个文本的向量越接近，通常说明它们表达的意思越接近。

这里的“接近”不是字符串接近，而是语义接近。

三、向量搜索：解决字面不同但意思接近​

比如在商品搜索语境下：

• 苹果手机
• Apple 手机
• iPhone 手机
• 苹果品牌智能手机

这些表达字面不同，但都和“苹果品牌的手机”有关，所以可能被映射到相近的向量位置。

而下面这些表达：

• 苹果手机
• 机械键盘
• 羽绒服
• 保温杯

它们对应的商品类型不同，语义距离就会更远。

向量搜索做的事情，就是把用户问题也转换成向量，然后在商品向量里找距离最近的一批。

它不是问：

商品文本里有没有出现这个词？

而是问：

哪些商品和这个问题表达的意思最接近？

向量库负责存储商品向量。搜索时，用户问题也会被转换成查询向量，然后系统去找距离最近的商品。

这就是为什么“Apple 手机”有机会召回“苹果手机”。不是因为系统建立了 Apple 等于苹果的硬规则，而是因为 embedding 模型认为它们在当前语境下相似。

所以向量搜索的优势是召回更宽：同义词、跨语言、口语化表达都有机会命中。

但它的风险也在这里：相似不等于严格满足。价格、品牌、库存、规格这类硬条件，仍然要靠过滤规则保证。

四、RAG：让模型基于真实数据回答​

当向量搜索和生成式 AI 结合起来，就形成了 RAG。

RAG 可以拆成三步：

在商品搜索里，RAG 的重点不是让模型凭空推荐，而是让模型基于真实商品结果回答。

这点很重要。否则模型可能会编造不存在的商品、价格或规格。

RAG 的价值在于：召回由数据负责，表达由模型负责。

五、三种方案对比​

可以简单理解为：

• 模糊搜索解决“怎么稳定地查、筛、排”
• AI 结构化解决“怎么让用户更快表达需求”
• 向量搜索解决“意思像不像”

六、向量搜索不是万能的​

向量搜索适合处理：

• 相似商品
• 模糊需求
• 口语表达
• 中英文混合
• 同义词和近义词

但它不适合单独处理强约束：

• 价格必须小于 3000
• 品牌必须是苹果
• 存储必须是 512GB
• 只返回 5 条
• 只看有库存的商品

这些条件应该交给确定性过滤，而不是完全依赖向量相似度。

更稳的方式是分层：

七、一个更完整的购物助手还缺什么​

搜索只是第一步。真正好用的购物助手还需要补齐几类能力。

1. 完整意图处理​

用户不只会搜索，还会筛选、排序、对比、追问、解释和重置。

比如：

便宜点

这不是一个全新的搜索，而是对上一轮结果继续筛选。

第二款和第四款比一下

这也不是重新搜索，而是基于上一轮结果做对比。

系统要能判断用户是在开启新任务，还是继续修改当前任务。

2. 上下文记忆​

多轮购物对话需要记住三类信息：

• 当前查询条件：品牌、价格、规格、数量
• 上一轮结果：哪些商品排在第几位
• 用户偏好：预算、品牌倾向、是否偏好大存储

有了这些记忆，系统才能理解“这个”“第二款”“再便宜点”“换个品牌”这类表达。

3. 条件继承和覆盖​

用户连续输入时，系统要判断条件是新增、覆盖还是删除��

例如：

推荐苹果手机
2000 以内

这里应该继承“苹果手机”，追加“价格小于 2000”。

但如果用户说：

算了，看看小米

这更像是把品牌从苹果切换成小米。

4. 标准化​

用户表达和商品数据经常不一致：

• Apple、iPhone、苹果
• 512G、512GB
• 2k、2000 元、两千
• 手机、智能手机

如果系统内部没有标准词表，查询会不稳定。

标准化的目标是：用户可以用不同方式表达，但系统内部尽量落到统一的品牌、类目、规格和价格结构。

5. 无结果降级​

没有结果时，不应该只说“没找到”。

更好的回答是指出可能原因，并给出放宽建议：

没有找到 2000 元以内的大存储苹果手机。可以放宽到 3000 元以内，或者保留预算但改看其他品牌。

这比单纯报空更像助手。

6. 结果质量评估​

AI 搜索不能只看回答是否流畅，还要看结果是否满足约束。

可以关注：

• 价格有没有超预算
• 品牌有没有跑偏
• 规格是否满足
• 排序是否合理
• 推荐理由是否来自真实商品信息

RAG 的质量很大程度取决于召回和过滤，而不是最后那段文字。

八、推荐的演进路径​

如果从零构建，可以按这个顺序推进：

1. 先做模糊搜索，保证基础搜索可用。
2. 加 AI 结构化，理解自然语言里的条件。
3. 把品牌、价格、规格、库存交给硬过滤。
4. 引入 embedding 和向量库，增强语义召回。
5. 加上下文记忆，支持连续追问、筛选和对比。
6. 补齐标准化、降级策略和结果评估。
7. 最后用 RAG 把结果组织成自然语言回答。

每一步都解决一个明确问题，不要一开始就把所有复杂度堆在一起。

总结​

商品搜索的演进，本质上不是简单地用 AI 替代传统搜索，而是在传统搜索的稳定能力上，补上自然语言交互和语义召回。

模糊搜索让系统稳定地完成检索、筛选和排序。

AI 结构化搜索让用户更快表达需求，并支持连续追问。

向量搜索让系统能找到语义相近的商品。

RAG 让模型基于真实商品结果组织回答。

职责边界要清楚：

• 数据库和过滤器负责确定性条件
• 向量库负责语义召回
• 生成式模型负责理解意图和组织表达

这样系统才会既聪明，又可控。

RSC（React Server Components）是 React 官方提出的一种组件模式，它允许一部分组件在服务器上运行，而不是在浏览器里运行。

它的目标是更快的加载、更小的 JS 体积，同时保留 React 的组合式开发体验。

回顾 CSR（客户端渲染）​

<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

这个 bundle.js 脚本包含我们安装和运行应用程序所需的全部代码，包括 React、其他第三方依赖项以及自己编写的所有代码。

一旦 JS 被下载并解析，React 就会开始执行，为我们的整个应用程序生成所有的 DOM 节点，并放在那个空的<div id="root">.

这种方法的问题在于，执行期间需要很多时间。所以在此期间，用户只能盯着一片空白的屏幕。这个问题会随着时间的推移而变得更加严重：我们发布的每个新功能都会给 JavaScript 包增加更多构建 size，从而延长用户等待的时间。

回顾 SSR (服务端渲染)​

服务器端渲染旨在提升用户体验。其核心就是，所有的渲染相关的js（期望上，某些第三方包并未支持需强制使用客户端渲染）都是在服务端先渲染好静态html模板（通过React/Vue 对应的各自 server 端的工具库），然后再统一发送到浏览器客户端，用户收到的是一个完整的 HTML 文档，而不需要等待js加载的白屏过程。

<!DOCTYPE html>
<html>
  <body>
    <div id="root">
  		<button>Click me</button>
    </div>
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

但同时由于服务端返回的是纯html字符串，服务器无法处理绑定 onClick 等交互事件，因此此时整个页面是无法交互的。

所以 HTML 文件依然包含 <script> 标签，因为我们仍需要在客户端运行 React 来处理这些交互。但它不再从头生成所有 DOM 节点，而是采用现有的 HTML。这个过程称为**“水合”** （hydration）[/hai'dreiʃən/]。

完整水合过程​

1. 重建虚拟 DOM → 浏览器执行 React/Vue 代码，生成虚拟 DOM 树。
2. 对比现有 HTML → 检查 SSR 的 HTML 跟虚拟 DOM 一致不一致。（不一致则发出警告）
3. 绑定事件 → 给按钮、输入框等加上交互能力。

*Hydration 就像用交互性和事件处理程序的“水”来浇灌“干燥的” HTML。

这就是 SSR 的精髓。服务器端生成初始 HTML，这样用户在下载和解析 JS 包时就不必面对空白页面。然后，客户端 React 会接续服务器端 React 的进度，采用 DOM 并添加一些交互功能。

SSG（静态站点生成）​

当我们谈论服务器端渲染时，我们通常会想象这样的流程：

1. 用户访问 test.com。
2. Node.js 服务器接收请求，并立即呈现 React 应用程序，生成 HTML。
3. 刚刚生成的 HTML 被发送到客户端。

这是实现服务器端渲染的一种可能方法，但不是唯一的方法。另一种选择是在构建应用程序时生成 HTML。

通常，React 应用程序需要编译，将 JSX 转换为纯 JavaScript，并打包所有模块。如果在同一过程中，我们为所有不同的路由“预渲染”所有 HTML，会怎么样？

这通常被称为 静态站点生成（SSG） 。它是服务器端渲染的另一种方式。

与 SSR 不同的是，SSG 在构建阶段就生成静态 HTML，用户访问时直接拿到现成文件，不需要服务器每次渲染，如果有数据请求，则在构建阶段就提前获取并渲染好。

因此也无法实现动态数据了，如需变更数据，需要重新构建。适合数据变更不太频繁的站点，例如博客，文档，官网，营销页面等。

CSR/SSR 反复横跳​

csr​

客户端优化方式，数据获取之前，添加加载 Loading，直到请求完成并且 React 重新渲染，用真实内容替换加载 UI。

ssr​

在这个新流程中，我们在服务器上执行第一次渲染。用户收到的 HTML 文件并非完全为空。

这算是一种改进——有壳总比空白页好——但最终，它并没有带来什么显著的改变。用户访问我们的应用不是为了看加载页面，而是为了查看内容（商品列表、搜索结果、消息等等）。

通过在服务器上进行初始渲染，我们可以更快地绘制初始“外壳”。这可以让加载体验感觉更快一些，因为它提供了一种进度感，让玩家感觉事情正在发生。

在某些情况下，这将是一个有意义的改进。例如，用户可能只是在等待标题加载，以便他们可以点击导航链接。

但是这个流程是不是感觉有点繁琐？ SSR 图表里，仔细发现会注意到请求是从服务器开始的。与其要求第二次往返网络请求，为什么不在初始请求期间就完成数据库查询操作呢？

换句话说，为什么不能这样呢？

不在客户端和服务器之间来回跳转，而是将数据库查询作为初始请求的一部分，将完全填充的 UI 直接发送给用户。

但是，我们究竟该怎么做呢？

生态系统已经针对这个问题提出了很多解决方案。 元框架？像 Next.js 和 Gatsby 已经创建了自己的方式，可以在服务器上专门运行代码。

例如，使用 Next.js（使用旧版 "Page" 路由）时如下所示：

import db from 'mysql';

// 这段代码只运行在服务端
export async function getServerSideProps() {
  const link = db.connect('localhost', 'root', 'passw0rd');
  const data = await db.query(link, 'SELECT * FROM products');

  return {
    props: { data },
  };
}

// 这段代码在服务端和客户端都会运行
export default function Homepage({ data }) {
  return (
    <>
      <h1>Trending Products</h1>

      {data.map((item) => (
        <article key={item.id}>
          <h2>{item.title}</h2>
          <p>{item.description}</p>
        </article>
      ))}
    </>
  );
}

分解一下： 当服务器收到请求时， getServerSideProps 函数会被调用。它返回一个props对象。这些 props 随后被传入组件，组件首先在服务器上渲染，然后在客户端进行 水合。

这里的巧妙之处在于它 getServerSideProps 不会在客户端重新运行。事实上，这个函数甚至没有包含在我们的 JavaScript 包中！

这种方法在当时非常超前。但它也有一些缺点：

1. 此策略仅适用于路由级别，适用于树最顶端的组件。我们无法在任何组件中执行此操作。
2. 每个元框架都提出了自己的方法。Next.js 有一种方法，ReactRouter 有另一种方法，Remix 又有另一种方法。它们尚未标准化。
3. 我们的所有 React 组件都将始终*在客户端上进行水合，就算它们不需要这样做（无需交互页面）。

多年来，React 团队一直在默默地研究这个问题，试图找到一个官方的解决方案。他们的解决方案叫做 React Server Components。

React 服务器组件简介​

从高层次上讲，React 服务器组件代表着一种全新的规范。在这个环境下，我们可以创建专门在服务器上运行的组件。这使我们能够在 React 组件内部执行诸如编写数据库查询之类的操作！

以下是“服务器组件”的简单示例：

import db from 'mysql';

async function Homepage() {
  const link = db.connect('localhost', 'root', 'passw0rd');
  const data = await db.query(link, 'SELECT * FROM products');

  return (
    <>
      <h1>Trending Products</h1>
      {data.map((item) => (
        <article key={item.id}>
          <h2>{item.title}</h2>
          <p>{item.description}</p>
        </article>
      ))}
    </>
  );
}

export default Homepage;

这段代码一开始对一个前端开发者来说看起来应该很疯狂

**需要理解的关键点是：**服务器组件永远不会重新渲染。它们在服务器上运行一次以生成 UI。渲染后的值会发送到客户端并锁定在原地。就 React 而言，此输出是不可变的，永远不会改变。

这意味着React 的很大一部分 API 与服务器组件不兼容。例如，我们不能使用 state，因为 state 可以改变，但服务器组件无法重新渲染。我们也不能使用 effect，因为 effect 只能在渲染之后在客户端运行，而服务器组件永远不会运行在 React 客户端环境中。

这也意味着我们在规则方面拥有更大的灵活性。例如，在传统的 React 中，我们需要将副作用放在 useEffect 回调或事件函数之类的东西中，这样它们就不会在每次渲染时重复出现。但如果组件只运行一次，我们就不用考虑这些！

服务器组件本身出奇的简单，但 “React 服务器组件” 规范却要复杂得多。这是因为我们也需要使用常规的组件，而它们的组合方式可能相当混乱。

在这个新规范中，我们熟悉的“传统” React 组件被称为 客户端组件。

“客户端组件”这个名称暗示这些组件仅在客户端上渲染，但事实并非如此。客户端组件在客户端和服务器上都会渲染。

使用 react-server-component 需要特殊的编译器，例如 react-server-dom-webpack ，或者直接使用 Nextjs/Remix 这类已经集成好的框架。下面以 NextJS 为例

指定客户端组件​

'use client';

import React from 'react';

function Counter() {
  const [count, setCount] = React.useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Current value: {count}
    </button>
  );
}

export default Counter;

顶部的独立字符串 'use client' 是我们向 React 发出信号的方式，表明该文件中的组件是客户端组件，它们应该包含在我们的 JS 包中，以便它们可以在客户端上重新渲染。

这似乎是一种非常奇怪的方式来指定我们正在创建的组件的类型，不过有个类似的先例：“use strict”在 JavaScript 中选择进入“严格模式”的指令。

在服务器组件中我们不会声明 'use server' ；在 React 服务器组件规范中，组件默认被视为服务器组件。事另外，'use server' 它用于服务器操作，这是一个完全不同的功能，下面会提及。

哪些组件应该是客户端组件？

您可能想知道：我应该如何决定给定组件应该是服务器组件还是客户端组件？

一般来说，如果一个组件不需要交互，那么它就应该作为服务器组件。服务器组件往往更简单，更容易理解。此外，它还具有性能优势：由于服务器组件不在客户端运行，因此其代码不会包含在 JavaScript 包中。React 服务器组件规范的优势之一是它有潜力提升页面交互性(TTI) 指标。

当你开始使用 React 服务器组件时，你可能会发现这非常直观。我们的一些组件需要在客户端运行，因为它们使用状态变量或效果。你可以在这些组件上添加 'use client' 指令。否则，你可以将它们作为服务器组件。

客户端组件不能嵌套服务器组件

如图所示，Article 重新渲染时，所有拥有的组件也会重新渲染。但如果这些是服务器组件，则它们无法重新渲染。

为了避免这种不可能的情况，React 团队添加了一条规则：客户端组件只能导入其他客户端组件 。'use client' 下面这些组件都默认设定成为客户端组件。

这意味着我们不用在每个需要在客户端运行的文件中都添加 'use client'。只需要在创建新的顶部客户端组件时添加。

也因此，你的每个路由页面默认应该是服务器组件，对于需要交互的子组件，就添加 'use client' 将其设定为客户端组件，对于顶部服务端组件，我们可以在里面进行数据获取，或者渲染一些静态列表

TODO LIST //

优势​

React 服务器组件是第一个在 React 中运行服务器专用代码的“官方”方法。不过，之前也提到的，这在更广泛的 React 生态系统中并不算是什么新鲜事；自 2016 年以来，就能够在 Next.js 中运行服务器专用代码

最大的区别是，以前从来没有办法在组件内部运行服务器专用代码。

最明显的好处是性能。服务器组件不会包含在我们的 JS 包中，这减少了需要下载的 JavaScript 数量，以及需要加载的组件数量

例如，大多数博客都需要某种语法高亮库来展示代码块。

一个支持所有流行编程语言的语法高亮库，其体积将达到几兆大小，这实在太大，根本无法塞进 JS 包里。因此，我们不得不做出妥协，删减那些非关键的语言和功能。

但是，假设我们在服务器组件中实现语法高亮。在这种情况下，库代码实际上不会包含在浏览器需要下载的 JS 包中。这样一来，我们就不需要任何妥协，可以使用所有的功能。

以前那些因为包体积过高的功能，现在可以直接在服务器上运行，不增加任何 JS 空间，还能带来更佳的用户体验。

Server Action（服务器操作）​

另一项值得注意的新特性是 Server Action。这些是用来处理用户交互触发的服务端逻辑，如表单提交或数据变更的异步函数。

使用方式非常简单：你只需要在函数体内（或者文件顶部）添加一个特殊指令 “use server”，React 就会将其识别为服务端操作，并自动处理 RPC（远程过程调用）无需手写 API 接口即可调用该服务器端函数

action.ts

'use server'

async function createTodo(title: string) {
  const title = formData.get('title')?.toString() ?? '';

  // 验证
  if (!title) throw new Error('title 不能为空');

  await db.todo.create({ data: { title } });
}

create-todo.tsx

'use client';

import { useState } from "react";
import { addTodo } from "../action";

export default function CreateTodo() {
  const [title, setTitle] = useState("");

  const handleAddTodo = async () => {
    await addTodo(title);
    setTitle("");
  };
  return (
    <div className="flex items-center justify-between">
      <input 
        className="border-2 border-gray-300 rounded-md p-2"
        type="text"
        value={title}
        onChange={(e) => setTitle(e.target.value)}
       />
      <button
        className="bg-blue-500 text-white rounded-md p-2"
        onClick={handleAddTodo}
       >
        Add Todo
      </button>
    </div>
  );
}

数据更新​

revalidatePath()​

强制让指定页面路径的缓存失效并立即渲染最新数据

'use server';

import { revalidatePath } from 'next/cache';
import { db } from '@/lib/prisma';

export async function createTodo(todo: Todo) {
  await db.post.create({ data });

  // 让 `/` 页面缓存失效
  revalidatePath('/');
}

revalidateTag()​

指定某个函数缓存失效

import { unstable_cache } from 'next/cache';
import { db } from '@/lib/prisma';

export const getTodos = unstable_cache(
  async () => db.todo.findMany(),
  ['todo'],  // 缓存 Key
  { tags: ['todo_list'] } // 缓存标签
);


export async function addTodo(todo: Todo) {
  await db.todo.create({ data: todo });
  revalidateTag('todo_list'); // 所有用到这个 tag 的缓存失效
}

结尾​

React 服务器组件（RSC）为 React 带来了一个新的思路——让部分组件只在服务器运行，从而减少客户端的 JS 体积、提升加载速度、优化交互体验。

与传统的 CSR、SSR、SSG 相比，RSC 最大的亮点是可以在组件内部直接编写服务器端逻辑，并与客户端组件无缝组合，这在过去的 React 生态里是无法做到的。

RSC 并不是替代 SSR 或 CSR 的“万能钥匙”，而是给了开发者更多自由度去按需选择组件运行位置。合理的组件拆分与运行策略，才能最大化发挥它的性能优势与开发体验价值。

未来，随着框架（如 Next.js、Remix）的完善与标准化，RSC 很可能会成为构建高性能 React 应用的默认选项。可以说，它不仅是性能优化的工具，更是 React 架构理念的一次进化。

因为是服务端渲染，所以肯定自带了后端服务，它默认使用 nodejs 的 express 库一次部署就可以完成前端资源项目和后端 API 服务的部署。

Nginx 是一个高性能的负载均衡功能服务器，其强大的性能和稳定性深得人心，目前是大多数公司的 web 服务器首选。

Let’s Encrypt 是一种新的证书颁发机构 (CA)，它提供了一种获取和安装免费 TLS/SSL 证书的简单方法，从而在 web 服务器上启用加密的 HTTPS。通过加密传输加持，使得我们的 Nginx 服务器更加的安全。

先决条件：

1. 具有 sudo 权限用户的 CentOS 7 服务器。
2. 拥有 node 和 nginx 初始环境。
3. 拥有注册域名。
4. DNS 记录（域名解析），将你的的域指向服务器的公共 IP 地址。 Let’s Encrypt 会验证你是否拥有它为其颁发证书的域

安装 Certbot 加密客户端​

使用 Let’s Encrypt 获取 SSL 证书的第一步是在服务器上安装 certbot 软件。目前，最好的安装方式是通过 EPEL 存储库。

sudo yum install epel-release

启用存储库后， 安装 certbot-nginx 包:

sudo yum install certbot-nginx

启动 NextJS 项目​

我们可以使用 pm2 让我们的 NextJS 服务在后台运行而不会一直占着终端的位置。

npm install -g pm2

# 进入到项目根目录下
pm2 start npm --name "next" -- start
pm2 stop next

设置 Nginx​

如果还没有安装 Nginx

sudo yum install nginx

使用 systemctl 启动 Nginx

sudo systemctl start nginx

Certbot 可以为 Nginx 自动配置 SSL，但它需要能够在配置中找到正确的 server 块。它通过查找请求证书的域匹配的 server_name 参数来实现。

如果刚开始安装新的 Nginx，可以更新默认配置文件(已安装过忽略以下配置)

sudo vi /etc/nginx/nginx.conf

新增一个 server 块，配置 server_name 参数

server {
  server_name www.example.com;

  location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;
  }
}

访问 www.example.com 这个域名的所有路径都会被反向代理到本机的 http://localhost:3000，（前提是该域名已经在域名服务商那里解析到了本机服务器的公网 ip 地址） 3000 是 NextJS 项目生产环境默认启动端口。

保存并退出，检查配置语法是否有误

sudo nginx -t

如果提示正确，则重启 Nginx 服务器

sudo systemctl reload nginx

更新防火墙​

如果启用了防火墙，请确保端口 80 和 443 对传入流量开放。如果你没有运行防火墙，则忽略。

sudo firewall-cmd --add-service=http
sudo firewall-cmd --add-service=https
sudo firewall-cmd --runtime-to-permanent

准备就绪，现在可以运行 Certbot 并获取证书。

获取证书​

sudo certbot --nginx

--nginx 代表使用 nginx 插件运行 certbot

如果是第一次运行 certbot，会提示输入电子邮件地址并同意服务条款。

紧接着会问你想要激活哪个域名的证书，输入数字选择固定的域名，多选以逗号隔开，输入空格则全选，最后回车确定

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: xx.com
2: www.xx.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces， or leave input
blank to select all options shown (Enter 'c' to cancel):

其他安装提示进行即可，最后成功会提示你证书的存放路径，并且 nginx 配置也会更新。

当然也可以加上 -d 参数运行 certbot，指定证书名称

sudo certbot --nginx -d www.xx.com

然后就可以重启 Nginx 服务器了（当然，你的 server 需要有个目标，是需要配置静态 html 路径或者 proxy_pass 反向代理地址的）

sudo systemctl reload nginx

设置自动续订​

加密的证书只在 90 天内有效。这是为了鼓励用户自动化其证书续订过程。我们需要设置一个定期运行的命令来检查过期的证书并自动续订它们。

为了每天运行更新检查，我们将使用 cron，这是一种用于运行定期作业的标准系统服务。我们通过打开和编辑一个名为 crontab 的文件来告诉 cron 要做什么。

sudo crontab -e

文本编辑器将打开默认的 crontab，此时它是一个空文本文件。粘贴到以下行，然后保存并关闭:

crontab

15 3 * * * /usr/bin/certbot renew --quiet

15 3 * * * 部分表示 “每天上午 3:15 运行以下命令”。你也可以改成任何时间。

Certbot 的 renew 命令检查系统上安装的所有证书，并更新任何设置为在 30 天内过期的证书。--quiet 告诉 Certbot 不要输出信息或等待用户输入。

cron 现在会每天运行这个命令。所有已安装的证书会在到期前 30 天或更短时间内自动续订和重新加载。

React.memo​

示例​

我们先从一个简单的示例入手

以下是一个常规的父子组件关系，打开浏览器控制台并观察，每次点击父组件中的 + 号按钮，都会导致子组件渲染。

const ReactNoMemoDemo = () => {
  const [count, setCount] = React.useState(0);

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <Child name="Son" />
    </div>
  );
};

const Child = props => {
  console.log('子组件渲染了');
  return <p>Child Name: {props.name}</p>;
};

render(<ReactNoMemoDemo />);

子组件的 name 参数明明没有被修改，为什么还是重新渲染？

这就是 React 的渲染机制，组件内部的 state 或者 props 一旦发生修改，整个组件树都会被重新渲染一次，即时子组件的参数没有被修改，甚至无状态组件。

如何处理这个问题？接下里就要说到 React.memo

介绍​

React.memo 是 React 官方提供的一个高阶组件，用于缓存我们的需要优化的组件

如果你的组件在相同 props 的情况下渲染相同的结果，那么你可以通过将其包装在 React.memo 中调用，以此通过记忆组件渲染结果的方式来提高组件的性能表现。这意味着在这种情况下，React 将跳过渲染组件的操作并直接复用最近一次渲染的结果。

让我们来改进一下上述的代码，只需要使用 React.memo 组件包裹起来即可，其他用法不变

使用​

function ReactMemoDemo() {
  const [count, setCount] = React.useState(0);

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <Child name="Son" />
    </div>
  );
}

const Child = React.memo(props => {
  console.log('子组件渲染了');
  return <p>Child Name: {props.name}</p>;
});

render(<ReactMemoDemo />);

再次观察控制台，应该会发现再点击父组件的按钮，子组件已经不会重新渲染了。

这就是 React.memo 为我们做的缓存优化，渲染 Child 组件之前，对比 props，发现 name 没有发生改变，因此返回了组件上一次的渲染的结果。

React.memo 仅检查 props 变更。如果函数组件被 React.memo 包裹，且其实现中拥有 useState，useReducer 或 useContext 的 Hook，当 state 或 context 发生变化时，它仍会重新渲染。

当然，如果我们子组件有内部状态并且发生了修改，依然会重新渲染（正常行为）。

FAQ​

看到这里，不禁会产生疑问，既然如此，那我直接为每个组件都添加 React.memo 来进行缓存就好了，再深究一下，为什么 React 不直接默认为每个组件缓存呢？那这样既节省了开发者的代码，又为项目带来了许多性能的优化，这样不好吗？​

使用太多的缓存，反而容易带来 负提升。

前面有说到，组件使用缓存策略后，在被更新之前，会比较最新的 props 和上一次的 props 是否发生值修改，既然有比较，那就有计算，如果子组件的参数特别多且复杂繁重，那么这个比较的过程也会十分的消耗性能，甚至高于 虚拟 DOM 的生成，这时的缓存优化，反而产生的负面影响，这个就是关键问题。

当然，这种情况很少，大部分情况还是 组件树的 虚拟 DOM 计算比缓存计算更消耗性能。但是，既然有这种极端问题发生，就应该把选择权交给开发者，让我们自行决定是否需要对该组件进行渲染，这也是 React 不默认为组件设置缓存的原因。

也因此，在 React 社区中，开发者们也一致的认为，不必要的情况下，不需要使用 React.memo。

什么时候该用？ 组件渲染过程特别消耗性能，以至于能感觉到到，比如：长列表、图表等

什么时候不该用？组件参数结构十分庞大复杂，比如未知层级的对象，或者列表（城市，用户名）等

React.memo 二次优化​

React.memo 默认每次会对复杂的对象做对比，如果你使用了 React.memo 缓存的组件参数十分复杂，且只有参数属性内的某些/某个字段会修改，或者根本不可能发生变化的情况下，你可以再粒度化的控制对比逻辑，通过 React.memo 第二个参数

function MyComponent(props) {
  /* 使用 props 渲染 */
}
function shouldMemo(prevProps, nextProps) {
  /*
  如果把 nextProps 传入 render 方法的返回结果与
  将 prevProps 传入 render 方法的返回结果一致则返回 true，
  否则返回 false
  */
}
export default React.memo(MyComponent, shouldMemo);

如果对 class 组件有了解过的朋友应该知道，class 组件有一个生命周期叫做 shouldComponentUpdate()，也是通过对比 props 来告诉组件是否需要更新，但是与这个逻辑刚好相反。

总结​

对于 React.memo，无需刻意去使用它进行缓存组件，除非你能感觉到你需要。另外，不缓存的组件会多次的触发 render，因此，如果你在组件内有打印信息，可能会被多次的触发，也不用去担心，即使强制被 rerender，因为状态没有发生改变，因此每次 render 返回的值还是一样，所以也不会触发真实 dom 的更新，对页面实际没有任何影响。

useMemo​

示例​

同样，我们先看一个例子，calculatedCount 变量是一个假造的比较消耗性能的计算表达式，为了方便显示性能数据打印时间，我们使用了 IIFE 立即执行函数，每次计算 calculatedCount 都会输出它的计算消耗时间。

打开控制台，因为是 IIFE，所以首次会直接打印出时间。然后，再点击 + 号，会发现再次打印出了计算耗时。这是因为 React 组件重渲染的时候，不仅是 jsx，而且变量，函数这种也全部都会再次声明一次，因此导致了 calculatedCount 重新执行了初始化（计算），但是这个变量值并没有发生改变，如果每次渲染都要重新计算，那也是十分的消耗性能。

注意观察，在计算期间，页面会发生卡死，不能操作，这是 JS 引擎 的机制，在执行任务的时候，页面永远不会进行渲染，直到任务结束为止。这个过程对用户体验来说是致命的，虽然我们可以通过微任务去处理这个计算过程，从而避免页面的渲染阻塞，但是消耗性能这个问题仍然存在，我们需要通过其他方式去解决。

function UseMemoDemo() {
  const [count, setCount] = React.useState(0);

  const calculatedCount = (() => {
    let res = 0;
    const startTime = Date.now();
    for (let i = 0; i <= 100000000; i++) {
      res++;
    }
    console.log(`Calculated Count 计算耗时：${Date.now() - startTime} ms`);
    return res;
  })();

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <div>Calculated Count: {calculatedCount}</div>
    </div>
  );
}

介绍​

const memoizedValue = useMemo(() => {
  // 处理复杂计算，并 return 结果
}, []);

useMemo 返回一个缓存过的值，把 "创建" 函数和依赖项数组作为参数传入 useMemo，它仅会在某个依赖项改变时才重新计算 memoized 值。这种优化有助于避免在每次渲染时都进行高开销的计算

第一个参数是函数，函数中需要返回计算值

第二个参数是依赖数组

• 如果不传，则每次都会初始化，缓存失败
• 如果传空数组，则永远都会返回第一次执行的结果
• 如果传状态，则在依赖的状态变化时，才会从新计算，如果这个缓存状态依赖了其他状态的话，则需要提供进去。

这下就很好理解了，我们的 calculatedCount 没有任何外部依赖，因此只需要传递空数组作为第二个参数，开始改造

使用​

function UseMemoDemo() {
  const [count, setCount] = React.useState(0);

  const calculatedCount = useMemo(() => {
    let res = 0;
    const startTime = Date.now();
    for (let i = 0; i <= 100000000; i++) {
      res++;
    }
    console.log(`Memo Calculated Count 计算耗时：${Date.now() - startTime} ms`);
    return res;
  }, []);

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <div>Memorized Calculated Count: {calculatedCount}</div>
    </div>
  );
}

现在，"Memo Calculated Count 计算耗时"的输出信息永远只会打印一次，因为它被无限缓存了。

FAQ​

何时使用？​

当你的表达式十分复杂需要经过大量计算的时候

示例 2​

下面示例中，我们使用状态提升，将子组件的 click 事件函数放在了父组件中，点击父组件的 + 号，发现子组件被重新渲染

const FunctionPropDemo = () => {
  const [count, setCount] = React.useState(0);

  const handleChildClick = () => {
    //
  };

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <Child onClick={handleChildClick} />
    </div>
  );
};

const Child = React.memo(props => {
  console.log('子组件渲染了');
  return (
    <div>
      <div>Child</div>
      <button onClick={props.onClick}>Click Me</button>
    </div>
  );
});

render(<FunctionPropDemo />);

于是我们想到用 memo 函数包裹子组件，给缓存起来

const FunctionPropDemo = () => {
  const [count, setCount] = React.useState(0);

  const handleChildClick = () => {
    //
  };

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <Child onClick={handleChildClick} />
    </div>
  );
};

const Child = React.memo(props => {
  console.log('子组件渲染了');
  return (
    <div>
      <div>Child</div>
      <button onClick={props.onClick}>Click Me</button>
    </div>
  );
});

render(<FunctionPropDemo />);

但是意外来了，即使被 memo 包裹的组件，还是被重新渲染了，为什么！

我们来逐一分析

1. 首先，点击父组件的 + 号，count 发生变化，于是父组件开始重渲染
2. 内部的未经处理的变量和函数都被重新初始化，useState 不会再初始化了， useEffect 钩子函数重新执行，虚拟 dom 更新
3. 执行到 Child 组件的时候，Child 准备更新，但是因为它是 memo 缓存组件，于是开始浅比较 props 参数，到这里为止一切正常
4. Child 组件参数开始逐一比较变更，到了 onClick 函数，发现值为函数，提供的新值也为函数，但是因为刚刚在父组件内部重渲染时被重新初始化了（生成了新的地址），因为函数是引用类型值，导致引用地址发生改变！比较结果为不相等， React 仍会认为它已更改，因此重新发生了渲染。

既然函数重新渲染会被重新初始化生成新的引用地址，因此我们应该避免它重新初始化。这个时候，useMemo 的第二个使用场景就来了

const FunctionPropDemo = () => {
  const [count, setCount] = React.useState(0);

  const handleChildClick = useMemo(() => {
    return () => {
      //
    };
  }, []);

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      <Child onClick={handleChildClick} />
    </div>
  );
};

const Child = React.memo(props => {
  console.log('子组件渲染了');
  return (
    <div>
      <div>Child</div>
      <button onClick={props.onClick}>Click Me</button>
    </div>
  );
});

render(<FunctionPropDemo />);

这里我们将原本的 handleChildClick 函数通过 useMemo 包裹起来了，另外函数永远不会发生改变，因此传递第二参数为空数组，再次尝试点击 + 号，子组件不会被重新渲染了。

对于对象，数组，renderProps(参数为 react 组件) 等参数，都可以使用 useMemo 进行缓存

示例 3​

既然 useMemo 可以缓存变量函数等，那组件其实也是一个函数，能不能被缓存呢？我们试一试

继续使用第一个案例，将 React.memo 移除，使用 useMemo 改造

const ReactNoMemoDemo = () => {
  const [count, setCount] = React.useState(0);

  const memorizedChild = useMemo(() => <Child name="Son" />, []);

  return (
    <div>
      <div>Parent Count: {count}</div>
      <button onClick={() => setCount(count => count + 1)}>+</button>
      {memorizedChild}
    </div>
  );
};

const Child = props => {
  console.log('子组件渲染了');
  return <p>Child Name: {props.name}</p>;
};

render(<ReactNoMemoDemo />);

尝试点击 + 号，是的，Child 被 useMemo 缓存成功了！

总结​

同样的，不是必要的情况下，和 React.memo 一样，不需要特别的使用 useMemo

使用场景

1. 表达式有复杂计算且不会频发触发更新
2. 引用类型的组件参数，函数，对象，数组等（一般情况下对象和数组都会从 useState 初始化，useState 不会二次执行，主要是函数参数）
3. react 组件的缓存

扩展​

useCallback​

前面使用 useMemo 包裹了函数，会感觉代码结构非常的奇怪

const handleChildClick = useMemo(() => {
  return () => {
    //
  };
}, []);

函数中又 return 了一个函数，其实还有另一个推荐的 API， useCallback 来代替于对函数的缓存，两者功能是完全一样，只是使用方法的区别，useMemo 需要从第一个函数参数中 return 出要缓存的函数，useCallback 则直接将函数传入第一个参数即可

const handleChildClick = useCallback(() => {
  //
}, []);

代码风格上简介明了了许多

看完这篇文章，相信你对 React.memo 和 React.useMemo 已经有了一定的了解，并且知道何时/如何使用它们了

既然是封装，那就要考虑到代码的健硕性，参数的扩展性，TS 类型支持，以及可维护性，如何有效设计封装，就是我们接下来要讲的重点。

模拟接口 api​

为了方便后续的测试，我们先模拟了一个获取用户信息的接口

/** 用户信息 **/
interface User {
  id: number;
  name: string;
  age: number;
}

const USER_DATA: User[] = [
  { id: 0, name: '乔治', age: 12 },
  { id: 0, name: '佩奇', age: 14 }
];

/** 响应结果 **/
interface ResponseData<T> {
  result: T;
  message?: string;
  code: number;
}

function withResponse<T>(result: T): ResponseData<T> {
  return {
    message: '成功',
    code: 200,
    result: result
  };
}

/** 获取用户信息接口 **/
async function getUserInfo() {
  return new Promise<ResponseData<User[]>>(resolve => {
    setTimeout(resolve, 1000, withResponse(USER_DATA));
  });
}

解释：

• 我们先定义了一个用户信息的数据模型，然后以这个结构定义了一个数组 data。
• 其次为了完全模拟后台接口数据结构，我们又在外面包裹了一层响应信息，状态码，message，result 等
• 最后在 getUserInfo 房中，用 Promise.resolve 异步方式 return 了这个结果

最终使得 getUserInfo 这个方法调用时，和真实的请求数据看起来一模一样

当然，这个响应数据结构可能每个后端定义的都不太一样，但这个对上下文没有什么影响，自行更改下 ResponseData 的模型结构就行

默认配置​

const instance = axios.create({
  baseURL: 'https://some-domain.com/api/',
  timeout: 1000,
  headers: { 'X-Access-Token': 'foobar' }
});

axios.create 可以帮助我们创建一个新的 axios 实例。

如果项目存在多种配置，则可以创建多个实例，配置之间互不干扰。

配置参数一般是 BASE_URL 基本 url, timeout 请求超市, headers 请求头信息等，更多参数说明见官方文档 https://axios-http.com/zh/docs/req_config

axios 拦截器​

请求拦截​

请求拦截中，有两个回调函数

• 第一个回调是请求发送之前，我们可以在这里进行参数处理，同样可以设置 headers 请求头相关的

比如我们的所有请求都会触发一个全局 loading 效果，但是部分请求希望跳过 loading $loading: false 之类的参数

到了请求拦截发送之前这个回调中，去解析请求参数，条件显示 loading 效果，并且移除这个自定义参数

• 第二个回调是请求失败之后，默认这里会抛出错误异常，因此我们需要在业务代码中使用 try catch 来进行异常捕获

instance.interceptors.request.use(
  config => {
    if (config.data.$loading !== false || config.params.$loading !== false) {
      // 展示全局 loading
    } else {
      // 移除自定义参数，以免发送到后端
      delete config.data.$loading;
      delete config.params.$loading;
    }

    return config;
  },
  error => {
    return Promise.reject(error);
  }
);

请求异常一般不会发生，除非你在请求回调的第一个参数中抛出了异常，才会走到请求异常的回调中

响应拦截​

对于请求完成的响应，通常我们要做出处理

比如接口返回错误，并返回了对应的 message，我们需要统一提示出来，可以在响应成功拦截里全局提示

对于接口请求失败（无法进入成功拦截），就要在响应失败拦截回调中处理

axiosInstance.interceptors.response.use(
  config => {
    const { code, message, result } = config?.data;

    if (code !== 0) {
      ToastUtil.error(retMsg || '服务器异常');
    }

    return config?.data;
  },
  error => {
    let errorMessage = '系统异常';

    if (error?.message?.includes('Network Error')) {
      errorMessage = '网络异常';
    } else {
      errorMessage = error?.message;
    }
    console.dir(error);
    error.message && ToastUtil.error(errorMessage);

    return {
      status: false,
      message: errorMessage,
      result: null
    };
  }
);

request 封装​

为了获取请求返回值能够获得完整的类型提示，这里的 request 我们使用到了泛型，对于传入的泛型，我们包装了一层全局通用的自定义的响应内容

import type { AxiosRequestConfig } from 'axios';

/**
 *
 * @param method - 请求方式
 * @param url - url
 * @param data - 参数
 * @param config - Axios config
 */
export const request = <T = any>(
  method: 'get' | 'post',
  url: string,
  data?: any,
  config?: AxiosRequestConfig
): ResponseData<T> => {
  if (method === 'get') {
    return axiosInstance.get(url, {
      params: data,
      ...config
    });
  } else {
    return axiosInstance.post(url, data, config);
  }
};

扩展泛型​

使用​

传入泛型​

interface GetDataResult {
  list: User[];
}
const apiGetData = async () => request<GetDataResult>('get', 'https://www.test_url.com/api/test');

调用 api​

由于 apiGetData 方法我们传入了返回类型泛型参数，所以下面 res 会有完整的类型提示

apiGetData().then(res => {
  if (res.status) {
    console.log(res.result.list);
  }
});

示例​

因为我们提供的 url 是不存在的，所以这个请求不会成功

请求参数类型​

对于请求参数，我们也可以提供类型校验

interface GetDataParams {
  name: string;
}
const apiGetData = async (params: GetDataParams) => request('get', 'https://www.test_url.com/api/test');

这样一来，整个开发过程都会得到类型的校验和提示，极大的增加了开发和维护效率。

通过字面意思可以得知 process 变量是在 node 环境中的变量，浏览器肯定不行，我们可以通过在加载代码之前添加一段 hack 脚本

<script>
  var process = {
    env: {
      NODE_ENV: 'production'
    }
  };
</script>
<script src="你的库的src"></script>

但是这样很不优雅，如果别人使用你的库直接报错肯定也不行。

同样可以在 rollup 配置文件中通过 @rollup/plugin-replace 插件去处理

import replace from '@rollup/plugin-replace';

export default {
  // ...
  plugins: [
    // ...
    replace({
      'process.env.NODE_ENV': JSON.stringify('production')
    })
  ]
};

inset: 0; 等价于：

div {
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}

同时 inset: 1px 2px; 等价于：

div {
  top: 1px;
  right: 2px;
  bottom: 1px;
  left: 2px;
}

inset: 1px 2px 3px; 等价于：

div {
  top: 1px;
  right: 2px;
  bottom: 3px;
  left: 2px;
}

inset: 1px 2px 3px 4px; 等价于：

div {
  top: 1px;
  right: 2px;
  bottom: 3px;
  left: 4px;
}

设置顺序依次为上、下、左、右，这点就和 margin padding 等属性的统一设置规则一样。

4 行缩成 1 行，在代码简化上，倒是起了很大的帮助。

项目创建​

演示环境：

• NodeJS: > 16.13.0
• npm: 6.x

初始化​

首先尝试去初始化你的目录

mkdir my-cli

进入目录

cd my-cli

初始化 npm

npm init -y

设置入口文件

echo "console.log('hello my-cli')" >> index.js

设置 bin​

因为我们的包是可执行文件，因为需要在 package.json 中设置一下 bin

bin 字段是命令名到本地文件名的映射。通过 npm 安装后，在调用执行文件时，可以不带路径，直接使用命令名来执行相对应的执行文件。

{
  "name": "my-cli",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
+ "bin": {
+   "my-cli": "./index.js"
+ },
+ "type": "module",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

可以配置多个 bin，key 是可执行文件命令名称，值是文件路径。

"type": "modue 可以让我们直接使用 ES Module 语法

npm link​

如何测试我们的包？我们还没有发布，因此无法下载。也不可能每次修改都要通过 npm 发布吧？

npm link 命令会在 nodejs 安装目录下的 node_modules 帮我们生成一个符号链接（windows 下则是快捷键），这样我们就可以在全局的任意位置使用这个 npm 包了。调试 npm 插件通常也都这么做。

一定要在 包目录下执行 npm link

执行完 npm link 之后，我们就可以直接在命令行执行我们的全局包了

my-cli

如果没有正确的输出 'hello my-cli'，并且抛了个错误，说明你的当前系统可能是 Mac OS 或者 linux。

通过在文件顶部添加 #! /usr/bin/env node，告诉 类 unix（Mac OS、Linux） 系统，声明这是一个可执行的 node 脚本。

+ #!/usr/bin/env node

console.log('hello my-cli')

然后再次执行 my-cli，然后应该就会正常输出 'hello my-cli' 了

配置模板​

因为我们此次的目录是为了生成模板项目，因此我们需要先提供模板文件到项目中，创建 template 目录

mkdir template

这里我们先使用 vite 生成一个模板

cd  template

react-js

yarn create vite react --template react

准备好了模板，如何生成？

复制模板​

用户执行命令的时候，通过 node api 去复制模板目录到用户的当前目录下

#! /usr/bin/env node

import fs from 'fs';
import path from 'path';

const currentRoot = new URL('.', import.meta.url).pathname;
const templateDir = path.resolve(currentRoot, './template/react');

fs.cpSync(templateDir, './react-app', { recursive: true });

然后我们可以在任意的地方执行 my-cli，这里选择在当前根目录执行，会发现根目录多了一个名为 react-app 目录，说明我们的模板已经安装成功了。

进阶​

上述已经完成了一个最基本的脚手架功能了，但是暴露出来的问题也很多，需要进一步优化。

动态目录名称​

由于生成出来的目录名称被我们写死，但是一般情况下，生成的目录名称应该由用户决定，这样就不需要再二次修改了。

minimist​

process.argv 这个属性可以帮我提取出用户提供的命令行参数，但是使用起来不是很直观，这里我们选择 minimist 这个工具库。

npm i minimist

  #! /usr/bin/env node

  import fs from 'fs';
  import path from 'path';
+ import minimist from 'minimist';

+ const args = minimist(process.argv.slice(2));
+ console.log(args);

  const currentRoot = new URL('.', import.meta.url).pathname;
  const templateDir = path.resolve(currentRoot, './template/react');

  fs.cpSync(templateDir, './react-app', { recursive: true });

接下来修改我们的命令脚本

my-cli my-react-app

将会输出

{ _: [ 'my-react-app' ] }

拿到了动态的目录名称，就可以作为复制的目标目录了

  #! /usr/bin/env node

  import fs from 'fs';
  import path from 'path';
  import minimist from 'minimist';

  const args = minimist(process.argv.slice(2));
+ const projectName = args._[0]

  const currentRoot = new URL('.', import.meta.url).pathname;
  const templateDir = path.resolve(currentRoot, './template/react');

- fs.cpSync(templateDir, './', { recursive: true });
+ fs.cpSync(templateDir, `./${projectName}`, { recursive: true });

重新执行 my-cli my-react-app，则会看到新名为 my-react-app 的目录出来了

动态内容​

虽然目录名称修改了，但是会发现 package.json 中的 name 字段还是写死的，这里应该也要是动态生成的。

因此我们需要复制出这段 json，然后删掉这个文件，配置动态 projectName

  #! /usr/bin/env node

  import fs from 'fs';
  import path from 'path';
  import minimist from 'minimist';

  const args = minimist(process.argv.slice(2),);
  const projectName = args._[0];
+ const workSpaceRoot = path.resolve(projectName);

  const currentRoot = new URL('.', import.meta.url).pathname;
  const templateDir = path.resolve('./template/react');

  fs.cpSync(templateDir, `./${projectName}`, { recursive: true });

+ const packageJsonContent = {
+   "name": projectName,
+   "private": true,
+   "version": "0.0.0",
+   "type": "module",
+   "scripts": {
+     "dev": "vite",
+     "build": "vite build",
+     "preview": "vite preview"
+   },
+   "dependencies": {
+     "react": "^18.2.0",
+     "react-dom": "^18.2.0"
+   },
+   "devDependencies": {
+     "@types/react": "^18.0.15",
+     "@types/react-dom": "^18.0.6",
+     "@vitejs/plugin-react": "^2.0.0",
+     "vite": "^3.0.0"
+   }
+ }
+
+ // 写入新的 package.json
+ fs.writeFileSync(path.join(workSpaceRoot, 'package.json'), JSON.stringify(packageJsonContent, null, 4));

这里我们设置了自己配置的 package.json 内容，二次写入到了 projectName 根目录下

JSON.stringify(packageJsonContent, null, 4) 最后一个参数 代表缩进，可以自行选择

其他文件内容也可以参考这种方式，比如 index.html 的 <title> 标签，README.md 的标题内容 等等...

多模板​

我们目前只提供了一个模板，但是大多数情况往往需要多种模板提供用户选择，比如 js 还是 ts，vue 还是 react

再添加一个 react-ts 模板

yarn create vite react-ts --template react-ts

记得也要删除 package.json

用户通过命令行选项 --template xx 选择生成特定模板

  #! /usr/bin/env node

  import fs from 'fs';
  import path from 'path';
  import minimist from 'minimist';
+ import chalk from 'chalk';

  const args = minimist(process.argv.slice(2),);
  const projectName = args._[0];
  const workSpaceRoot = path.resolve(projectName);
+ const templateName = args.template || 'react';
  const currentRoot = new URL('.', import.meta.url).pathname;
+ const templateDir = path.resolve(currentRoot, `./template/${templateName}`);
+ const templateNameOptions = fs.readdirSync(path.resolve(currentRoot, './template'));

+ if (!templateNameOptions.includes(templateName)) {
+   console.log(chalk.red(`${templateName} 不是一个合法的模板选项，请使用以下值：${templateNameOptions.join(', ')}`));
+   process.exit(1);
+ }

  fs.cpSync(templateDir, `./${projectName}`, { recursive: true });

+ const isTS = templateName === 'react-ts';

  const packageJsonContent = {
    "name": projectName,
    "private": true,
    "version": "0.0.0",
    "type": "module",
    "scripts": {
      "dev": "vite",
-     "build": "vite build",
+     "build": `${isTS ? 'tsc && ' : ''}vite build`,
      "preview": vite preview"
    },
    "dependencies": {
      "react": "^18.2.0",
      "react-dom": "^18.2.0"
    },
    "devDependencies": {
      "@types/react": "^18.0.15",
      "@types/react-dom": "^18.0.6",
      "@vitejs/plugin-react": "^2.0.0",
      "vite": "^3.0.0"
    }
  }
+ // 如果是 ts 模板，则添加 typescript 依赖
+ if (isTS) {
+   packageJsonContent.devDependencies.typescript = "^4.6.4"
+ }

  fs.writeFileSync(path.join(workSpaceRoot, 'package.json'), JSON.stringify(packageJsonContent, null, 2));

我们新增了 chalk 这个库来对命令行输出信息美化

并设置了 react 为默认模板选项，通过读取 template 下的子目录来提示用户设置合法的模板值

现在，命令行添加 --template react-ts 选项，可以为我们生成一个 React + TypeScript 的模板了

my-cli my-react-app --template react-ts

目录已存在校验​

目前每次执行命令都会强制替换的之前的目录，这样其实很不安全，缺少一个已存在校验

我们可以在执行复制命令之前进行判断，通过 fs.existsSync API

if (fs.existsSync(workSpaceRoot)) {
  console.log(chalk.red(`${projectName} 文件夹已存在，请先删除`));
  process.exit(1);
}

初始化 git​

为了优化体验，我们可以提前初始化好项目的 git

在代码的最后，添加以下代码

import { execSync } from 'child_process';

process.chdir(workSpaceRoot);

execSync(`git init`, { stdio: 'ignore' });

console.log(`\n${projectName} 创建完成 \n\n 路径：${chalk.green(workSpaceRoot)}\n\n`);
console.log(`进入目录: ${chalk.blue(`cd ${projectName}`)}`);
console.log(`安装依赖: ${chalk.blue(`npm install`)}\n\n`);

process.chdir 是 node 的全局 API，可以帮助我们修改当前 node 工作区，为什么要做这一步？

当前的执行目录是在项目目录的上一层，如果在这里执行 git 初始化，那肯定是不对的，我们应该进入到项目内部执行 git 命令

execSync 是 node 子进程 child_process 的一个 API，可以用来执行 shell 脚本，第二个参数我们用到了 stdio: 'ignore' 选项，目的是告诉它不要输出 git 初始化的日志

最后，我们添加了一些创建完成的成功提示信息

发布​

以上大致功能开发完成，可以发布到 npm 公共仓库了

发布之前，我们需要登录，如果没有注册的话，需要到 https://www.npmjs.com/ 进行账号注册

登陆之前，请检查当前 npm 的源是否为官方源，如果不是，可能是设置了镜像，需要先切换到官方源

npm config get registry

如果输出的地址不是 https://registry.npmjs.org/，则设置为

npm config set registry https://registry.npmjs.org/

接着可以开始登录了，按照提示输入账号密码以及邮箱地址

如果出现需要验证码的提示，则打开你注册的邮箱，应该会收到一封 npm 发来的邮件，里面有登录需要的验证码

npm login

登录成功之后，可以开始发布了

npm publish

首先会出现的第一个错误应该是

npm ERR! This package has been marked as private
npm ERR! Remove the 'private' field from the package.json to publish it.

原因是我们的 package.json 中默认是 "private": true，需要改成 "private": false 或删除这个配置

再次执行 npm publish 应该会遇到第二个错误： 403 Forbidden，因为我们使用的 name 字段 my-cli 太大众化了，这个插件包名已经被别人注册过了

我们可以使用 scope 的组织命名法 @你的npm用户名/你的包名，例如： @vue/cli 这也是目前 npm 插件包的流行命名方式

• 因为 npm 用户名是唯一的，这可以完全阻止了与别人命名冲突的问题
• 其次这种命名方式在 node_modules 中也会将你的个人组织下的包分类在一起，方便快速找到

唯一的缺点可能就是这类名称方式最终看起来不太好看：）

需要注意的是，每次发布新版本时，都应该设置更高的版本号，package.json 中 version 字段

全局安装​

不出意外的话，到此已经成功发布到 npm 公共镜像了，现在可以通过 npm 的方式全局安装我们的包了。

值得一题的是，安装之前我们需要先解除之前 npm link 的包全局路径（已存在），以免发生冲突

npm unlink​

npm unlink my-cli

然后正式全局安装

npm i @你的npm用户名/你的包名 -g

现在，我们可以全局的任意地方执行生成模板的命令了

my-cli my-react-app

或者 生成 ts 模板

my-cli my-react-app --template react-ts

毫秒之内，就提示我们创建完成了。打开 my-react-app，检查一下文件，是否都正常显示。

.gitignore 无法上传问题​

细心的朋友，可能会发现，之前模板里的 .gitignore git 忽略文件消失了。

原因是因为 npm 发布的时候，它会自动过滤掉 .gitignore npmrc 这类文件，所以永远上传不到 npm 服务器上，所以下载下来也是没有的。

如何解决？我们可以换个思路，把模板文件里的 .gitignore 取个其他的名字（比如去掉 . 开头，叫 gitignore），先让它成功上传，然后我们在执行安装脚本的时候（生成好目录之后），再去把名字修改回来。

通过 fs.renameSync API 可以帮我我们实现重命名的功能

fs.renameSync(path.join(root, 'gitignore'), path.join(root, '.gitignore'));

npx 远程安装​

目前的这种安装方式要求我们必须先把 npm 包安装到本地的存储当中，如果全局包过多，就会导致本地的包吃掉的硬盘内容特别多。

目前更推荐的做法是，通过 npx 命令执行全局脚本， 一次性调用，无需本地安装

执行之前，我们先删除本地的全局包

npm uninstall @winme/my-cli -g

通过npx 重新执行

npx @winme/my-cli

如果有多个 bin，可以添加 -p 参数，用于指定执行某个 bin 名称，如果只有一个 bin 可以省略这个参数

npx @winme/my-cli -p my-cli

npx --ignore-existing​

也可以通过 npx --ignore-existing 忽略本地的同名模块，强制安装使用远程模块

npx --no-install​

也可以通过 npx --no-install 强制使用本地模块，不下载远程模块

至此，脚手架工具的功能已经基本开发完成，对于许多公司来说，许多项目用到的技术栈，配置，甚至基本布局样式都是可复用的，这个时候我们完全可以通过脚手架的模板预先配置好，以免过多的复制粘贴还容易出错

这样一来就可以大大节省时间成本了。

tips​

过滤发布内容​

默认发布时会把我们所有的文件和目录都上传，但通常我们需要排除一些文件或者指定一些文件，有 2 种方式可以做到

1. 根目录下创建 .npmignore 文件，会排除掉你列出的文件和目录，就像写 .gitignore 一样

2. 在 package.join 中 添加 files 字段，是一个数组，可以添加你需要指定上传的文件和目录，也可以作为 .npmignore 的白名单

码字不易，如遇书写错误，烦请指出~

系统的 yum 源安装 nodejs 版本太低。如果你的系统版本比较低，gcc 库版本低，编译安装的时候有可能不成功，下面是 yum 安装的步骤

安装 nodejs 源​

curl --silent --location https://rpm.nodesource.com/rpm/setup_lts.x | sudo bash

yum 安装 nodejs​

sudo yum -y install nodejs

如果以上步骤不能安装 最新版 node，执行以下命令后再执行第二步：

sudo yum clean all

如果存在多个 nodesoucre，执行以下命令删除，然后重新执行第一第二步：

sudo rm -fv /etc/yum.repos.d/nodesource*

确认安装成功​

node -v
v16.13.1

npm -v
8.1.2

但是许多人都或者不知道或者没用过 JS 的新的 Window 对象 API：ULRSearchParms， ULRSearchParms 就是专门用来处理 query 参数的各种转换问题。

JS 对象转为 URL query 参数​

new URLSearchParams({ id: 1, name: 'Jack' }).toString();
// id=1&name=Jack'

URL query 参数转为 JS 对象​

const query = 'id=1&name=Jack';
const searchParms = new URLSearchParams(query);
Object.fromEntries(searchParms);
// {id: '1', name: 'Jack'}

因此，可以将当前 url 的 query 参数传递给 URLSearchParams

const searchParms = new URLSearchParams(window.location.search);

其他用法​

• URLSearchParams.get(name):

  插入一个指定的键/值对作为新的搜索参数。

  const searchParms = new URLSearchParams('id=1&name=Jack');
  searchParms.get('name');
  // 'Jack'
  

• URLSearchParams.append(name, value):

  插入一个指定的键/值对作为新的搜索参数。

  const searchParms = new URLSearchParams('id=1&name=Jack');
  searchParms.append('age', '18');
  Object.fromEntries(searchParms);
  // {id: '1', name: 'Jack', age: '18'}
  

• URLSearchParams.delete(name):

  插入一个指定的键/值对作为新的搜索参数。

  const searchParms = new URLSearchParams('id=1&name=Jack');
  searchParms.delete('id');
  Object.fromEntries(searchParms);
  // {name: 'Jack'}
  

• URLSearchParams.has('name')

  返回 Boolean 判断是否存在此搜索参数。

• URLSearchParams.toString()

  返回搜索参数组成的字符串，可直接使用在 URL 上。

当然，我们可以先将 search 字符串 转为 js 对象，再使用对象的操作方法，最后再根据需要转回 search 字符串。

更多用法见 https://developer.mozilla.org/zh-CN/docs/Web/API/URLSearchParams

因此想到添加一个高度 100% 的空的行内元素，并且同时设置 vertical:middle 作为子元素的参照物。

.parent {
  width: 200px;
  height: 200px;
  text-align: center;
  border: 1px solid #ccc;
}

.parent::before {
  display: inline-block;
  width: 0;
  height: 100%;
  vertical-align: middle;
  content: '';
}

.parent .child {
  display: inline-block;
  vertical-align: middle;
  width: 50px;
  height: 50px;
  border: 1px solid #ccc;
}

1. 关闭共享 wifi

2. 通过命令行 cd 进入（或者 shift+commond+g 前往文件夹）进入到 /Library/Preferences/SystemConfiguration/ 目录，找到以下文件并删除

   • com.apple.airport.preferences.plist
   • com.apple.network.eapolclient.configuration.plist
   • com.apple.wifi.message-tracer.plist
   • NetworkInterfaces.plist
   • preferences.plist

3. 重启 mac

4. 重新设置共享 wifi

成功设置共享网络后，wifi 图标会如图所示

值得一题的是，如果遇到其他网络问题，也可以尝试上述方法

Reinitialized existing Git repository in /home/gitlab-runner/builds/AXzjdXyZ/0/root/blog/.git/
fatal: git fetch-pack: expected shallow list
fatal: The remote end hung up unexpectedly

原因是 centos 7 git 版本太老不持之新 API，需要升级一下 git：

#安装源
yum install http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-2.noarch.rpm
#安装git
yum install git
#更新git
yum update git

打开终端，使用 vim 修改 Hosts 文件：

sudo vi /etc/hosts

sudo vim C:\Windows\System32\drivers\etc\hosts

添加以下 host 配置

# Github Hosts
# Update 20210925
# domain: github.com
140.82.112.4 github.com
140.82.112.10 nodeload.github.com
140.82.114.5 api.github.com
140.82.113.10 codeload.github.com
185.199.108.133 raw.github.com
185.199.108.153 training.github.com
185.199.108.153 assets-cdn.github.com
185.199.108.153 documentcloud.github.com
185.199.108.154 help.github.com

# domain: githubstatus.com
185.199.108.153 githubstatus.com

# domain: fastly.net
199.232.69.194 github.global.ssl.fastly.net

# domain: githubusercontent.com
185.199.108.133 raw.githubusercontent.com
185.199.108.154 pkg-containers.githubusercontent.com
185.199.108.133 cloud.githubusercontent.com
185.199.108.133 gist.githubusercontent.com
185.199.108.133 marketplace-screenshots.githubusercontent.com
185.199.108.133 repository-images.githubusercontent.com
185.199.108.133 user-images.githubusercontent.com
185.199.108.133 desktop.githubusercontent.com
185.199.108.133 avatars.githubusercontent.com
185.199.108.133 avatars0.githubusercontent.com
185.199.108.133 avatars1.githubusercontent.com
185.199.108.133 avatars2.githubusercontent.com
185.199.108.133 avatars3.githubusercontent.com
185.199.108.133 avatars4.githubusercontent.com
185.199.108.133 avatars5.githubusercontent.com
185.199.108.133 avatars6.githubusercontent.com
185.199.108.133 avatars7.githubusercontent.com
185.199.108.133 avatars8.githubusercontent.com
# End of the section

因此，你完全可以在工作中使用 ES6 编写程序，最后使用 Babel 将代码转为 ES5 的代码，这样就不用担心所在环境是否支持了。下面是一个示例：

转换前，代码里使用 ES6 箭头函数

const fn = num => num;

转换后

var fn = function fn(num) {
  return num;
};

上述就是 Babel 主要做的事情

前言​

使用之前，我们先搭建一个简单的 webpack 环境，用于执行编译我们的代码（当然也可以使用 @babel/cli，在这里使用较为常见的 webpack）

项目准备​