React这个库有个很有意思的特点：它自己只解决"视图怎么渲染"这一件事，剩下的路由、状态、请求、样式、构建、跨端、可视化，几乎全靠外部生态来补。所以你去看任何一个真实项目，React的代码大概只占三分之一，剩下的全是各种"扩展"。这也是为什么面试里问React，问到最后往往变成问生态选型、问工程化配置、问性能排查。这篇东西我打算把React扩展这个话题从头理一遍，不讲空泛的概念，而是按"为什么要扩展、扩展在哪一层、每一层怎么选、选完怎么落地、落地之后会踩什么坑"这条线走。不管你是刚学完基础语法想找个方向练手，还是已经写过几个项目但对生态选型心里没底，或者正在准备面试想把这些零散知识点串成体系，应该都能从里面捞到点东西。内容会覆盖工程配置、状态管理、跨端渲染、可视化适配、以及最近很热的React Agent方向，中间会插不少我实际踩过的坑和能直接抄的配置。
1. React扩展的底层逻辑：为什么一个库要养活一个生态
1.1 只做视图层，是克制也是代价
React的定位从第一天起就很明确：它是一个用于构建用户界面的库，注意是"库"不是"框架"。框架的特点是给你一整套约定，路由、数据流、目录结构都帮你定好，你按它的规矩写就行；库的特点是只解决一个问题，其余的你自己拼。React选了后者，官方文档里那句"Just the UI"就是这个意思。
这种克制带来了两个结果。好处是灵活，你可以用它写一个按钮，也可以用它撑起一个几十万行的后台系统，中间的工具链完全由你决定。代价是决策成本高——每个项目开始前你都要做一轮选型，路由用哪个、状态放哪、样式怎么写、构建用什么，这些在框架里是默认答案，在React里全是开放题。
我在早期项目里就吃过这个亏。当时团队从零起项目，光是"用不用TypeScript""状态管理选Redux还是自己写Context"这两个问题就讨论了两天，最后拍脑袋定了，写到中期发现Context嵌套太深、性能有问题，又回头重构。所以理解React扩展的第一课不是学某个库怎么用，而是理解"哪些东西需要扩展、扩展的收益和成本各是什么"。
从工程角度，React需要扩展的部分大致可以归到四条主线上，我把它整理成下面这张表，后面几个章节基本就是按这四条线展开的。
| 扩展主线 | 解决的问题 | 典型方案 | 引入成本 |
|---|---|---|---|
| 语法与开发体验 | 写起来更顺、错误更少 | TypeScript、ESLint、编辑器插件 | 低，但配置琐碎 |
| 状态与数据流 | 跨组件共享状态、缓存、异步 | Zustand、Redux Toolkit、React Query | 中，选错影响大 |
| 构建与工程化 | 打包、热更新、SSR、路由约定 | Vite、Next.js | 中高，迁移成本大 |
| 渲染目标与表现层 | 跨端、图表、大屏、富文本 | React Native、图表库、vw/vh方案 | 高，涉及架构 |
1.2 扩展不是越多越好，判断标准是什么
很多人新手期有个惯性，看到什么库火就往项目里塞，最后依赖树长得离谱，构建慢、升级难、出问题定位不到源头。我后来总结了一个很朴素的判断标准：这个扩展解决的是"我当下真实遇到的问题"还是"我担心未来可能遇到的问题"。
前者放心加，后者先放着。举个例子，项目初期只有三四个页面，组件层级不深，那就没必要上Redux，一个Context加useReducer完全够用，甚至直接用useState往上提一层都行。等到状态确实开始跨三四层传递、出现明显的数据同步问题时，再引入专门的状态库，这时候你是有明确痛点的，选型也更有的放矢。
另一个判断维度是"这个扩展能不能被替换"。像TypeScript、ESLint这类，替换成本相对可控，早点上收益明显；而构建工具、跨端方案这种一旦铺开就很难换的，反而要多花时间评估。这个"可逆性"的思路在后面讲Vite和Next.js选型时还会再提。
提示：选型的犹豫期不要超过两天。大部分扩展方案的差距没有想象中那么大，真正决定项目成败的是代码组织和业务理解，而不是用了哪个状态库。拖太久反而错过开发节奏。
1.3 一个常见误区：把扩展当核心
我见过一些简历，项目描述里写满了"使用Zustand + Vite + TypeScript + Tailwind + React Query"，但问到"为什么这么选""遇到过什么问题"，答不上来。这就是把扩充当成了核心，以为堆得越多越厉害。
真实情况是，面试官更在意你对React本身的理解，比如组件的渲染机制、状态更新的批量处理、闭包导致的陈旧值问题、key的正确使用、memo和useMemo的区别与适用场景。这些是地基，扩展是房子。地基不稳，房子堆再高也是危房。所以这一章的结论很简单：先把React核心吃透，再按需扩展，每加一个依赖都能说出理由。
2. 编辑器与工程化扩展：从VSCode插件到构建工具选型
2.1 让VSCode真正"懂"React：插件与配置实操
写React如果编辑器没配置好，体验会差一大截。最常见的一个问题就是标签不会自动闭合——你打一个<div，回车之后只得到<div>，或者干脆没反应。这个问题在VSCode里靠原生设置其实能解决一大半，不用装一堆插件。
先看原生设置。打开settings.json，加上这两条：
{ "emmet.includeLanguages": { "javascript": "javascriptreact", "typescript": "typescriptreact" }, "editor.linkedEditing": true }第一条让Emmet在.js和.ts文件里也生效，这样你输入div.container按Tab就能展开成带类名的完整标签。第二条开启"链接编辑"，改开标签时自动改闭标签，省掉一半的改名工作量。
插件层面，我长期只留三个。ESLint负责代码规范校验，Prettier负责格式化，还有一个是错误高亮插件，能在编辑器里直接标出JSX里的语法问题。VSCode从1.60版本之后内置了对JSX和TSX的语法支持，自动闭合标签是自带的，所以网上那些"必须装某某闭合插件"的说法其实有点过时了——如果你发现闭合失效，先检查文件语言模式是不是被识别成了普通JavaScript，右下角点一下改成JavaScript React即可。
注意：Prettier和ESLint的规则如果都开启格式化，会互相打架。建议用ESLint管代码质量（未使用变量、缺少依赖等），把格式化交给Prettier，并在ESLint配置里关掉所有和格式相关的规则，或者直接引入
eslint-config-prettier。这个坑我至少踩过三次，表现为保存时格式反复横跳。
2.2 Vite + React 还是 Next.js：先回答三个问题
这是近两年被问得最多的一组选型。我自己的判断从来不看哪个更火，而是先回答三个问题。
第一个问题：这个项目需要被搜索引擎抓到内容吗，或者需要更好的首屏加载体验吗？如果需要，Next.js这类支持服务端渲染的方案更合适，因为页面在服务端就渲染好了HTML，爬虫和用户都能更快看到内容。如果是后台管理系统、内部工具这类登录后才能用的页面，搜索引擎根本进不来，那服务端渲染的价值就很有限。
第二个问题：团队里有没有人能搞定服务端环境？Next.js不只是前端框架，它带了一套服务端能力，部署时可能涉及Node服务、环境变量、缓存策略。如果团队都是纯前端背景，运维也没人配合，强行上服务端渲染，最后大概率是"用了但没用好"，反而增加故障面。
第三个问题：这个项目会长期演进成大应用，还是一个快速验证的小工具？小工具、Demo、内部脚本，Vite起步快、心智负担小，很合适。要长期演进、需要约定式路由、图片优化、API路由这些开箱能力的，Next.js更省心。
我把它整理成一个更直观的对照：
| 维度 | Vite + React | Next.js |
|---|---|---|
| 渲染方式 | 客户端渲染为主 | SSR/SSG/CSR 多模式 |
| 启动速度 | 极快，冷启动几乎无感 | 相对慢，尤其首次构建 |
| 路由 | 自己选 React Router | 文件系统约定路由 |
| 部署复杂度 | 静态托管即可 | 需要 Node 运行时或平台支持 |
| 适合场景 | 后台、内部工具、SPA | 内容站、电商、需要 SEO 的产品 |
| 学习曲线 | 平缓，就是标准React | 需要理解服务端概念 |
有个容易被忽略的点：这两者不是互斥的，也不能简单说谁替代谁。Next.js内部同样可以用React的一切能力，而Vite构建的SPA也能通过在构建期预渲染来改善首屏。选型时别被"谁更先进"的说法带偏，回到项目需求本身。
2.3 一份可直接抄的工程扩展配置
说再多不如给配置。下面是一个Vite + React + TypeScript项目的vite.config.ts，我一般会加上路径别名和代理，开发时会舒服很多：
import { defineConfig } from 'vite'; import react from '@vitejs/plugin-react'; import path from 'path'; export default defineConfig({ plugins: [react()], resolve: { alias: { '@': path.resolve(__dirname, 'src') } }, server: { port: 5173, proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true } } }, build: { rollupOptions: { output: { manualChunks: { vendor: ['react', 'react-dom'], charts: ['echarts'] } } } } });这里有三处值得说。路径别名@解决的是相对路径层层往上找的问题，../../components这种写多了容易错，改成@/components直观得多。代理解决的是开发环境跨域，前端跑在5173，后端跑在3000，通过代理把/api请求转发过去，浏览器看到的是同源请求，就不会被拦截。manualChunks是打包优化，把React本体和体积大的图表库拆成独立文件，利用浏览器缓存——只要这些库版本没变，用户第二次访问就不需要重新下载。
这三条配置我几乎每个项目都加，属于低成本高收益的典型。要注意代理只在开发环境生效，生产环境得靠服务端配置或网关处理，别以为配了代理线上就万事大吉了。
3. 状态层扩展：Zustand 与 Redux 到底怎么选
3.1 从Redux迁到Zustand，改的到底是什么
Redux曾经是React状态管理的事实标准，那本《深入浅出React和Redux》也是很多人的入门书。它的核心理念——单向数据流、单一数据源、状态只读、用纯函数修改——到今天依然是对的。问题出在"样板代码"上：一个简单的计数器，你要定义action type、写action creator、写reducer、配置store、再用connect或useSelector连组件，五六个文件才跑起来一个功能。
Zustand把这些压缩成了一段代码：
import { create } from 'zustand'; const useCounterStore = create((set) => ({ count: 0, increment: () => set((state) => ({ count: state.count + 1 })), decrement: () => set((state) => ({ count: state.count - 1 })), reset: () => set({ count: 0 }) })); // 组件里直接用 function Counter() { const { count, increment } = useCounterStore(); return <button onClick={increment}>{count}</button>; }它没有Provider包裹，没有dispatch，没有action type，组件订阅的是store，状态一改，用到的那部分自动重渲染。迁移的时候你会发现，真正要改的是思维习惯——从"派发动作、reducer处理"变成"直接调方法改状态"。
但我要说句公道话，Redux不是被淘汰了，是被用错了地方。大型团队协作、状态变更需要严格可追溯、要接时间旅行调试、要和某些既有中间件生态配合的场景，Redux Toolkit依然是稳妥选择，它之后也大幅简化了样板代码。选Zustand更多是因为中小项目里它的心智负担和代码量明显更低。
3.2 什么状态该进store，什么该留在组件里
这是我踩过的最大一个坑。早期用状态库，习惯性地把所有状态都往store里塞，结果store变得巨大，改一个字段牵连一堆组件重渲染，调试起来像解乱麻。
后来我定了个简单的分界线，分三类看：
第一类，只有当前组件自己用的，比如一个弹窗的开合、一个输入框的临时值，这类直接useState，别进store。放进store只会增加耦合。
第二类，父子之间传一两层的，用props传下去就行，加个TypeScript类型还更清晰。为了省一次传参就上全局状态，是过度设计。
第三类，真正跨模块共享、或者多个不相邻组件都要读写的，比如登录用户信息、全局主题、购物车，这类才进store。
按这个分法，很多项目的store其实会瘦一半以上。状态库不是越多越好用，放对地方才有价值。
3.3 状态扩展里最容易翻车的三个细节
第一个是选择器粒度。用Zustand时如果写成const state = useStore()，等于订阅了整个store，任何一个字段变化都会让组件重渲染。正确做法是只取需要的那部分：const count = useStore((s) => s.count)。这个小改动在中大型列表页里性能差异很明显。
第二个是引用类型导致的无效更新。如果你的选择器返回一个新对象或新数组，比如useStore((s) => ({ a: s.a, b: s.b }))，每次渲染返回的都是新引用，配合某些比较策略就会触发无限重渲染。解决办法是用浅比较，Zustand提供了shallow中间件，或者干脆拆成两个独立的选择器。
第三个是异步状态的边界处理。请求失败、组件卸载后回调仍在执行、竞态导致旧请求覆盖新数据，这些都要在store里考虑。我的做法是把请求相关的状态单独抽出来，配上加载中、错误、重试三个状态位，别把所有异步逻辑都糊在一个大store里。
4. 渲染目标扩展：React Native 启动白屏怎么系统排查
4.1 白屏的四个来源，按概率排序
React Native启动白屏是个高频问题，我从实际排查经验出发，把它归成四类，按发生率从高到低排。
第一类是打包资源没加载上。开发环境靠Metro服务提供JS包，如果服务没启动、端口被占、或者设备连不上网络，JS包加载失败就是白屏。这类问题的特征是：白屏前可能有一瞬间的加载画面，然后卡住。排查方法是先看Metro窗口有没有报错，再确认设备或模拟器的网络能访问到开发机。
第二类是原生模块初始化抛异常。某个第三方库的原生部分没链接好，或者Android/iOS配置里漏了权限、漏了Provider配置，初始化阶段就崩了，这时JS还没跑起来，自然白屏。特征是没有明显报错，或者报错出现在原生日志里而不是JS控制台。要看原生侧的日志，Android用adb logcat，iOS用Xcode的日志面板。
第三类是JS侧首屏组件渲染报错但没被捕获。比如首屏组件里读了一个未定义对象的属性，抛错了，如果没有错误边界，整个界面就是白的。这类要靠控制台里的红色报错定位。
第四类是主线程被同步任务阻塞。启动时做了大量同步计算，比如一次性解析大JSON、同步读大量数据，界面迟迟渲染不出来。特征是CPU占用高、白屏时间随数据量增长。
4.2 启动链路的优化实操
搞清楚原因之后，优化思路就清晰了。我一般按这个顺序处理。
首先是减少启动时的同步工作。把不急着用的初始化往后挪，比如用户信息的拉取、埋点上报，放到首屏渲染完成后异步执行。启动阶段只保留最必要的逻辑。
其次是启用Hermes引擎。新版React Native默认就是它，它把JS提前编译成字节码，省掉启动时的解析时间，对启动速度帮助比较直接。如果项目还停留在旧版本，值得评估升级。
第三是控制包体积。启动时要加载的JS越多，耗时越长。检查有没有把整个组件库、整个工具库全量引入，改成按需引入；检查有没有把只在某个页面用到的重型库放进了入口依赖。
第四是做启动阶段的日志埋点。在应用启动、JS引擎就绪、首屏组件挂载这几个关键节点打时间戳，输出耗时。这么做的好处是优化有数据支撑，不会凭感觉瞎调。
提示：白屏问题最忌讳的是"先改一堆东西看有没有好"。正确顺序是先确定是原生层还是JS层，再确定是加载失败还是渲染失败，一步步缩小范围。乱改会让问题更难复现。
4.3 Web端和Native端的差异，别想当然迁移经验
很多人从Web转React Native，最容易犯的错是把Web经验直接搬过来。两边差异其实不小。
样式上，Native不支持CSS，用的是类似Flexbox的样式对象，而且默认就是纵向排列，和Web的默认横向不一样。单位也不一样，Web可以用px、rem、vw，Native里是密度无关像素，写死数值在不同屏幕上表现不同。
布局上，Native没有DOM树，没有div和span，用的是View和Text，而且文字必须包在Text里，不能像Web那样随便放。
调试上，Native的错误可能来自三个层次：JS层、原生桥接层、平台原生代码。定位问题时要在多个日志源之间来回看，比Web的浏览器控制台麻烦得多。
理解这些差异，才不会在排查白屏时只盯着JS控制台，而忽略了原生侧的问题。
5. 表现层扩展：图表、大屏适配与富文本集成
5.1 图表库怎么选，看三个指标
React生态里的图表方案很多，我按"是否需要高度定制、数据量多大、要不要动效"这三个指标来选。
如果需要快速出图、标准图表类型齐全、不想写复杂配置，用偏声明式的库，配置项清晰，上手快。如果图表类型很特殊，或者要做高度定制化的交互，用基于Canvas或SVG的底层库，自由度高但代码量大。如果数据量上万条、还要流畅缩放拖拽，那得选支持WebGL渲染的方案。
下面这张表是我常用的几个方向的对照，具体库名按你项目实际评估：
| 指标 | 声明式方案 | 底层定制方案 | 大数据量方案 |
|---|---|---|---|
| 上手成本 | 低 | 高 | 中 |
| 定制能力 | 中 | 高 | 中 |
| 大数据表现 | 一般 | 一般 | 好 |
| 适用场景 | 后台报表 | 特殊可视化 | 实时监控 |
有个实际经验是，图表库的体积往往不小，一定要按需引入。很多库支持只引入用到的图表类型和组件，能把打包体积砍掉一大半。这个优化在大屏项目里尤其值得做。
5.2 大屏vw/vh适配，一套能落地的方案
大屏项目最头疼的是不同分辨率的适配。常见方案有两种，一种是vw/vh，一种是rem配合动态根字号。我这两年在几个大屏项目里更偏向vw/vh，理由是它和设计稿的对应关系最直接。
思路是这样的：设计稿一般给一个基准分辨率，比如1920×1080。把设计稿上的像素值换算成vw，公式是vw值 = 设计稿像素 / 1920 * 100。比如设计稿上一个元素宽200px，换算后就是200 / 1920 * 100 ≈ 10.42vw。
手算太麻烦，我用一个PostCSS插件自动转换，配置大概是这样：
// postcss.config.js module.exports = { plugins: { 'postcss-px-to-viewport': { viewportWidth: 1920, viewportHeight: 1080, unitPrecision: 5, viewportUnit: 'vw', selectorBlackList: ['.ignore'], minPixelValue: 1, mediaQuery: false } } };这样你在代码里照常写px，构建时会自动转成vw，开发体验和普通项目没区别。
但要注意两个坑。第一，不是所有尺寸都适合转vw，字体大小如果也转，在超宽屏上会变得巨大，所以要加白名单或黑名单控制。第二，vw方案在极端宽高比（比如超宽拼接屏）上会导致元素被拉扁，这时得配合最大最小宽高限制，或者用JS动态计算根字号，做更精细的控制。
5.3 把富文本编辑器接进React项目
有些项目需要在React里集成富文本能力，比如做一个Markdown编辑器。以StackEdit这类编辑器为例，它本身是一个功能完整的编辑工具，要在React里用它，思路通常是把它作为一个独立模块嵌入，而不是重写。
集成方式大致分两种。一种是iframe嵌入，把编辑器部署成一个独立页面，React里用iframe引用。好处是隔离彻底，样式和全局变量互不干扰；缺点是父子通信要走postMessage，稍微绕一点。另一种是把它编译成可以引入的模块，直接在组件里实例化，好处是通信直接，缺点是可能引入一堆全局样式，和现有项目冲突。
我个人在正式项目里更倾向第一种。理由很简单：富文本编辑器的样式体系往往很"霸道"，直接引入很容易把项目里已有的组件样式搞乱，排查成本很高。iframe虽然通信麻烦点，但边界清晰，出问题也好定位。
如果只是需要Markdown的渲染能力而不是编辑能力，那更简单，直接用一个Markdown解析库把文本转成HTML就行，不需要引入完整编辑器。这个判断要先做，别为了一个渲染需求引入一整个编辑器。
顺带说一句，最近有个叫React Agent的方向挺热。它指的是把React组件和AI能力结合起来——组件不只是渲染界面，还能在运行时根据用户输入做出决策、调用工具、更新界面。这里面涉及模型输出的结构化解析、工具的注册与调用、以及组件状态的协同更新。目前在原型阶段比较常见，落地还需要解决稳定性、成本和可观测性问题。
6. 面试视角：那些高频问题背后的考察逻辑
6.1 高频题不是让你背，是看你有没有真写过
整理面试题的时候我发现，题目本身来来去去就那些，但回答的深度差距很大。举几个典型。
"介绍一下React的生命周期"，很多人背的是类组件的挂载、更新、卸载三个阶段加一堆钩子。但如果你只是背，面试官追问一句"函数组件里怎么对应这些阶段"就露馅了。真正写过项目的人会告诉你，函数组件用useEffect加依赖数组来模拟不同阶段，依赖为空数组对应挂载，写具体依赖对应更新，返回清理函数对应卸载，然后顺带说清楚useEffect的执行时机是在浏览器绘制之后。
"useMemo和useCallback有什么区别"也是类似。标准答案一个是缓存值、一个是缓存函数，但面试官更想听的是"什么时候不该用"。我会说，这两个钩子本身也有开销，如果计算很轻或者依赖频繁变化，加了反而更慢。真正值得用的是把重计算结果缓存，或者把传给子组件的函数稳定住以配合memo。
"key的作用"看起来简单，但能说清楚"为什么用数组下标当key会有问题"的人不多。核心在于React用key来判断元素是否需要复用，下标会随着列表增删而错位，导致状态错乱——比如删掉第一项后，第二项的输入框内容跑到了第一项的位置。
6.2 一张表看清考察维度
我把常见面试题按考察维度归了一下类，方便对照复习：
| 考察维度 | 典型问题 | 真正想看的 |
|---|---|---|
| 渲染机制 | 虚拟DOM、diff、key | 你是否理解更新代价 |
| 状态与闭包 | useState陈旧值、依赖数组 | 是否踩过实际的坑 |
| 性能优化 | memo、懒加载、分片 | 是否有量化意识 |
| 生态选型 | 状态库、构建工具对比 | 是否能说出取舍理由 |
| 工程化 | 配置、规范、调试 | 是否独立带过项目 |
看这张表会发现，除了前两行偏原理，后面全是实践题。这也解释了为什么"面经"看多了用处有限——别人的经历没法直接套到你的项目上，面试官稍微换个场景你就答不上来。更有效的做法是把自己项目里的关键决策复盘一遍，想清楚每个选择的理由和代价。
6.3 一条更高效的学习路径
常有人问学React该看什么书、跟什么教程。我的建议是分三步走。
第一步，把官方文档的核心概念过一遍，重点是状态提升、受控与非受控组件、组合与继承这几节，它们决定了你后面写代码的方式。这一步不要跳，跳了后面全是坑。
第二步，动手写一个完整的小项目，必须有真实的数据流和交互，比如一个带增删改查的待办应用，或者一个带筛选排序的数据表格。写的过程中刻意用上useEffect、useMemo、自定义Hook，把概念变成肌肉记忆。
第三步，读一个高质量开源项目的源码，看看真实项目怎么组织目录、怎么封装Hook、怎么处理边界情况。这一步能帮你从"能写"跨到"写得好"。
至于那本经典的Redux书，我的建议是理解它的思想比记API重要。单向数据流、状态不可变、纯函数更新这些理念，你在用Zustand甚至用useReducer的时候同样受益。工具会换，思想会留下来。
7. 常见问题速查与排查技巧实录
7.1 问题速查表
把前面几章提到的典型问题整理成一张表，方便快速定位：
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 编辑器标签不闭合 | 语言模式识别错误 | 右下角切到JSX/TSX模式 |
| 保存时格式反复横跳 | Prettier与ESLint规则冲突 | 关闭ESLint格式化规则 |
| 组件无故重渲染 | 选择器粒度太粗 | 拆细选择器或浅比较 |
| 状态更新但不刷新 | 直接改了对象属性 | 用不可变方式返回新对象 |
| RN启动白屏 | 包未加载/原生初始化失败 | 分原生层和JS层排查 |
| 大屏元素被拉伸 | 极端宽高比下vw失真 | 加最大最小宽高限制 |
| 打包体积过大 | 全量引入重型库 | 按需引入并手动分包 |
| 首屏加载慢 | 同步任务阻塞 | 延后非关键初始化 |
7.2 几条用血换来的避坑经验
第一，不要在项目初期追求"技术栈完整性"。我见过太多项目一开始就把状态库、请求库、UI库、图表库全配齐，结果开发一个月后发现有一半根本没用上，还拖慢了构建。按需引入，缺什么补什么，这个节奏最舒服。
第二，任何扩展上线前都要确认"出问题我能定位"。比如引入一个状态库，先想清楚怎么调试它——有没有开发者工具、能不能打印状态变化、出错日志是否清晰。如果答案是"不清楚"，那就要慎重。可观测性比功能本身更重要。
第三，升级依赖要小步走，别攒着一起升。React版本、构建工具、TypeScript这几个如果同时跨大版本升级，出问题你根本分不清是谁引起的。我一般一次只升一个，跑通测试再升下一个。
第四，性能优化先测量再动手。React DevTools的性能面板能看出哪个组件渲染耗时最长，浏览器的网络面板能看出哪个资源最大。不看数据就凭感觉加memo、加缓存，大概率是在做无用功，甚至引入新bug。
第五，把"暂时没时间做"的技术债记下来。比如某个配置当时为了赶进度写了临时方案，一定要在文档或任务系统里留一笔，注明原因和后续计划。不然三个月后你看到那段代码，完全想不起来当初为什么这么写。
7.3 关于这套扩展体系的后续延伸
这套东西往下还有不少可挖的方向。状态层可以继续看请求缓存库怎么和store配合，构建层可以研究预渲染和边缘部署，渲染层可以深入跨端方案的差异，表现层可以做大屏的动效和实时数据推送。我打算后面按主题逐个展开，每个方向都配上能直接跑的示例。
最后分享一个我一直在用的习惯：每引入一个新扩展，就在项目里写一个简短的说明文件，写清楚它解决什么问题、为什么选它、替代方案是什么、遇到问题找谁。这个文件平时看着多余，但等新人接手或者半年后自己回头看，价值就体现出来了。技术选型这件事，理由比结论重要得多。
