React 已經(jīng)經(jīng)歷了相當(dāng)長(zhǎng)的發(fā)展歷程。與此同時(shí)，一個(gè)功能全面且復(fù)雜的庫生態(tài)系統(tǒng)在 React 的基礎(chǔ)上逐漸形成。本文就來深入探討一下 2024 年你可以 React 項(xiàng)目中使用的庫！

創(chuàng)建新項(xiàng)目

對(duì)于初學(xué) React 的開發(fā)者，首先要面臨的問題就是如何搭建一個(gè) React 項(xiàng)目。市面上的工具眾多，目前最受 React 社區(qū)歡迎的是 Vite。Vite 不僅支持多種庫（如 React）與TypeScript 的結(jié)合使用，還具備出色的性能。

如果你已經(jīng)對(duì) React 有所了解，那么可以考慮使用 Next.js 或 Remix 等其他（元）框架作為 Vite 的替代方案。Next.js 最初主要用于服務(wù)端渲染，但如今也支持靜態(tài)站點(diǎn)生成以及其他渲染模式。2023年，Next.js 引入了新的功能——React Server Components，這一功能將 React 組件從客戶端遷移到了服務(wù)端，從而實(shí)現(xiàn)了重大的范式轉(zhuǎn)變。

如果尋求性能卓越的靜態(tài)內(nèi)容框架，那么 Astro 是一個(gè)理想的選擇。它不僅與各種框架兼容，而且能與 React 協(xié)同工作。在將內(nèi)容發(fā)送到瀏覽器時(shí)，Astro 僅包含 HTML 和 CSS，即使使用了如 React 這樣的框架來創(chuàng)建組件。只有當(dāng)這些組件變得交互式時(shí)，才會(huì)請(qǐng)求必要的 JavaScript。

如果你是 React 老手，并希望嘗試新的技術(shù)，Nitro 或 Waku都是不錯(cuò)的選擇。Waku 由 Zustand 的創(chuàng)造者開發(fā)，并支持 React Server Components。

建議：

• Vite：適用于客戶端渲染的 React 應(yīng)用
• Next.js：適用于服務(wù)端渲染的 React 應(yīng)用
• Astro：適用于靜態(tài)生成的 React 應(yīng)用

包管理

如果你正在尋找在 JavaScript 生態(tài)系統(tǒng)中（尤其是React）包管理工具，npm 無疑是首選，因?yàn)樗c Node.js 安裝捆綁在一起。然而，yarn 和 pnpm 也是值得考慮的優(yōu)秀替代方案。特別是 pnpm，它提供了更高的性能。

如果有多個(gè)相互依賴或共享通用UI組件的React應(yīng)用，monorepo 的概念可能值得探索。所有上述包管理器都支持使用其內(nèi)部工作區(qū)功能創(chuàng)建 monorepo，但使用 yarn 或 pnpm 時(shí)可以獲得更好的開發(fā)體驗(yàn)。結(jié)合諸如 Turborepo 之類的 monorepo 管道工具，可以使整個(gè)體驗(yàn)更加順暢。

建議：

• 選擇一個(gè)包管理器并堅(jiān)持使用它

• 默認(rèn)和最廣泛使用的 -> npm
• 性能提高，但相對(duì)較新，不那么流行 -> pnpm

• 如果需要 monorepo，使用 Turborepo。

狀態(tài)管理

React 提供了兩個(gè)用于管理本地狀態(tài)的內(nèi)置 Hooks：useState 和 useReducer。若要進(jìn)行全局狀態(tài)管理，可以利用 React 的 useContext Hook，它能夠?qū)傩詮捻敿?jí)組件安全地傳遞至其子組件，從而避免了屬性傳遞的問題。

這三個(gè) React Hooks 都賦予了開發(fā)者在 React 中實(shí)現(xiàn)強(qiáng)大狀態(tài)管理的能力。可以選擇在組件內(nèi)部使用 useState/useReducer Hook 進(jìn)行協(xié)同定位，或者將它們與 useContext Hook 結(jié)合進(jìn)行全局管理。

如果頻繁地使用 React 的 Context 進(jìn)行全局狀態(tài)管理，那么 Zustand 可能會(huì)是你需要的工具。Zustand 允許管理全局應(yīng)用狀態(tài)，任何與 Zustand 存儲(chǔ)連接的 React 組件都可以讀取和修改這些狀態(tài)。

盡管 Zustand 已成為社區(qū)中的主流選擇，但當(dāng)需要狀態(tài)管理庫時(shí)，Redux 仍然是市場(chǎng)上最受歡迎的 React 狀態(tài)管理工具庫。若你選擇使用Redux，推薦你一并查看 Redux Toolkit。如果對(duì)狀態(tài)機(jī)有特別的興趣，XState 和 Zag 也是不錯(cuò)的選擇。如果需要一個(gè)全局存儲(chǔ)，但不滿意 Zustand 或 Redux，Jotai、Recoil 或 Nano Stores 等本地狀態(tài)管理解決方案值得考慮。

建議：

• 對(duì)于協(xié)同定位或共享狀態(tài)，使用使用內(nèi)置的 useState/useReducer。
• 若需全局狀態(tài)管理，考慮使用內(nèi)置的 useContext。
• 對(duì)于大量的全局狀態(tài)，考慮使用 Zustand 或其替代方案。

數(shù)據(jù)獲取

在處理 UI 狀態(tài)時(shí)，React 的內(nèi)置 Hook 是非常適用的。然而，當(dāng)涉及到遠(yuǎn)程數(shù)據(jù)的狀態(tài)管理（包括數(shù)據(jù)獲取和緩存）時(shí)，建議使用專門的數(shù)據(jù)獲取庫，比如TanStack Query（前身為React Query）。

雖然 TanStack Query 本身并不是一個(gè)專門的狀態(tài)管理庫，主要用于從 API 獲取遠(yuǎn)程數(shù)據(jù)，但它能夠處理所有與該遠(yuǎn)程數(shù)據(jù)相關(guān)的狀態(tài)管理工作，包括緩存和樂觀更新。

如果在 React 中需要更專用的 GraphQL 庫，除了 TanStack Query，還可以考慮使用 Apollo Client（流行）、urql（輕量級(jí)）或 Relay（由Facebook開發(fā)）。

如果希望在 Redux 中集成數(shù)據(jù)獲取和狀態(tài)管理功能，那么可以考慮使用 RTK Query，它能夠?qū)?shù)據(jù)獲取功能與 Redux 無縫集成，簡(jiǎn)化狀態(tài)管理流程。

此外，如果同時(shí)開發(fā)前端和后端（并且兩者都使用TypeScript），那么 tRPC 是一個(gè)值得考慮的選項(xiàng)。tRPC 提供端到端的類型安全 API，可顯著提高開發(fā)效率和用戶體驗(yàn)。當(dāng)需要從前端調(diào)用后端時(shí)，可以使用類型化的函數(shù)。

建議：

• TanStack Query（適用于REST API或GraphQL API），結(jié)合 axios 或 fetch 使用
• Apollo Client（適用于 GraphQL API）
• tRPC（適用于緊密耦合的客戶端-服務(wù)端架構(gòu)）

路由

如果使用 Next.js 這樣的 React 框架，路由已經(jīng)處理好了。然而，如果使用的是沒有框架的React，僅用于客戶端渲染（例如 Vite 無 SSR），那么最強(qiáng)大和最受歡迎的路由庫是React Router。另一個(gè)新的選擇是 TanStack Router，它特別考慮了 TypeScript 的支持。

當(dāng)在 React 中通過 React Router 使用客戶端路由時(shí)，在路由級(jí)別上引入代碼分割并不復(fù)雜。如果進(jìn)行此類優(yōu)化，可以使用@loadable/component替換React.lazy()。

建議：

• 最常用的：React Router
• 新興趨勢(shì)：TanStack Router

• 主要因其一流的 TypeScript 支持

樣式

作為 React 的初學(xué)者，可以通過在 JSX 中使用樣式對(duì)象來從內(nèi)聯(lián)樣式和簡(jiǎn)單的 CSS 開始。然而，對(duì)于實(shí)際應(yīng)用，應(yīng)避免頻繁使用這種方法。

const Headline = ({ title }) =>
  <h1 style={{ color: 'blue' }}>
    {title}
  </h1>

在React 的 JSX 中，雖然可以使用 JavaScript 動(dòng)態(tài)地添加內(nèi)聯(lián)樣式，但為了保持代碼的整潔和可維護(hù)性，通常建議將大部分樣式放在外部 CSS 文件中。這樣，所有的樣式規(guī)則都可以集中在一個(gè)地方，便于管理和修改。

import './Headline.css';

const Headline = ({ title }) =>
  <h1 className="headline" style={{ color: 'blue' }}>
    {title}
  </h1>

首先，建議了解一下 CSS 模塊。作為眾多 CSS-in-CSS 解決方案中的一種，它能夠?qū)?CSS 封裝到與組件同源的模塊中。這樣一來，樣式就不用擔(dān)心會(huì)不小心泄露到其他組件中。

import styles from './style.module.css';

const Headline = ({ title }) =>
  <h1 className={styles.headline}>
    {title}
  </h1>

其次，推薦使用 Styled Components，這是眾多 CSS-in-JS 解決方案中的一種，專門為 React 設(shè)計(jì)。Styled Components（或其替代品如 emotion）允許將使用 JavaScript 創(chuàng)建的樣式與 React 組件放在同一文件或相鄰文件中。這種方法有助于保持代碼的整潔和組織性，并減少樣式的意外泄露。

import styled from 'styled-components';

const BlueHeadline = styled.h1`
  color: blue;
`;

const Headline = ({ title }) =>
  <BlueHeadline>
    {title}
  </BlueHeadline>

第三，推薦使用 Tailwind CSS，這是最流行的實(shí)用型 CSS 解決方案。它提供了預(yù)定義的 CSS 類，這使得開發(fā)人員更高效，并簡(jiǎn)化了 React 應(yīng)用的設(shè)計(jì)系統(tǒng)。然而，使用 Tailwind CSS 需要了解所有預(yù)定義的類，并且在某些情況下可能需要冗長(zhǎng)的內(nèi)聯(lián)樣式。

const Headline = ({ title }) =>
  <h1 className="text-blue-700">
    {title}
  </h1>

最終選擇哪種樣式方案取決于你的具體需求和偏好。目前，實(shí)用類優(yōu)先的 CSS（如Tailwind CSS）是主流趨勢(shì)。如果希望在 React 中根據(jù)條件應(yīng)用樣式，可以考慮使用像 clsx 這樣的實(shí)用庫。

建議：

• 實(shí)用類優(yōu)先：Tailwind CSS（最流行）
• CSS-in-CSS：CSS Modules
• CSS-in-JS（不推薦在服務(wù)端環(huán)境中使用運(yùn)行時(shí)的 CSS-in-JS，因?yàn)榇嬖谛阅軉栴}）：Styled Components 或 Facebook 的 StyleX
• CSS-in-TS（支持 TypeScript 和服務(wù)端渲染）

組件庫

對(duì)于初學(xué)者來說，親手構(gòu)建可復(fù)用的組件是極佳的學(xué)習(xí)經(jīng)驗(yàn)。無論需要?jiǎng)?chuàng)建一個(gè)下拉菜單、選擇框、單選按鈕還是復(fù)選框，都應(yīng)該學(xué)會(huì)如何獨(dú)立地完成這些 UI 組件。

當(dāng)然，如果你覺得創(chuàng)建所有組件的工作過于繁重，可以選擇使用現(xiàn)成的 UI 庫。這些庫已經(jīng)準(zhǔn)備了許多預(yù)先構(gòu)建的組件，并且它們都遵循相同的設(shè)計(jì)原則、功能性和無障礙性標(biāo)準(zhǔn)：

• Ant Design
• Material UI（MUI）：在自由職業(yè)項(xiàng)目中最受歡迎。
• Mantine UI：2022 年最受歡迎。
• Chakra UI：2021 年最受歡迎。
• NextUI：基于 React Aria。
• Park UI：基于 Ark UI。

不過，值得注意的是，UI庫的發(fā)展趨勢(shì)正朝向無樣式化轉(zhuǎn)變。這些新的庫沒有固定的樣式，但它們具備現(xiàn)代組件庫所必需的所有功能和無障礙性。它們經(jīng)常與像Tailwind這樣的實(shí)用CSS解決方案配合使用：

• shadcn/ui：2023 年最受歡迎
• Radix
• React Aria
• Catalyst
• Daisy UI
• Headless UI
• Ark UI：來自 Chakra UI 制造商的庫。

盡管這些UI庫都自帶組件，但它們無法像專注于單一UI組件的庫那樣強(qiáng)大。例如，使用react-table-library 可以在 React 中創(chuàng)建功能強(qiáng)大的表格組件，同時(shí)它還提供各種主題（如Material UI），能夠輕松地與UI庫集成。

動(dòng)畫

在 Web 應(yīng)用中，所有動(dòng)畫都始于 CSS。但隨著需求的發(fā)展，CSS 動(dòng)畫可能無法滿足需求。這時(shí)，開發(fā)人員通常會(huì)尋求動(dòng)畫庫的幫助，它使你能夠使用 React 組件進(jìn)行動(dòng)畫操作。一些廣受好評(píng)的 React 動(dòng)畫庫包括：

• Framer Motion（最推薦）
• react-spring
• react-motion
• react-move

可視化

在 React 中創(chuàng)建圖表時(shí)，開發(fā)人員通常會(huì)選擇一些預(yù)先構(gòu)建的圖表庫，以換取更高的靈活性和可定制性。然而，如果希望從頭開始創(chuàng)建圖表，那么D3是一個(gè)無法回避的選擇。它是一個(gè)基礎(chǔ)的可視化庫，提供了創(chuàng)建精美圖表所需的所有工具。

然而，由于學(xué)習(xí) D3 需要投入大量的時(shí)間和精力，許多開發(fā)人員更傾向于選擇一個(gè)React圖表庫。這些庫提供了現(xiàn)成的圖表、強(qiáng)大的可組合性，并且可以根據(jù)需要進(jìn)行定制。一些流行的 React 圖表庫包括：

• Echarts
• Recharts

• 現(xiàn)成的圖表
• 強(qiáng)大的可組合性
• 可選定制

• visx

• 更傾向于低層次的 D3 而不是高層次的抽象

• 學(xué)習(xí)難度大

• 現(xiàn)成的圖表較多，定制難度較高

• Victory

• nivo

• react-chartjs

表單

在 React 中，最受歡迎的表單庫是 React Hook Form。它提供了所需的所有功能：驗(yàn)證（最受歡迎的集成是 zod）、表單提交和表單狀態(tài)管理。作為替代方案，還有 Formik 和React Final Form 可供選擇。

建議：

• React Hook Form：與 zod 集成進(jìn)行驗(yàn)證

類型檢查

React 自帶了一個(gè)名為 PropTypes 的內(nèi)置屬性驗(yàn)證功能。通過 PropTypes可以為 React 組件定義屬性。如果向組件傳遞了類型錯(cuò)誤的屬性，將收到錯(cuò)誤消息。

import PropTypes from 'prop-types';

const List = ({ list }) => (
  <div>
    {list.map((item) => (
      <div key={item.id}>{item.title}</div>
    ))}
  </div>
);

List.propTypes = {
  list: PropTypes.array.isRequired,
};

盡管 PropTypes 曾經(jīng)是 React 的一個(gè)重要組成部分，但現(xiàn)在它們已經(jīng)不再包含在 React 中了。由于歷史原因，這里仍然提到了它們，但強(qiáng)烈建議不要使用它。

對(duì)于現(xiàn)代的 React 應(yīng)用，行業(yè)標(biāo)準(zhǔn)是使用 TypeScript。如今，幾乎所有的新 React 項(xiàng)目都采用 TypeScript，因此建議你也嘗試在 React 中使用 TypeScript。

type Item = {
  id: string;
  title: string;
};

type ListProps = {
  list: Item[];
};

const List = ({ list }: ListProps) => (
  <div>
    {list.map((item) => (
      <div key={item.id}>{item.title}</div>
    ))}
  </div>
);

如果需要進(jìn)行更高級(jí)的有類型表單驗(yàn)證、API 驗(yàn)證（例如使用 tRPC）等，可以考慮使用 Zod。

建議：

• 如果需要 JavaScript 的類型，就使用 TypeScript。

代碼結(jié)構(gòu)

如果希望在 React 項(xiàng)目中采用統(tǒng)一且符合常識(shí)的代碼風(fēng)格，強(qiáng)烈推薦使用 ESLint。ESLint是一個(gè)強(qiáng)大的代碼檢查工具，可以強(qiáng)制執(zhí)行特定的編碼標(biāo)準(zhǔn)。例如，可以配置 ESLint 來遵循流行的風(fēng)格指南（如Airbnb風(fēng)格指南），以確保代碼的一致性和規(guī)范性。

同時(shí)，如果希望自動(dòng)化地格式化代碼，Prettier 也是一個(gè)不錯(cuò)的選擇。Prettier是一個(gè)無配置項(xiàng)的代碼格式化工具，可以輕松集成到編輯器中。每次保存文件時(shí)，它會(huì)自動(dòng)格式化代碼，使代碼更易于閱讀和維護(hù)。

ESLint 和 Prettier 可以很好地協(xié)同工作。ESLint 主要用于檢查代碼中的錯(cuò)誤和潛在問題，而 Prettier 則專注于使代碼格式更加一致和易于閱讀。因此，結(jié)合使用兩者可以大大提高代碼質(zhì)量和開發(fā)效率。

另外，值得注意的是，隨著時(shí)間的推移，可能會(huì)有新的工具和技術(shù)出現(xiàn)并取代 ESLint 和 Prettier 的地位。Biome（前身為Rome）是一個(gè)值得關(guān)注的新興工具，它旨在提供一個(gè)快速且一體化的代碼檢查和格式化解決方案。

建議：

• ESLint + Prettier
• 給 Biome 一個(gè)機(jī)會(huì)

身份驗(yàn)證

在 React 應(yīng)用中實(shí)現(xiàn)身份驗(yàn)證功能時(shí)，通常涉及到用戶注冊(cè)、登錄、注銷以及可能的密碼重置和密碼更改等功能。然而，這些功能超出了 React 本身的范圍，因?yàn)閷?shí)際的身份驗(yàn)證邏輯通常由后端應(yīng)用程序處理。

建議使用這些身份驗(yàn)證/后端即服務(wù)解決方案中的一種：

• Lucia
• Supabase Auth
• Clerk
• AuthKit
• NextAuth
• Firebase Auth
• Auth0
• AWS Cognito

后端

隨著 React 在服務(wù)端的應(yīng)用日益普及，像 Next.js、Astro 或 Remix 這樣的元框架成為了 React 項(xiàng)目的理想選擇。這些框架提供了構(gòu)建全棧應(yīng)用所需的一切，同時(shí)充分發(fā)揮了React的優(yōu)勢(shì)。

如果由于某些原因無法使用全棧框架，但仍然希望使用 JavaScript 或 TypeScript，那么可以考慮使用 tRPC 或 Hono。這兩者都是強(qiáng)大的后端解決方案，能夠與 React 前端無縫集成。

當(dāng)然，我們也不能忽視那些傳統(tǒng)的后端框架。Express 框架仍然備受推崇，盡管它可能不是最前沿的技術(shù)，但其穩(wěn)定性和成熟度使其成為許多項(xiàng)目的首選。其他值得考慮的選項(xiàng)包括 Fasitfy 和 Nest.js，它們都具有強(qiáng)大的功能和靈活性，能夠滿足各種后端需求。

數(shù)據(jù)庫

盡管 React 本身并不直接與數(shù)據(jù)庫交互，但隨著全棧 React 應(yīng)用的普及，它與數(shù)據(jù)庫的交互越來越緊密。在開發(fā) Next.js 應(yīng)用時(shí)，可能會(huì)遇到數(shù)據(jù)庫對(duì)象關(guān)系映射器（ORM）。目前最受歡迎的 ORM 是 Prisma。另一個(gè)值得考慮的選項(xiàng)是 Drizzle ORM。其他可用的選項(xiàng)包括 Kysely 和 database-js（僅適用于PlanetScale）。

選擇合適的數(shù)據(jù)庫時(shí)，Supabase 和 Firebase 是兩個(gè)流行的數(shù)據(jù)庫提供商。Supabase 提供 PostgreSQL，既可自托管也可作為付費(fèi)服務(wù)使用。對(duì)于無服務(wù)器數(shù)據(jù)庫，PlanetScale、Neon 和 Xata 是值得考慮的替代方案。

測(cè)試

測(cè)試 React 應(yīng)用的核心是使用如 Jest 這樣的測(cè)試框架。Jest 提供了測(cè)試運(yùn)行器、斷言庫以及其他實(shí)用的功能，滿足全面測(cè)試框架的需求。如果傾向于使用 Vite，Vitest 是一個(gè)值得考慮的 Jest 替代方案。

在測(cè)試框架中渲染 React 組件時(shí)，可以使用 react-test-renderer。這足以進(jìn)行所謂的快照測(cè)試，這是通過 Jest 或 Vitest 進(jìn)行的。快照測(cè)試的工作方式如下：一旦運(yùn)行測(cè)試，會(huì)為 React 組件的渲染DOM元素創(chuàng)建快照。在未來的某個(gè)時(shí)間點(diǎn)再次運(yùn)行測(cè)試時(shí)，將創(chuàng)建另一個(gè)快照，并使用它與前一個(gè)快照進(jìn)行比較。如果差異不匹配，測(cè)試框架會(huì)發(fā)出警告，可以選擇接受快照或調(diào)整組件。

隨著時(shí)間的推移，你可能會(huì)發(fā)現(xiàn)自己在測(cè)試框架環(huán)境中使用React Testing Library（RTL）。RTL是一個(gè)全面的 React 測(cè)試庫，可以在測(cè)試框架環(huán)境中使用。它能夠渲染組件并模擬HTML元素上的事件。然后，可以使用測(cè)試框架進(jìn)行斷言。

如果正在尋找用于 React 端到端（E2E）測(cè)試的測(cè)試工具，Playwright 和 Cypress 是最受歡迎的選擇。

建議：

• 單元/集成測(cè)試：Vitest + React Testing Library（最受歡迎）
• 快照測(cè)試：Vitest
• E2E測(cè)試：Playwright 或 Cypress

不可變數(shù)據(jù)結(jié)構(gòu)

在 JavaScript 中，原生提供了許多工具來處理數(shù)據(jù)結(jié)構(gòu)，使其看似不可變。但如果有必要強(qiáng)制使用不可變數(shù)據(jù)結(jié)構(gòu)，Immer 是一個(gè)廣受歡迎的選擇。

國際化

在為 React 應(yīng)用進(jìn)行國際化時(shí)，需要考慮的不僅是翻譯，還包括復(fù)數(shù)形式、日期和貨幣格式化等方面。以下是一些流行的庫，可用于處理這些問題：

• FormatJS
• react-i18next
• Lingui

時(shí)間處理

當(dāng) React 應(yīng)用需要處理大量日期、時(shí)間和時(shí)區(qū)時(shí)，引入一個(gè)專門管理這些內(nèi)容的庫是很有用的。以下是一些可用的選項(xiàng)：

• date-fns
• Day.js
• Luxon

桌面應(yīng)用

Electron 和 Tauri 是跨平臺(tái)桌面應(yīng)用的框架。

移動(dòng)應(yīng)用

如果想將 React 從 Web 移植到移動(dòng)平臺(tái)，React Native 仍然是最佳選擇。Expo 作為最流行的框架，可以輕松創(chuàng)建 React Native 應(yīng)用。而如果需要實(shí)現(xiàn)跨 Web 和移動(dòng)端的統(tǒng)一組件，Tamagui 是一個(gè)值得考慮的方案。

文件上傳

• react-dropzone

郵件

• react-email
• Mailing
• mjml

拖拽

react-beautiful-dnd 是最受歡迎的 React 拖拽庫。dnd kit 是一個(gè)流行的替代品，它提供了更多的靈活性和選項(xiàng)，但學(xué)習(xí)難度也更大。在該領(lǐng)域中，react-dnd 也是一個(gè)不錯(cuò)的選擇。

VR/AR

React 也可以用于開發(fā)虛擬現(xiàn)實(shí) (VR) 和增強(qiáng)現(xiàn)實(shí) (AR) 的應(yīng)用。大部分庫仍處于早期階段（實(shí)驗(yàn)階段），但以下是與 React 相關(guān)的 AR/VR 庫：

• react-three-fiber
• react-360
• aframe-react

文檔

在編寫組件文檔時(shí)，有許多優(yōu)秀的 React 文檔工具可供選擇：

• Storybook
• Docusaurus
• Docz
• Styleguidist

小結(jié)

React 生態(tài)系統(tǒng)可以被視為 React 的一個(gè)框架，但它保持了對(duì) React 的靈活性。這是一個(gè)靈活的框架，可以自行決定選擇加入哪些庫。可以從小處著手，只添加解決特定問題的庫。相反，如果 React 就是所需的全部，可以只使用它，保持輕量級(jí)。