做前端开发的人应该都有过这样的经历刚把 React 的基础语法、Hooks 弄明白还没来得及开心就被铺天盖地的“生态库”淹没了。打开招聘网站的 React 岗位描述要求里永远写着熟练使用 Redux、React Router、Next.js、Ant Design逛技术社区看到别人在用 Zustand、TanStack Query、React Hook Form跟同事聊天他还在 Remix 和 Next.js 之间纠结选型。很多人会把这种状态归因为“React 生态太乱”。但我想给一个不同的判断React 生态的丰富不是混乱而是分层清晰。真正让新手痛苦的不是库太多而是没有人把这套组合逻辑讲成一条主线。大多数教程都在单独讲某个库的 API却没有回答一个更关键的问题——在一个真实项目里这些库到底是怎么各司其职、互相配合的这篇文章想做的就是把 React 目前的主流库按照它们解决的问题重新整理一遍。不追求逐个 API 罗列而是理清“每一层选型解决什么问题、有哪些主流选择、实际项目里怎么搭配”。读完你会得到一张完整的 React 技术栈地图以后无论是自己搭项目还是看别人的项目都不会再迷路。1. 为什么 React 生态会有这么多库要理解 React 生态为什么看起来“乱”得先理解 React 本身的定位。React 官方定位一直很克制它是一个用于构建用户界面的库。这句话翻译过来就是——React 只负责把组件渲染到页面上以及管理组件内部的状态。至于路由怎么跳、全局数据怎么存、请求怎么发、表单怎么校验、样式怎么写React 官方有意不给出唯一答案而是把空间留给社区。这和 Vue 有明显区别。Vue 生态里Vue Router、Pinia、Vuex 几乎可以算是官方指定方案新手照着官方文档就能搭出一套标准项目。React 没有这种待遇于是社区里自然涌现出了大量尝试每个方向都有多个主流竞争者。这种局面带来的问题是选择困难但带来的好处是每个方向最终都会收敛出某个更优解。比如状态管理从 Redux 一家独大到 Zustand、Jotai 这些轻量方案崛起再到 Redux Toolkit 统一了官方推荐写法。此时再看所谓的“React 库很多”本质上是在看一个动态收敛过程。理解了这一点后面的选型思路会清晰很多。2. 框架层选型Next.js、Remix 还是纯 React SPA第一个环节是框架选择这决定了项目的地基。今天的 React 项目已经很少直接裸写 React 后再手动配 Webpack 或 Vite 了主流方式是直接选用一个框架。2.1 Next.js当前 React 项目的默认起点Next.js 是当下 React 生态里影响力最大的框架。它基于 React提供了文件路由、服务端渲染、静态站点生成、API 路由等一系列功能。过去要在 React 项目里自己折腾 SSR、路由、构建配置现在 Next.js 把这些问题全部标准化了。Next.js 最大的价值在于解决了首屏渲染和 SEO 问题。纯客户端渲染的 React 项目首屏要等 JS 加载、执行才能渲染出内容搜索引擎的爬虫不一定能完整拿到页面内容。Next.js 支持在服务端把组件渲染成 HTML 直接返回用户的感知速度和 SEO 效果都会好很多。当前 Next.js 的版本已经进入了 App Router 时代。App Router 使用 React Server Components 作为默认模型这意味着组件默认在服务端执行只有显式标注use client的组件才会在浏览器端运行。这个变化对 React 开发模式的影响很大需要把“数据获取在哪里发生”纳入设计考虑。2.2 Remix更强调 Web 标准的 React 框架Remix 是另一个有影响力的 React 全栈框架。它的核心思想是充分利用 Web 标准把数据加载、表单提交、缓存这些能力建立在浏览器原生的 fetch、request、response 模型之上。Remix 和 Next.js 的差别可以从一个实际体验看出来在 Next.js 里做表单提交你会习惯写useState管理表单状态再通过fetch调用 API在 Remix 里更正统的方式是直接用原生form提交在action函数里处理数据。Remix 让表单在未加载 JavaScript 时也能工作这比很多 SPA 方案更接近传统 Web 的工作方式。对于新项目如果团队追求极致的 Web 语义化、希望表单交互更简单可以考虑 Remix。但客观说从社区规模、模板数量、招聘市场需求来看Next.js 的生态优势依然明显。2.3 纯 React SPA用 Vite 搭建如果项目是一个后台管理系统、内部工具或者对 SEO 完全无要求那么不需要服务端渲染直接使用 Vite 创建纯 React SPA 是更轻量的选择。npm create vitelatest my-app -- --template react-ts cd my-app npm install npm run dev这种方式构建快、开发体验好、部署只需要静态文件服务器。应用内的路由跳转、状态管理、数据请求都可以由客户端方案解决不必引入 Node.js 服务端。所以框架层选型的结论很简单需要 SEO、需要首屏快、需要服务端能力 → Next.js追求 Web 标准、项目以表单和数据交互为主 → Remix内部系统、纯前端后台、无 SEO 需求 → Vite React SPA3. 路由方案React Router 与 TanStack Router路由是 React 应用绕不开的环节。React 本身没有路由方案最长时间里社区的标准答案都是 React Router。3.1 React Router事实标准React Router 已经迭代到了第六个大版本。它最核心的 API 是声明式路由和 HooksuseNavigate用于跳转useParams用于读取路径参数useLocation用于读取当前地址信息。// 文件路径src/router/index.jsx import { createBrowserRouter, RouterProvider } from react-router-dom; import Home from ../pages/Home; import User from ../pages/User; const router createBrowserRouter([ { path: /, element: Home /, }, { path: /user/:id, element: User /, }, ]); export default function AppRouter() { return RouterProvider router{router} /; }// 文件路径src/pages/User.jsx import { useParams, useNavigate } from react-router-dom; export default function User() { const { id } useParams(); const navigate useNavigate(); return ( div p当前用户 ID{id}/p button onClick{() navigate(/)}返回首页/button /div ); }React Router 的使用范围很广从简单的页面跳转到嵌套路由、路由守卫、面包屑联动都能做。对于绝大多数 React 项目它依然是最稳妥的默认选择。3.2 TanStack Router以类型安全为卖点的新选择TanStack Router 是 TanStack 家族的一员核心卖点是类型安全。它支持路由参数类型的自动推断还有内置的搜索参数管理。import { createFileRoute } from tanstack/react-router; export const Route createFileRoute(/user/$id)({ component: UserPage, }); function UserPage() { const { id } Route.useParams(); return div用户 ID{id}/div; }如果你是一个对 TypeScript 类型完整性要求很高的团队TanStack Router 的体验会比 React Router 更舒服。但它的社区资料、第三方集成成熟度跟 React Router 相比还有差距选型时需要权衡。4. 状态管理Context、Zustand、Redux Toolkit、Jotai状态管理是 React 技术栈里被讨论最多的话题。很多开发者第一次崩溃就是发生在“为什么我用了 Redux 但状态还是乱了”的时候。4.1 先分清两种状态要理解状态管理先要分清楚两种状态服务端状态和客户端状态。服务端状态来自后端接口的数据比如用户列表、订单详情。这些状态需要从服务器获取、缓存、更新、失效。客户端状态界面上本地产生的数据比如弹窗是否打开、表单当前填了什么、当前选中的 Tab。这两种状态的管理方式完全不同。服务端状态应该交给数据请求库后面会讲客户端状态才需要全局状态管理的介入。4.2 ContextReact 内置方案Context 是 React 内置的跨组件通讯机制。它的优点是不需要安装额外依赖适合存放“低频更新”的全局数据比如用户登录信息、主题色。// 文件路径src/store/UserContext.jsx import { createContext, useContext, useState } from react; const UserContext createContext(null); export function UserProvider({ children }) { const [user, setUser] useState(null); return ( UserContext.Provider value{{ user, setUser }} {children} /UserContext.Provider ); } export function useUser() { return useContext(UserContext); }// 文件路径src/App.jsx import { UserProvider, useUser } from ./store/UserContext; function Profile() { const { user } useUser(); return div{user ? 你好${user.name} : 未登录}/div; } export default function App() { return ( UserProvider Profile / /UserProvider ); }当项目规模增长以后Context 的问题会暴露出来所有消费同一个 Context 的组件在值变化时都会重新渲染很难做细粒度的性能优化。所以 Context 适合低频数据、小项目不建议用它管理频繁变化的大型全局状态。4.3 Zustand当前最被推荐的轻量方案Zustand 是目前增长趋势很明显的状态管理库。它用一个很简单的思路解决了 Context 的痛点创建一个外部 store组件通过 Hook 订阅自己关心的那部分状态。状态更新时只有订阅了对应数据的组件会重新渲染。// 文件路径src/store/cartStore.js import { create } from zustand; export const useCartStore create((set) ({ items: [], addItem: (item) set((state) ({ items: [...state.items, item], })), removeItem: (id) set((state) ({ items: state.items.filter((item) item.id ! id), })), }));// 文件路径src/components/CartButton.jsx import { useCartStore } from ../store/cartStore; export default function CartButton() { const items useCartStore((state) state.items); const addItem useCartStore((state) state.addItem); return ( button onClick{() addItem({ id: 1, name: React 实战课程 })} 添加商品当前 {items.length} 件 /button ); }Zustand 的优点是不需要 Provider 包裹、代码量少、TypeScript 支持好、函数式更新灵活。对于中小型项目Zustand 属于“开箱即用、心智负担低”的选择。4.4 Redux Toolkit大型项目的官方推荐写法Redux 曾经是 React 状态管理的代名词但早期版本的样板代码很多。现在的官方推荐写法是 Redux ToolkitRTK把 createStore、combineReducers、redux-thunk 全部统一成了简洁的 API。// 文件路径src/store/userSlice.js import { createSlice } from reduxjs/toolkit; const initialState { profile: null, loading: false, }; const userSlice createSlice({ name: user, initialState, reducers: { setProfile: (state, action) { state.profile action.payload; }, setLoading: (state, action) { state.loading action.payload; }, }, }); export const { setProfile, setLoading } userSlice.actions; export default userSlice.reducer;// 文件路径src/store/index.js import { configureStore } from reduxjs/toolkit; import userReducer from ./userSlice; export const store configureStore({ reducer: { user: userReducer, }, });// 文件路径src/main.jsx import React from react; import ReactDOM from react-dom/client; import { Provider } from react-redux; import { store } from ./store; import App from ./App; ReactDOM.createRoot(document.getElementById(root)).render( Provider store{store} App / /Provider );RTK 配套的 RTK Query 还能直接处理数据请求和缓存适合作为团队统一状态管理方案。缺点是对新手的理解门槛偏高Action、Reducer、Selector 的概念需要一段时间消化。4.5 Jotai原子化状态Jotai 的思想是“原子状态”把状态拆成最小单元组件按需组合。它比 Zustand 更强调原子性适合状态复用复杂、派生状态多的场景。不过在实际项目里Zustand 的接受度一般高于 Jotai这更多是习惯和社区选择的问题。状态管理的选择结论项目很小、全局状态少 → Context中大型项目、个人开发或小团队 → Zustand大型项目、老团队、需要严格规范 → Redux Toolkit状态碎片化、派生逻辑复杂 → Jotai5. 服务端状态与数据请求TanStack Query 与 SWR这是 React 生态里最值得重视的一块也最容易被新手忽略。大多数项目的主要状态其实来自后端接口如果这些数据全部用全局状态管理去存会陷入缓存失效、重复请求、加载状态混乱的困境。5.1 TanStack QueryReact QueryTanStack Query 的核心价值是把服务端数据变成可缓存的资源。你只需要声明这个数据怎么获取它就会自动管理缓存、加载中、错误、更新、重新请求等一整套生命周期。// 文件路径src/api/useUsers.js import { useQuery } from tanstack/react-query; async function fetchUsers() { const res await fetch(/api/users); if (!res.ok) { throw new Error(请求失败); } return res.json(); } export function useUsers() { return useQuery({ queryKey: [users], queryFn: fetchUsers, }); }// 文件路径src/components/UserList.jsx import { useUsers } from ../api/useUsers; export default function UserList() { const { data, isLoading, isError } useUsers(); if (isLoading) { return div加载中.../div; } if (isError) { return div加载失败请稍后重试/div; } return ( ul {data.map((user) ( li key{user.id}{user.name}/li ))} /ul ); }TanStack Query 还会自动处理窗口重新聚焦时的数据刷新、分页和无限滚动查询、乐观更新等高级场景。它大幅减少了手写useEffectsetState的样板代码。5.2 SWRSWR 是 Vercel 团队推出的数据请求库名字来自 HTTP 缓存策略的 stale-while-revalidate。用起来和 TanStack Query 很相似但 API 更轻import useSWR from swr; const fetcher (url) fetch(url).then((res) res.json()); export default function Profile() { const { data, error, mutate } useSWR(/api/profile, fetcher); if (error) return div加载失败/div; if (!data) return div加载中.../div; return ( div p{data.name}/p button onClick{() mutate({ ...data, name: New Name })} 更新名称 /button /div ); }TanStack Query 和 SWR 二选一即可。从功能完整度和生态来说TanStack Query 更占优势如果项目里已经大量使用 Vercel 系工具SWR 是更顺手的补充。6. 表单方案React Hook Form 与 Formik表单在前端项目中的占比非常高同时也是代码量容易被低估的部分。校验规则、错误提示、脏状态、提交状态、性能每一项都需要处理。6.1 React Hook Form当前 React 表单方案的主流选择是 React Hook Form。它的核心优势在于利用非受控组件 ref 减少不必要的渲染再配合校验库 zod 做类型安全的校验。// 文件路径src/components/LoginForm.jsx import { useForm } from react-hook-form; import { z } from zod; import { zodResolver } from hookform/resolvers/zod; const schema z.object({ email: z.string().email(请输入正确的邮箱), password: z.string().min(6, 密码至少 6 位), }); export default function LoginForm() { const { register, handleSubmit, formState: { errors }, } useForm({ resolver: zodResolver(schema), }); const onSubmit (data) { console.log(提交数据, data); }; return ( form onSubmit{handleSubmit(onSubmit)} div input typeemail placeholder邮箱 {...register(email)} / {errors.email span{errors.email.message}/span} /div div input typepassword placeholder密码 {...register(password)} / {errors.password span{errors.password.message}/span} /div button typesubmit登录/button /form ); }React Hook Form 在处理大型表单、动态表单项方面表现很好社区解决方案也比较成熟。6.2 FormikFormik 曾经是 React 表单的主流方案但它的受控模式在多字段表单里渲染成本偏高目前新项目中使用 React Hook Form 的占比明显更高。如果维护的是老项目Formik 的代码仍然值得会读、会改。7. 样式方案与 UI 组件库样式方案是 React 技术栈中最因人而异的部分因为团队偏好差异很大。7.1 CSS ModulesCSS Modules 是当前最稳妥、心智负担最低的样式方案之一。它通过构建工具自动把 class 名变成带哈希的唯一值避免全局污染。/* 文件路径src/components/Button.module.css */ .btn { padding: 8px 16px; border-radius: 4px; background: #1677ff; color: #fff; border: none; cursor: pointer; }// 文件路径src/components/Button.jsx import styles from ./Button.module.css; export default function Button({ children }) { return button className{styles.btn}{children}/button; }CSS Modules 适合工程团队样式写在普通 CSS 文件里没有额外运行时成本也没有复杂的学习曲线。7.2 Tailwind CSSTailwind CSS 是当前热度很高的原子化 CSS 方案。它提供大量工具类直接在 JSX 里组合export default function Button({ children }) { return ( button classNamerounded-md bg-blue-500 px-4 py-2 text-white hover:bg-blue-600 {children} /button ); }Tailwind 的优势是快速构建界面、样式一致性好、打包体积因为未使用样式的剔除而更小。缺点是 JSX 中 class 列表会很长团队需要适应一种“写样式像写属性”的节奏。7.3 主流 UI 组件库UI 组件库可以作为中后台项目的底座Ant Design国内中后台项目的事实标准组件全面文档和社区资料丰富。Material UI谷歌 Material Design 规范的 React 实现国际化程度高。shadcn/ui基于 TailwindCSS Radix UI 的组件集合不依赖 npm 包而是将组件源码直接复制进项目适合需要完全掌控样式的团队。选型思路如果团队开发速度优先、需要开箱即用的中后台页面选择 Ant Design 很稳如果是产品型前端项目、对设计规范要求高shadcn/ui 或 Material UI 都值得考虑。8. 配套工具测试、动画与虚拟列表除了核心选型一个完整的 React 工程还会用到以下几类配套库。8.1 测试React 项目的官方推荐测试组合是 Vitest/Jest React Testing Library Testing Library 的 jest-dom 匹配器。// 文件路径src/components/Counter.test.jsx import { render, screen, fireEvent } from testing-library/react; import { describe, it, expect } from vitest; import Counter from ./Counter; describe(Counter 组件, () { it(点击按钮后计数增加, () { render(Counter /); const button screen.getByRole(button, { name: 增加 }); fireEvent.click(button); expect(screen.getByText(计数1)).toBeInTheDocument(); }); });React Testing Library 的理念是站在用户角度测试尽量避免直接测试组件内部实现。这种做法让测试更接近真实行为重构时不需要频繁改测试。8.2 动画React 生态里比较常用的动画库是 Framer Motion。它提供了声明式的动画组件支持页面切换、元素进入离开、手势交互动画API 设计贴合 React 开发习惯。import { motion } from framer-motion; export default function Card() { return ( motion.div initial{{ opacity: 0, y: 20 }} animate{{ opacity: 1, y: 0 }} transition{{ duration: 0.5 }} 内容卡片 /motion.div ); }对需要复杂动画效果的产品项目Framer Motion 基本是首选。8.3 虚拟列表当页面需要渲染大量数据比如日志列表、用户表格、聊天记录时直接渲染全部 DOM 会导致页面卡顿。虚拟列表组件会只渲染可视区域内的元素滚动时动态替换。常见的方案有tanstack/react-virtual和react-window。TanStack Virtual 和 TanStack Query 同属一个生态API 风格统一适合已经在使用 TanStack 系列的项目。import { useVirtualizer } from tanstack/react-virtual; import { useRef } from react; export default function VirtualList({ items }) { const parentRef useRef(null); const virtualizer useVirtualizer({ count: items.length, getScrollElement: () parentRef.current, estimateSize: () 40, }); return ( div ref{parentRef} style{{ height: 400px, overflow: auto }} div style{{ height: ${virtualizer.getTotalSize()}px, position: relative, }} {virtualizer.getVirtualItems().map((virtualItem) ( div key{virtualItem.key} style{{ position: absolute, top: 0, left: 0, width: 100%, height: ${virtualItem.size}px, transform: translateY(${virtualItem.start}px), }} {items[virtualItem.index]} /div ))} /div /div ); }9. 一套可落地的 React 技术栈推荐上面讲了很多选型这里给三套组合方案对应不同场景。9.1 中后台管理系统中后台最关键的是开发效率和一致性适合使用相对完整、资料多的方案框架Vite React TypeScript路由React Router样式CSS Modules Ant Design客户端状态Zustand服务端状态TanStack Query表单React Hook Form zod数据请求fetch/axios 封装这套组合的优势是各层职责清晰Ant Design 负责控件React Hook Form 负责表单逻辑TanStack Query 负责接口数据Zustand 只处理少量全局 UI 状态。9.2 面向 C 端的 Web 应用这类场景往往需要首屏速度和 SEO框架Next.js样式TailwindCSS按情况接入 shadcn/ui服务端状态TanStack Query 或 SWR客户端状态Context 足够则不引入额外库需要再上 Zustand动画Framer Motion为什么首选 Next.js因为 C 端产品对首屏要求高Next.js 的 SSR 和图片优化开箱即用Tailwind 适合快速迭代界面如果项目是 Next.js 全栈应用还能用 Server Actions 简化数据变更逻辑。9.3 个人项目或快速原型个人项目最怕被工具细节拖住少即是多框架Vite React路由先用 React Router状态Context React 内置能力不引入重量级状态库样式TailwindCSS数据直接写 axios 或 fetch量大了再升级 TanStack Query先跑通核心功能等痛点出现再补工具。比起一开始就把所有库装齐更重要的是保持技术栈的可替换性。10. 常见问题与选型排坑清单问题现象可能原因排查方式解决方案状态一直不同步把接口响应数据直接用 useState 管理缓存和更新逻辑混乱检查数据更新时是否有组件未重新渲染接口返回后是否有手动 setState 链将服务端数据交给 TanStack Query 或 SWR 管理Context 改动导致大量组件重新渲染Context Value 每次 render 都是新引用所有消费方全部刷新使用 React DevTools 分析 Highlighter 更新范围拆 Context、使用 Zustand 或 Jotai 做细粒度订阅Redux 样板代码太多使用了旧版 Redux 写法反复手写 action type 和 switch case检查 store 目录代码量改用 Redux Toolkit createSliceJSX 中 className 过长可读性差Tailwind 原子类全部堆在 JSX 里查看组件行数是否超出屏幕抽取公共类名、使用 clsx 或 tailwind-merge 组合表单大量输入框导致输入卡顿使用了受控组件且每次输入都触发大范围重新渲染在表单组件里打印 render 次数改用 React Hook Form 非受控模式SSR 项目接口请求混乱useEffect 内发起请求但服务端首屏拿不到数据确认使用框架的数据获取方式是否依赖 useEffectNext.js 中使用 Server Component 或 RSC 内直接请求11. 给开发者的三条实战建议第一选型标准不是“哪个库最流行”而是“这个库解决的是哪一层问题、团队能否驾驭”。把路由、状态、数据、表单、样式这五层分开思考就能避免 A 库和 B 库功能重叠导致的心智混乱。第二警惕不必要的全局状态。很多新手的惯性是只要多个组件要共享一个值就立刻引入全局状态库。其实 90% 的共享数据都可以通过组件树传参、Context、或服务端状态库解决。全局状态库应该是最后考虑的方案而不是第一反应。第三保持技术栈可替换。不要在代码里写死对某个库的依赖比如组件内部直接调用useStore而不是通过自定义 Hook 包一层。当你把数据访问都收敛到自定义 Hooks 后面未来从 Zudtand 换到 Redux Toolkit只需要改 Hook 内部实现业务组件完全不动。这种设计弹性比选到“完美库”更可靠。对 React 学习者来说强烈建议自己动手搭两遍全套项目。第一遍使用中后台推荐组合跑通一个带接口请求、表单校验、路由跳转、状态管理的完整后台页面第二遍使用 Next.js 搭一个内容型页面体会 SSR 和数据获取的区别。两遍做完以后React 生态在你眼里就不再是碎片化的“库”而是一条有主线的技术栈地图。 React 生态主流选型指南：从框架到状态管理的技术栈地图
做前端开发的人应该都有过这样的经历刚把 React 的基础语法、Hooks 弄明白还没来得及开心就被铺天盖地的“生态库”淹没了。打开招聘网站的 React 岗位描述要求里永远写着熟练使用 Redux、React Router、Next.js、Ant Design逛技术社区看到别人在用 Zustand、TanStack Query、React Hook Form跟同事聊天他还在 Remix 和 Next.js 之间纠结选型。很多人会把这种状态归因为“React 生态太乱”。但我想给一个不同的判断React 生态的丰富不是混乱而是分层清晰。真正让新手痛苦的不是库太多而是没有人把这套组合逻辑讲成一条主线。大多数教程都在单独讲某个库的 API却没有回答一个更关键的问题——在一个真实项目里这些库到底是怎么各司其职、互相配合的这篇文章想做的就是把 React 目前的主流库按照它们解决的问题重新整理一遍。不追求逐个 API 罗列而是理清“每一层选型解决什么问题、有哪些主流选择、实际项目里怎么搭配”。读完你会得到一张完整的 React 技术栈地图以后无论是自己搭项目还是看别人的项目都不会再迷路。1. 为什么 React 生态会有这么多库要理解 React 生态为什么看起来“乱”得先理解 React 本身的定位。React 官方定位一直很克制它是一个用于构建用户界面的库。这句话翻译过来就是——React 只负责把组件渲染到页面上以及管理组件内部的状态。至于路由怎么跳、全局数据怎么存、请求怎么发、表单怎么校验、样式怎么写React 官方有意不给出唯一答案而是把空间留给社区。这和 Vue 有明显区别。Vue 生态里Vue Router、Pinia、Vuex 几乎可以算是官方指定方案新手照着官方文档就能搭出一套标准项目。React 没有这种待遇于是社区里自然涌现出了大量尝试每个方向都有多个主流竞争者。这种局面带来的问题是选择困难但带来的好处是每个方向最终都会收敛出某个更优解。比如状态管理从 Redux 一家独大到 Zustand、Jotai 这些轻量方案崛起再到 Redux Toolkit 统一了官方推荐写法。此时再看所谓的“React 库很多”本质上是在看一个动态收敛过程。理解了这一点后面的选型思路会清晰很多。2. 框架层选型Next.js、Remix 还是纯 React SPA第一个环节是框架选择这决定了项目的地基。今天的 React 项目已经很少直接裸写 React 后再手动配 Webpack 或 Vite 了主流方式是直接选用一个框架。2.1 Next.js当前 React 项目的默认起点Next.js 是当下 React 生态里影响力最大的框架。它基于 React提供了文件路由、服务端渲染、静态站点生成、API 路由等一系列功能。过去要在 React 项目里自己折腾 SSR、路由、构建配置现在 Next.js 把这些问题全部标准化了。Next.js 最大的价值在于解决了首屏渲染和 SEO 问题。纯客户端渲染的 React 项目首屏要等 JS 加载、执行才能渲染出内容搜索引擎的爬虫不一定能完整拿到页面内容。Next.js 支持在服务端把组件渲染成 HTML 直接返回用户的感知速度和 SEO 效果都会好很多。当前 Next.js 的版本已经进入了 App Router 时代。App Router 使用 React Server Components 作为默认模型这意味着组件默认在服务端执行只有显式标注use client的组件才会在浏览器端运行。这个变化对 React 开发模式的影响很大需要把“数据获取在哪里发生”纳入设计考虑。2.2 Remix更强调 Web 标准的 React 框架Remix 是另一个有影响力的 React 全栈框架。它的核心思想是充分利用 Web 标准把数据加载、表单提交、缓存这些能力建立在浏览器原生的 fetch、request、response 模型之上。Remix 和 Next.js 的差别可以从一个实际体验看出来在 Next.js 里做表单提交你会习惯写useState管理表单状态再通过fetch调用 API在 Remix 里更正统的方式是直接用原生form提交在action函数里处理数据。Remix 让表单在未加载 JavaScript 时也能工作这比很多 SPA 方案更接近传统 Web 的工作方式。对于新项目如果团队追求极致的 Web 语义化、希望表单交互更简单可以考虑 Remix。但客观说从社区规模、模板数量、招聘市场需求来看Next.js 的生态优势依然明显。2.3 纯 React SPA用 Vite 搭建如果项目是一个后台管理系统、内部工具或者对 SEO 完全无要求那么不需要服务端渲染直接使用 Vite 创建纯 React SPA 是更轻量的选择。npm create vitelatest my-app -- --template react-ts cd my-app npm install npm run dev这种方式构建快、开发体验好、部署只需要静态文件服务器。应用内的路由跳转、状态管理、数据请求都可以由客户端方案解决不必引入 Node.js 服务端。所以框架层选型的结论很简单需要 SEO、需要首屏快、需要服务端能力 → Next.js追求 Web 标准、项目以表单和数据交互为主 → Remix内部系统、纯前端后台、无 SEO 需求 → Vite React SPA3. 路由方案React Router 与 TanStack Router路由是 React 应用绕不开的环节。React 本身没有路由方案最长时间里社区的标准答案都是 React Router。3.1 React Router事实标准React Router 已经迭代到了第六个大版本。它最核心的 API 是声明式路由和 HooksuseNavigate用于跳转useParams用于读取路径参数useLocation用于读取当前地址信息。// 文件路径src/router/index.jsx import { createBrowserRouter, RouterProvider } from react-router-dom; import Home from ../pages/Home; import User from ../pages/User; const router createBrowserRouter([ { path: /, element: Home /, }, { path: /user/:id, element: User /, }, ]); export default function AppRouter() { return RouterProvider router{router} /; }// 文件路径src/pages/User.jsx import { useParams, useNavigate } from react-router-dom; export default function User() { const { id } useParams(); const navigate useNavigate(); return ( div p当前用户 ID{id}/p button onClick{() navigate(/)}返回首页/button /div ); }React Router 的使用范围很广从简单的页面跳转到嵌套路由、路由守卫、面包屑联动都能做。对于绝大多数 React 项目它依然是最稳妥的默认选择。3.2 TanStack Router以类型安全为卖点的新选择TanStack Router 是 TanStack 家族的一员核心卖点是类型安全。它支持路由参数类型的自动推断还有内置的搜索参数管理。import { createFileRoute } from tanstack/react-router; export const Route createFileRoute(/user/$id)({ component: UserPage, }); function UserPage() { const { id } Route.useParams(); return div用户 ID{id}/div; }如果你是一个对 TypeScript 类型完整性要求很高的团队TanStack Router 的体验会比 React Router 更舒服。但它的社区资料、第三方集成成熟度跟 React Router 相比还有差距选型时需要权衡。4. 状态管理Context、Zustand、Redux Toolkit、Jotai状态管理是 React 技术栈里被讨论最多的话题。很多开发者第一次崩溃就是发生在“为什么我用了 Redux 但状态还是乱了”的时候。4.1 先分清两种状态要理解状态管理先要分清楚两种状态服务端状态和客户端状态。服务端状态来自后端接口的数据比如用户列表、订单详情。这些状态需要从服务器获取、缓存、更新、失效。客户端状态界面上本地产生的数据比如弹窗是否打开、表单当前填了什么、当前选中的 Tab。这两种状态的管理方式完全不同。服务端状态应该交给数据请求库后面会讲客户端状态才需要全局状态管理的介入。4.2 ContextReact 内置方案Context 是 React 内置的跨组件通讯机制。它的优点是不需要安装额外依赖适合存放“低频更新”的全局数据比如用户登录信息、主题色。// 文件路径src/store/UserContext.jsx import { createContext, useContext, useState } from react; const UserContext createContext(null); export function UserProvider({ children }) { const [user, setUser] useState(null); return ( UserContext.Provider value{{ user, setUser }} {children} /UserContext.Provider ); } export function useUser() { return useContext(UserContext); }// 文件路径src/App.jsx import { UserProvider, useUser } from ./store/UserContext; function Profile() { const { user } useUser(); return div{user ? 你好${user.name} : 未登录}/div; } export default function App() { return ( UserProvider Profile / /UserProvider ); }当项目规模增长以后Context 的问题会暴露出来所有消费同一个 Context 的组件在值变化时都会重新渲染很难做细粒度的性能优化。所以 Context 适合低频数据、小项目不建议用它管理频繁变化的大型全局状态。4.3 Zustand当前最被推荐的轻量方案Zustand 是目前增长趋势很明显的状态管理库。它用一个很简单的思路解决了 Context 的痛点创建一个外部 store组件通过 Hook 订阅自己关心的那部分状态。状态更新时只有订阅了对应数据的组件会重新渲染。// 文件路径src/store/cartStore.js import { create } from zustand; export const useCartStore create((set) ({ items: [], addItem: (item) set((state) ({ items: [...state.items, item], })), removeItem: (id) set((state) ({ items: state.items.filter((item) item.id ! id), })), }));// 文件路径src/components/CartButton.jsx import { useCartStore } from ../store/cartStore; export default function CartButton() { const items useCartStore((state) state.items); const addItem useCartStore((state) state.addItem); return ( button onClick{() addItem({ id: 1, name: React 实战课程 })} 添加商品当前 {items.length} 件 /button ); }Zustand 的优点是不需要 Provider 包裹、代码量少、TypeScript 支持好、函数式更新灵活。对于中小型项目Zustand 属于“开箱即用、心智负担低”的选择。4.4 Redux Toolkit大型项目的官方推荐写法Redux 曾经是 React 状态管理的代名词但早期版本的样板代码很多。现在的官方推荐写法是 Redux ToolkitRTK把 createStore、combineReducers、redux-thunk 全部统一成了简洁的 API。// 文件路径src/store/userSlice.js import { createSlice } from reduxjs/toolkit; const initialState { profile: null, loading: false, }; const userSlice createSlice({ name: user, initialState, reducers: { setProfile: (state, action) { state.profile action.payload; }, setLoading: (state, action) { state.loading action.payload; }, }, }); export const { setProfile, setLoading } userSlice.actions; export default userSlice.reducer;// 文件路径src/store/index.js import { configureStore } from reduxjs/toolkit; import userReducer from ./userSlice; export const store configureStore({ reducer: { user: userReducer, }, });// 文件路径src/main.jsx import React from react; import ReactDOM from react-dom/client; import { Provider } from react-redux; import { store } from ./store; import App from ./App; ReactDOM.createRoot(document.getElementById(root)).render( Provider store{store} App / /Provider );RTK 配套的 RTK Query 还能直接处理数据请求和缓存适合作为团队统一状态管理方案。缺点是对新手的理解门槛偏高Action、Reducer、Selector 的概念需要一段时间消化。4.5 Jotai原子化状态Jotai 的思想是“原子状态”把状态拆成最小单元组件按需组合。它比 Zustand 更强调原子性适合状态复用复杂、派生状态多的场景。不过在实际项目里Zustand 的接受度一般高于 Jotai这更多是习惯和社区选择的问题。状态管理的选择结论项目很小、全局状态少 → Context中大型项目、个人开发或小团队 → Zustand大型项目、老团队、需要严格规范 → Redux Toolkit状态碎片化、派生逻辑复杂 → Jotai5. 服务端状态与数据请求TanStack Query 与 SWR这是 React 生态里最值得重视的一块也最容易被新手忽略。大多数项目的主要状态其实来自后端接口如果这些数据全部用全局状态管理去存会陷入缓存失效、重复请求、加载状态混乱的困境。5.1 TanStack QueryReact QueryTanStack Query 的核心价值是把服务端数据变成可缓存的资源。你只需要声明这个数据怎么获取它就会自动管理缓存、加载中、错误、更新、重新请求等一整套生命周期。// 文件路径src/api/useUsers.js import { useQuery } from tanstack/react-query; async function fetchUsers() { const res await fetch(/api/users); if (!res.ok) { throw new Error(请求失败); } return res.json(); } export function useUsers() { return useQuery({ queryKey: [users], queryFn: fetchUsers, }); }// 文件路径src/components/UserList.jsx import { useUsers } from ../api/useUsers; export default function UserList() { const { data, isLoading, isError } useUsers(); if (isLoading) { return div加载中.../div; } if (isError) { return div加载失败请稍后重试/div; } return ( ul {data.map((user) ( li key{user.id}{user.name}/li ))} /ul ); }TanStack Query 还会自动处理窗口重新聚焦时的数据刷新、分页和无限滚动查询、乐观更新等高级场景。它大幅减少了手写useEffectsetState的样板代码。5.2 SWRSWR 是 Vercel 团队推出的数据请求库名字来自 HTTP 缓存策略的 stale-while-revalidate。用起来和 TanStack Query 很相似但 API 更轻import useSWR from swr; const fetcher (url) fetch(url).then((res) res.json()); export default function Profile() { const { data, error, mutate } useSWR(/api/profile, fetcher); if (error) return div加载失败/div; if (!data) return div加载中.../div; return ( div p{data.name}/p button onClick{() mutate({ ...data, name: New Name })} 更新名称 /button /div ); }TanStack Query 和 SWR 二选一即可。从功能完整度和生态来说TanStack Query 更占优势如果项目里已经大量使用 Vercel 系工具SWR 是更顺手的补充。6. 表单方案React Hook Form 与 Formik表单在前端项目中的占比非常高同时也是代码量容易被低估的部分。校验规则、错误提示、脏状态、提交状态、性能每一项都需要处理。6.1 React Hook Form当前 React 表单方案的主流选择是 React Hook Form。它的核心优势在于利用非受控组件 ref 减少不必要的渲染再配合校验库 zod 做类型安全的校验。// 文件路径src/components/LoginForm.jsx import { useForm } from react-hook-form; import { z } from zod; import { zodResolver } from hookform/resolvers/zod; const schema z.object({ email: z.string().email(请输入正确的邮箱), password: z.string().min(6, 密码至少 6 位), }); export default function LoginForm() { const { register, handleSubmit, formState: { errors }, } useForm({ resolver: zodResolver(schema), }); const onSubmit (data) { console.log(提交数据, data); }; return ( form onSubmit{handleSubmit(onSubmit)} div input typeemail placeholder邮箱 {...register(email)} / {errors.email span{errors.email.message}/span} /div div input typepassword placeholder密码 {...register(password)} / {errors.password span{errors.password.message}/span} /div button typesubmit登录/button /form ); }React Hook Form 在处理大型表单、动态表单项方面表现很好社区解决方案也比较成熟。6.2 FormikFormik 曾经是 React 表单的主流方案但它的受控模式在多字段表单里渲染成本偏高目前新项目中使用 React Hook Form 的占比明显更高。如果维护的是老项目Formik 的代码仍然值得会读、会改。7. 样式方案与 UI 组件库样式方案是 React 技术栈中最因人而异的部分因为团队偏好差异很大。7.1 CSS ModulesCSS Modules 是当前最稳妥、心智负担最低的样式方案之一。它通过构建工具自动把 class 名变成带哈希的唯一值避免全局污染。/* 文件路径src/components/Button.module.css */ .btn { padding: 8px 16px; border-radius: 4px; background: #1677ff; color: #fff; border: none; cursor: pointer; }// 文件路径src/components/Button.jsx import styles from ./Button.module.css; export default function Button({ children }) { return button className{styles.btn}{children}/button; }CSS Modules 适合工程团队样式写在普通 CSS 文件里没有额外运行时成本也没有复杂的学习曲线。7.2 Tailwind CSSTailwind CSS 是当前热度很高的原子化 CSS 方案。它提供大量工具类直接在 JSX 里组合export default function Button({ children }) { return ( button classNamerounded-md bg-blue-500 px-4 py-2 text-white hover:bg-blue-600 {children} /button ); }Tailwind 的优势是快速构建界面、样式一致性好、打包体积因为未使用样式的剔除而更小。缺点是 JSX 中 class 列表会很长团队需要适应一种“写样式像写属性”的节奏。7.3 主流 UI 组件库UI 组件库可以作为中后台项目的底座Ant Design国内中后台项目的事实标准组件全面文档和社区资料丰富。Material UI谷歌 Material Design 规范的 React 实现国际化程度高。shadcn/ui基于 TailwindCSS Radix UI 的组件集合不依赖 npm 包而是将组件源码直接复制进项目适合需要完全掌控样式的团队。选型思路如果团队开发速度优先、需要开箱即用的中后台页面选择 Ant Design 很稳如果是产品型前端项目、对设计规范要求高shadcn/ui 或 Material UI 都值得考虑。8. 配套工具测试、动画与虚拟列表除了核心选型一个完整的 React 工程还会用到以下几类配套库。8.1 测试React 项目的官方推荐测试组合是 Vitest/Jest React Testing Library Testing Library 的 jest-dom 匹配器。// 文件路径src/components/Counter.test.jsx import { render, screen, fireEvent } from testing-library/react; import { describe, it, expect } from vitest; import Counter from ./Counter; describe(Counter 组件, () { it(点击按钮后计数增加, () { render(Counter /); const button screen.getByRole(button, { name: 增加 }); fireEvent.click(button); expect(screen.getByText(计数1)).toBeInTheDocument(); }); });React Testing Library 的理念是站在用户角度测试尽量避免直接测试组件内部实现。这种做法让测试更接近真实行为重构时不需要频繁改测试。8.2 动画React 生态里比较常用的动画库是 Framer Motion。它提供了声明式的动画组件支持页面切换、元素进入离开、手势交互动画API 设计贴合 React 开发习惯。import { motion } from framer-motion; export default function Card() { return ( motion.div initial{{ opacity: 0, y: 20 }} animate{{ opacity: 1, y: 0 }} transition{{ duration: 0.5 }} 内容卡片 /motion.div ); }对需要复杂动画效果的产品项目Framer Motion 基本是首选。8.3 虚拟列表当页面需要渲染大量数据比如日志列表、用户表格、聊天记录时直接渲染全部 DOM 会导致页面卡顿。虚拟列表组件会只渲染可视区域内的元素滚动时动态替换。常见的方案有tanstack/react-virtual和react-window。TanStack Virtual 和 TanStack Query 同属一个生态API 风格统一适合已经在使用 TanStack 系列的项目。import { useVirtualizer } from tanstack/react-virtual; import { useRef } from react; export default function VirtualList({ items }) { const parentRef useRef(null); const virtualizer useVirtualizer({ count: items.length, getScrollElement: () parentRef.current, estimateSize: () 40, }); return ( div ref{parentRef} style{{ height: 400px, overflow: auto }} div style{{ height: ${virtualizer.getTotalSize()}px, position: relative, }} {virtualizer.getVirtualItems().map((virtualItem) ( div key{virtualItem.key} style{{ position: absolute, top: 0, left: 0, width: 100%, height: ${virtualItem.size}px, transform: translateY(${virtualItem.start}px), }} {items[virtualItem.index]} /div ))} /div /div ); }9. 一套可落地的 React 技术栈推荐上面讲了很多选型这里给三套组合方案对应不同场景。9.1 中后台管理系统中后台最关键的是开发效率和一致性适合使用相对完整、资料多的方案框架Vite React TypeScript路由React Router样式CSS Modules Ant Design客户端状态Zustand服务端状态TanStack Query表单React Hook Form zod数据请求fetch/axios 封装这套组合的优势是各层职责清晰Ant Design 负责控件React Hook Form 负责表单逻辑TanStack Query 负责接口数据Zustand 只处理少量全局 UI 状态。9.2 面向 C 端的 Web 应用这类场景往往需要首屏速度和 SEO框架Next.js样式TailwindCSS按情况接入 shadcn/ui服务端状态TanStack Query 或 SWR客户端状态Context 足够则不引入额外库需要再上 Zustand动画Framer Motion为什么首选 Next.js因为 C 端产品对首屏要求高Next.js 的 SSR 和图片优化开箱即用Tailwind 适合快速迭代界面如果项目是 Next.js 全栈应用还能用 Server Actions 简化数据变更逻辑。9.3 个人项目或快速原型个人项目最怕被工具细节拖住少即是多框架Vite React路由先用 React Router状态Context React 内置能力不引入重量级状态库样式TailwindCSS数据直接写 axios 或 fetch量大了再升级 TanStack Query先跑通核心功能等痛点出现再补工具。比起一开始就把所有库装齐更重要的是保持技术栈的可替换性。10. 常见问题与选型排坑清单问题现象可能原因排查方式解决方案状态一直不同步把接口响应数据直接用 useState 管理缓存和更新逻辑混乱检查数据更新时是否有组件未重新渲染接口返回后是否有手动 setState 链将服务端数据交给 TanStack Query 或 SWR 管理Context 改动导致大量组件重新渲染Context Value 每次 render 都是新引用所有消费方全部刷新使用 React DevTools 分析 Highlighter 更新范围拆 Context、使用 Zustand 或 Jotai 做细粒度订阅Redux 样板代码太多使用了旧版 Redux 写法反复手写 action type 和 switch case检查 store 目录代码量改用 Redux Toolkit createSliceJSX 中 className 过长可读性差Tailwind 原子类全部堆在 JSX 里查看组件行数是否超出屏幕抽取公共类名、使用 clsx 或 tailwind-merge 组合表单大量输入框导致输入卡顿使用了受控组件且每次输入都触发大范围重新渲染在表单组件里打印 render 次数改用 React Hook Form 非受控模式SSR 项目接口请求混乱useEffect 内发起请求但服务端首屏拿不到数据确认使用框架的数据获取方式是否依赖 useEffectNext.js 中使用 Server Component 或 RSC 内直接请求11. 给开发者的三条实战建议第一选型标准不是“哪个库最流行”而是“这个库解决的是哪一层问题、团队能否驾驭”。把路由、状态、数据、表单、样式这五层分开思考就能避免 A 库和 B 库功能重叠导致的心智混乱。第二警惕不必要的全局状态。很多新手的惯性是只要多个组件要共享一个值就立刻引入全局状态库。其实 90% 的共享数据都可以通过组件树传参、Context、或服务端状态库解决。全局状态库应该是最后考虑的方案而不是第一反应。第三保持技术栈可替换。不要在代码里写死对某个库的依赖比如组件内部直接调用useStore而不是通过自定义 Hook 包一层。当你把数据访问都收敛到自定义 Hooks 后面未来从 Zudtand 换到 Redux Toolkit只需要改 Hook 内部实现业务组件完全不动。这种设计弹性比选到“完美库”更可靠。对 React 学习者来说强烈建议自己动手搭两遍全套项目。第一遍使用中后台推荐组合跑通一个带接口请求、表单校验、路由跳转、状态管理的完整后台页面第二遍使用 Next.js 搭一个内容型页面体会 SSR 和数据获取的区别。两遍做完以后React 生态在你眼里就不再是碎片化的“库”而是一条有主线的技术栈地图。