接触React这么多年一个很深的感受是React的资料不是太少而是太多。网上随便一搜“react学习教程”能翻出几百个视频、几千篇文章、几十个仓库新手往往纠结的不是“找不到资料”而是“下载了10个G的资料包最后只看了第一章”。更麻烦的是React生态变化太快两年前的教程可能还在讲class组件你花一周学完结果现在的项目全是函数组件加Hooks等于白学。所以这篇React资料汇总我不打算再给你堆一堆链接而是把我自己这么多年筛选资料、带新人、准备面试、处理项目问题沉淀下来的东西整理成一份可直接照做的清单覆盖学习路线、面试准备、高频项目坑位、工程化选型这些方向顺便把最近大家在搜的几个问题——比如React Native启动白屏、VSCode里标签闭合、Zustand怎么用、大屏vw/vh适配、Next.js和ViteReact怎么选——一起讲清楚。1. 面对海量React资料我建议你先做一次“信息减负”很多人的学习卡点不在“不努力”而在“输入太杂”。今天刷到一篇“React 15个最佳实践”明天收藏一个“2024最新React教程”后天又看到一个“源码分析”信息源互相矛盾最后脑子里只剩一团浆糊。我自己的做法是先按资料类型分成几大类然后每一类只保留一个主来源其他全部当补充。1.1 常见资料类型与真实价值评估我把市面上的React资料粗略归成以下几类并附上我个人的价值评分资料类型典型代表适合阶段最大价值最大坑点官方文档react.dev、reactnative.dev任何阶段最权威跟随版本更新新手直接读会觉得抽象缺少项目语境入门教程视频各类“React从入门到实战”课程0-3个月新手能跟着敲代码建立直观感受版本老旧、为了点击量堆砌内容、只教用法不讲原理经典书籍《深入浅出React和Redux》、《React设计模式》有基础后成体系能深入原理基于老版本很多API已废弃源码分析类各类React源码精读文章6个月以上提升原理理解面试加分没有业务经验看这个纯粹浪费时间面经与面试题GitHub上的面经仓库、牛客、掘金等准备跳槽时快速摸清考点分布只背答案不理解被追问就露馅实战项目GitHub上的后台管理模板、仿项目有基础后练手接触真实工程结构很多项目代码质量差反而带坏习惯1.2 我现在的筛选标准经过大量试错我现在筛选资料只问三个问题它对应React的哪个版本如果还在讲class组件默认是一份历史资料可以用来理解演进但不要作为主学习路径。它讲的是“是什么”还是“为什么”只讲API用法的资料看过即忘能讲清楚为什么这样设计、什么场景下该用、什么时候不该用的资料才值得反复读。它我能复现吗教程里的代码我能跑通吗不能跑通的资料我一般直接放弃因为错误很可能在你自己的环境里最后浪费大量时间排错。提示我现在给新同学的建议永远是——问搜索引擎之前先去问官方文档。react.dev注意是.dev域名不是.com在2023年整体改版后对函数组件和Hooks的讲解已经比较友好了而且新增了大量互动示例这比两年前那版文档好了不止一个档次。2. 入门学习路线的实际排序官方文档、书、视频怎么配合使用很多初学者问我的第一个问题就是“要不要先看视频还是直接看文档”。我实话实说只看视频会形成“我懂了”的错觉实际写代码时连import都想不起来只看文档又容易因为太干燥而中途放弃。合理的做法是两者交叉。2.1 官方文档应当作为主线我建议把react.dev的“Learn React”部分当成主线。具体路径是先读“Describing the UI”和“Adding Interactivity”这两大块理解了JSX、组件、Props、State、渲染流程后再进入“Managing State”学习状态管理思路。这个顺序很关键因为React的难点从来不是语法而是“状态一变页面哪里会跟着变、为什么变”的心智模型。读文档的时候有一个技巧每读完一个章节不要急着往下走先合上页面自己默写一个小例子去验证。比如读完“useState”之后就自己写一个计数器读完“条件渲染”就自己写一个登录/登出切换的按钮。用这样的方式逼自己把“看懂”变成“会用”。2.2 经典书籍要不要看要看但带着版本意识热词里出现了《深入浅出React和Redux》的下载这本书确实是一代经典但你必须清楚它的定位。这本书成书年代比较早里面的Redux使用方式还是connect、mapStateToProps老一套和现在主流的Redux Toolkit写法差距很大。我的建议是这本书适合作为“理解React和Redux设计思想”的补充读物但不要照着里面的代码敲更不要以为现在的项目都那么写。如果你想要一本和现在版本契合的实体书我更推荐关注React官方团队或社区公认的书籍比如《React设计模式》这类偏原理的读物。不过我的个人看法是除非工作需要系统啃书否则文档自己动手源码文章已经足够应付绝大多数React开发任务。2.3 视频教程的取舍与项目的选择视频方面我不具体推荐某一门课但给你一个判断标准如果你的视频教程还在讲“组件生命周期三阶段”它大概率过时了至少它忽略了Hooks时代的心智模型。现在一门合格的React入门课至少要覆盖函数组件、useState、useEffect、useRef、自定义Hooks、性能优化三件套useMemo/useCallback/React.memo、路由React Router 6。学完基础后一定要动手写至少两个小项目。我自己的经验是第一个项目写待办列表什么都不许用纯useState实现体会状态驱动视图是什么感觉第二个项目用React Router做一个多页面小网站加一个全局状态可以用Zustand这个后面会讲体会工程上的状态拆分。不要一上来就复制后台管理模板那是陷阱——你会发现什么都看不懂最后根本跑不起来还以为是自己的问题。3. 面试题和面经真正要练的不是背答案搜索词里“react面试题”“react面经”“react面试题目”出现频率很高。每年都有无数人问我有没有“题库”我的回答是面试题当然要刷但刷法决定你是成为“背题机器”还是“能打的工程师”。3.1 React面试题到底在考什么根据我的观察React面试题表面上五花八门实际上就四类原理题虚拟DOM是什么diff算法怎么工作为什么key不能乱用index设计取舍题为什么要有Hooks类组件哪里不好useEffect依赖数组为什么要这么写场景题一个列表页频繁增删改怎么优化一个全局主题切换状态放在哪工程题怎么配置按需加载怎么做错误边界怎么选状态管理库你会发现除了第一类其他三类其实靠“背”是背不出来的。面试官随便换一个业务场景背过的答案就漏了。3.2 几个高频题型的思考框架虚拟DOM和diff算法。不要只回答“虚拟DOM就是JS对象diff就是对比新旧对象找出差异”。更重要的是说清楚为什么需要这一层直接操作真实DOM有什么问题diff算法在React里是如何把复杂度降下来的通常讲tree层级比较、同一层级比较、key的作用最后再补一句“diff并不免费频繁大列表更新依然可能卡顿这也是性能优化的出发点”。这样答才是一个有经验的开发者的水平。Hooks闭包陷阱。典型场景在useEffect里读state拿到的却是旧值。这个题的考点不是语法而是“你能不能理解闭包、依赖数组、每次渲染都是独立的”。我一般会反问一句“你写的函数组件每次状态更新本质上都会重新执行一次那我在这次执行里定义一个函数/一个effect它捕获的是哪一次的props和state”把这个想明白面试题里的死循环、旧值、异步取不到最新state的坑统统能理清。状态管理选型。现在这个时间点面试官很少再要求你必须用Redux更多是问“什么场景用Redux/Zustand/Context”我建议你的回答思路是先承认Context本身就可以做状态共享但它的问题是“只要value变所有消费它的组件都要重新渲染”且不适合高频更新场景Redux生态好、中间件丰富、时间旅行调试强大适合大型复杂应用Zustand轻量、无Provider包裹、可以在组件外部读写状态适合中小型项目和想少写样板代码的团队。这比单纯说“redux好”或“redux过时了”要立体得多。3.3 面经的正确用法面经不是用来“背”的它是用来“查漏”的。我的做法是准备面试的时候拿三五份面经把里面出现的题目全部过一遍但每一题只做一件事——问自己“如果面试官换一个业务场景问我同一个考点我能答出来吗”能就跳过不能就打开官方文档或写个demo验证直到能独立讲清楚为止。注意GitHub上那些几千星的面试大全我建议你用“检索引擎”的方式使用而不是从头读到尾。React面试题更新频率也很高2年前的“React 18新特性”题现在是基础题“并发特性”“Transition”这类才是新宠所以看面经也要挑新的看别抱着旧题集啃。4. React Native启动白屏从现象到根因的排查链路接着聊一个非常具体的坑React Native启动白屏。这个关键词搜得特别多说明中招的人不少。RN项目启动后会有一段原生页面转JS页面之间的空白期表现为应用启动后卡在纯白或纯黑界面若干秒然后才进入业务页面。这个白屏的本质是JS bundle还没加载执行完毕原生层已经铺好了空白容器。4.1 白屏可能出现在哪个环节我把RN启动过程拆成几个环节你可以按这个链路去排查原生壳启动系统加载MainActivity此时如果你没配SplashScreen默认就是白屏。Bundle加载debug模式下是从metro服务器拉取bundle网络慢或线上环境bundle体积大都会拉长这段时间。Bundle执行JS引擎执行bundle里的首次渲染代码如果你的根组件初始渲染太重比如首屏就拉一堆接口或者有大量同步计算屏幕会一直停在空白。首帧渲染React渲染完成但原生视图还没有被全部绘制出来。4.2 排查链路与常见解法第一步先确定是SplashScreen没配还是bundle加载慢。你可以在MainActivity的onCreate里打日志如果日志走到后、页面依然白很久那大概率是JS层的问题如果日志本身就有延迟那就是原生配置或设备性能问题。第二步如果确定是SplashScreen缺失现在常用的方案是splash-screen相关的库比如react-native-bootsplash。核心思路是让原生层在JS没ready之前先展示一张静态启动图等JS加载完后再调用hide方法平滑切换。配置不难Android端在MainActivity里初始化iOS端在AppDelegate里初始化。第三步如果启动图正常但白屏时间依然长重点看bundle体积和初始渲染。V8/Hermes的选择也会影响启动时间Android上开启Hermes能显著减少执行时间在gradle.properties里配hermesEnabledtrue。另外首屏渲染不要放在根组件里做大量网络请求可以先用本地缓存数据渲染一个可交互的首屏再在后台拉取更新。4.3 一套实用的启动配置建议我给自己项目定的启动优化标准大致如下Android/iOS都接SplashScreen且启动图颜色和首屏背景色一致避免视觉跳变。debug模式下metro的预加载插件如果有条件预先把bundle拉好减少重复等待。线上bundle按需拆分把首屏依赖的库合并非首屏路由做懒加载。排查是否使用了团队自研的基础库拖慢了初始化有些基础库会在启动时执行大量的instance初始化。提示React Native的白屏问题没有“一次配好永远不白”的银弹。它和网络、bundle体积、设备性能都有关系。我的排查顺序永远是先看原生有没有占位图再看bundle加载时间最后看首屏JS执行的时机。按这个顺序大概率能定位问题所在。5. VSCode插件补齐与Zustand编辑器体验和轻量状态管理的实战姿势5.1 VSCode里写React优先级最高的几个插件“VSCode什么插件支持react标签怎么闭合”这个问题本质上是在问两件事一是写JSX时标签的自动闭合二是有没有快速生成组件结构的代码片段。先说自动闭合。其实VSCode写JSX时输入开头标签后直接输入/编辑器通常会自动补全成配对标签这是内置能力不一定需要插件。但如果你的VSCode没有这个行为多半是因为文件类型没有被识别为JavaScript或TypeScript React检查一下右下角语言模式是不是JavaScript React或TypeScript React。如果想提升效率Auto Rename Tag是个好插件它能在你修改标签名时同步修改配对标签Prettier - Code formatter则在保存时帮你格式化JSX缩进和标签闭合。至于“快速生成组件”最常用的还是ES7的React扩展搜索关键词ES7 React/Redux/React-Native snippets它提供的rfc、rfce代码片段可以直接生成函数组件模板非常省时间。我自己的插件清单大概这些插件名作用必要性Auto Rename Tag同步改名配对标签推荐Prettier - Code formatter统一格式化JSX/TS强烈推荐ESLint代码规范、及时发现错误强烈推荐ES7 React snippets快速生成组件/函数模板推荐Tailwind CSS IntelliSense如果用Tailwind样式类名提示按需5.2 Zustand上手三步与selector性能坑“react使用zustand”也是高频词。Zustand这几年热度一路走高核心原因是它把“全局状态管理”的门槛降到了极低。简单说你不需要Provider不需要写Action Creator不需要配中间件三步就能用起来。第一步定义一个storeimport { create } from zustand; const useUserStore create((set) ({ user: null, login: (userInfo) set({ user: userInfo }), logout: () set({ user: null }), })); export default useUserStore;第二步在组件里读取状态和触发修改import useUserStore from ./store/userStore; function UserProfile() { const user useUserStore((state) state.user); const login useUserStore((state) state.login); if (!user) return button onClick{() login({ name: Tom })}登录/button; return div{user.name}/div; }第三步在组件外也能读或改import useUserStore from ./store/userStore; // 在非组件模块里比如请求拦截器 const token useUserStore.getState().user?.token; useUserStore.getState().logout();Zustand用得多了最容易踩的一个坑是selector误用导致的不必要渲染。比如你写const state useUserStore(); // 这会订阅整个store任何字段变化都会让组件渲染稍微大一点的store下这种写法会明显拖慢性能。正确的做法是让selector尽量精确只取当前组件真正用到的片段。如果某个需求需要同时取多个字段可以用useShallow做浅比较避免因为selector返回新对象而导致无限渲染。6. 大屏项目、vw/vh适配与React图表库选型“react 大屏 vwvh”这个搜索词通常是做数据可视化大屏智慧大屏、监控大屏时遇到的适配问题。大屏项目的目标很明确在一个固定设计稿尺寸一般是1920×1080上设计界面然后在各种不同分辨率的屏幕上等比展示不出现拉伸变形或大量留白。6.1 大屏适配的两种主流思路第一种是用vw/vh做单位换算。思路是把设计稿的px值转换成vw或vh比如设计稿宽度1920那么1vw等于192px / 100 19.2px所以一个宽度为192px的元素就写成width: 10vw。在React项目里可以用PostCSS插件比如postcss-px-to-viewport在构建时自动转换你写代码依然写px构建产物自动变成vw/vh。这种方案的好处是代码侵入小、适配平滑坑在于字体大小和小数像素可能在某些浏览器里出现渲染模糊另外如果要严格按照设计稿等比缩放可能会出现一个小问题——如果设计稿不是1920宽需要改配置。不过我实测下来对大多数大屏场景vw/vh方案够用且稳定。第二种是用transform: scale()整体缩放。思路把整个大屏页面固定为1920×1080然后在最外层容器上根据实际视口宽高计算缩放比例用CSS-scale缩放到对应尺寸。它的好处是开发的时候完全不考虑适配问题设计稿多大就写多大字体、边框、图表都统一缩放坑在于缩放后的元素在缩放因子不是整数时边缘可能模糊且页面里的弹窗、固定定位元素如果不在容器内部就会出现位置错乱。我的建议是大屏项目优先用scale方案因为开发效率高、效果可控如果要求极致的精细度和原生滚动交互再用vw/vh方案。6.2 React图表库怎么选“react 图表”这个关键词太宽了我把常见选择列出来你再对照自己的需求选图表库特点适合场景ECharts配合echarts-for-react或直接用echarts功能全支持海量图表类型中文资料多大屏、复杂业务图表、地图Ant Design Charts基于G2Plot开箱即用默认样式好看中后台系统、简单报表Recharts轻量、API友好、React风格纯正简单折线图、柱状图、饼图Visx基于d3组合灵活、自由度极高对可视化有强定制需求的团队Chart.jsreact-chartjs-2轻量、上手快简单图表且不想引入太重依赖在React生态里用ECharts我个人的踩坑经验是不要直接在每个组件里裸new一个echarts实例而是封装一个统一的图表组件负责初始化、resize监听、数据更新时setOption最后在组件卸载时调用dispose。这个封装看起来多写几行代码但在大屏里能避免大量内存泄漏和重复实例问题。大屏项目还有一个更隐蔽的坑ECharts初始化时容器宽度可能还是0因为布局还没完成导致图表渲染成默认宽度。解决方式是等容器有尺寸后再初始化或者在初始化前手动echarts.init前先display强转一下。7. Next.js还是ViteReact这个选择题其实考的是“你的应用需不需要服务器”最后说说“next.js和vite react”这个经典对比。很多新同学会把这个理解为“两个脚手架怎么选”其实它们不在一个维度上Vite是一个构建工具常和React搭配做纯前端SPANext.js是一个全栈React框架自带路由、SSR/SSG、API接口能力、图片优化等它是“React应用的一站式解决方案”。7.1 两者定位差异直接决定了使用场景ViteReact组合的业务场景是纯浏览器应用不需要SEO数据全靠后端接口前端只负责展示和交互。典型的例子是后台管理系统、数据看板、企业内部工具。它的优点是完全前端化部署就是一堆静态文件扔到Nginx或CDN上简单直接开发时Vite冷启动极快热更新体验好。Next.js的业务场景是需要考虑SEO、首屏速度、服务端数据或者想在一个应用里同时写前端和后端逻辑。典型的例子是官网、博客、营销页、以及需要社交分享卡片的业务页面。Next.js的服务端渲染能在用户看到页面前就把HTML拼好返回这是纯SPA做不到的。7.2 选型决策树我做技术选型时基本用这个决策树要不要SEO要 → Next.js。首屏加载速度是不是产品核心指标是 → Next.jsSSR/SSG。是否需要一个轻量后端提供API是 → Next.js的API Routes或Server Actions能够减轻独立后端压力。都没有纯内部后台 → ViteReact理由是简单、心智负担小、部署成本低。团队目前只有纯前端经验没写过Node服务可以先ViteReact等有明确SEO需求再迁移Next.js的迁移成本不算低但对中小项目也算可控。7.3 迁移成本和团队因素不可忽略还有一个很多人忽略的点Next.js最近几个版本一直在推App Router它引入的Server Component概念和传统React写法差别挺大对新人有不小学习成本。你搜索“react agent”“react btis”这类零散概念时可能也会看到一些关于Next.js未来方向的讨论有一些是比较前沿的提法作为普通开发者我的建议是不要被概念轰炸搞焦虑抓最核心的如果你的应用最终要输出HTML给搜索引擎或追求首屏极致体验选Next.js如果只是SPA生产力工具选ViteReact完全够用也不会丢人。我自己现在的习惯是绝大多数新项目起步用ViteReact只有在确定需要SEO或服务端能力时才引入Next.js。这个选择不是说Vite更高级而是它对前端团队更友好减少环境复杂度等需求逼到墙角再升级框架也不迟这本来就是React生态的魅力——同一个组件模型可以从纯前端一路走到全栈。最后再分享一条个人体会React学到现在我越来越觉得资料汇总这件事本质上不是“收藏”而是“筛选”。你每找一个资料都应该先想清楚自己处于哪个阶段、要解决什么问题否则只是在浪费时间反复看重复内容。今天这篇我尽量把我在入门、面试、RN排查、大屏图表、框架选型几个方向上的实际经验和踩坑记录都写进来了希望对你有点帮助。如果后面遇到具体问题最好的方式是去动手写一个最小可复现的demoReact的世界里跑通一次比看十篇文章都有用。