简介：面向准备前端岗位的求职者，React高频面试题PDF共收录258道经典考题，覆盖状态管理器使用时机、Real DOM与Virtual DOM的区别、JSX编译原理及浏览器兼容问题、React主要特点与优缺点、ES5与ES6语法差异、组件复用与render()职责等核心知识点。压缩包内仅包含1个PDF文件，大小661KB，轻量便携，方便日常翻阅与考前突击。目前已有326人学习下载，适合需要系统梳理React知识体系、提升面试通过率的开发者使用。多数题目附有要点解析与代码示例，能够帮助读者深入理解虚拟DOM工作流程、组件化设计思想及状态管理选型逻辑，也可用于自测知识掌握程度，查漏补缺。尤其是状态管理器使用场景、JSX转换机制、ES6与ES5写法对比等内容，配有直观代码片段，便于记忆和举一反三。同时适合作为前端团队内部培训的辅助材料。
1. 这份React题库到底是什么，值不值得刷
手头这份PDF标题很实在：React高频面试题_258题（部分题没答案）。我第一反应是"又一份网上拼凑的面试题"，但翻完前几十题之后，改观了不少。它不像很多营销号整理的题库那样只堆结论，而是真把React面试里会碰到的考点按模块摊开了，覆盖了基础概念、组件通信、Hooks、性能优化、React Router、状态管理、SSR、源码原理这些方向。
先说个现实问题：React面试题这几年变化非常大。三年前问"setState是异步还是同步"已经算深挖了，现在面试官上来就是"useEffect的依赖数组到底怎么比较的""useMemo和useCallback用不对会有什么后果""Concurrent Mode到底解决了什么问题"。这份题库里恰好有一批这样的新题，不是老掉牙的"什么是虚拟DOM"那种入门级内容。
再说"部分题没答案"这件事。我在实际刷题过程中发现，没答案的题反而比有答案的题更有价值。理由很简单：带答案的题你很容易扫一眼"哦我看懂了"就划过去，根本没形成记忆；而没答案的题逼着你停下来，翻文档、写demo、查源码，这个过程才是真正把知识内化的过程。所以这份PDF的"缺点"在我看来反而是优点。
适合谁来刷？准备跳槽的前端工程师、刚学完React想检验水平的初级开发者、以及需要带团队做技术摸底的技术Leader。不太建议完全零基础的人拿它当入门教材，因为很多题目默认你已经知道JSX是什么、组件怎么写了。如果你连React的基本用法都没过一遍，建议先去官方文档把tutorial跑通，再回来刷题。
下面我把这份题库里最有代表性的题目类型做个拆解，每类题我会给出不只是答案的答题思路，还会说明面试官到底在考察什么，以及你怎么回答能加分。
2. 核心原理题：虚拟DOM、diff算法与渲染机制
2.1 虚拟DOM相关的题目该怎么答才不落俗套
题库里必然有"什么是虚拟DOM""虚拟DOM比真实DOM快吗"这类题。很多人的答案是背课文："虚拟DOM是一个JavaScript对象，它描述了真实DOM的结构……"然后就没有然后了。
我给个建议：别背定义，讲清"为什么需要"。你可以这样组织回答：
虚拟DOM的出现不是为了"快"，而是为了"让开发者用声明式的方式写UI"。在没有虚拟DOM的时代，我们操作DOM要靠命令式API，手动管理每一步的增删改，这在复杂交互场景下非常容易出bug。虚拟DOM让开发者声明"UI应该长什么样"，框架负责把声明翻译成高效的DOM操作。
至于"快不快"这个问题，要分场景说。在小型应用里，手写DOM操作可能比虚拟DOM的diff遍历还快，因为React每次渲染都要创建一棵新的虚拟DOM树。但在大型应用里，手动优化DOM操作的复杂度会指数上升，而虚拟DOM配合diff算法能把更新范围控制在最小集合内，整体的可维护性和性能表现会好得多。
注意：面试官如果追问"React的diff算法复杂度是多少"，答案是O(n)。React做了三个假设才把复杂度从O(n³)降下来——不同类型的元素产生不同的树、开发者可以通过key暗示哪些子元素是稳定的、跨层级移动元素的情况极少发生。这三个假设你可以展开讲，是加分项。
2.2 从setState看React的批处理机制
题库里另一类常见题是"setState到底是异步还是同步"。这道题以前有个标准答案："在React事件处理函数里是异步的，在setTimeout和原生事件里是同步的。"但这个答案在React 18之后不准确了。
React 18引入了自动批处理（Automatic Batching），setTimeout、Promise回调、原生事件处理器里的setState也会被批量合并。这是为什么？因为React 18的并发特性要求更新可以被打断、可以重新调度，如果每次setState都立刻同步更新，并发调度就无从谈起。
遇到这类题，我的建议是一边回答一边写小demo，直接把"在React 18下setTimeout里连续setState三次，组件只渲染一次"这个现象演示出来。面试官问原理题不光是考你知道不知道，更是看你有没有实际验证过。
2.3 深入diff算法的三个策略
React的diff算法是高频中的高频，但大多数人只能说出"同层比较、key优化"这几个关键词。题库里有题直接问"React的diff策略有哪些"，我把它展开一下：
第一，不同类型的元素直接重建。比如从<div>变成<span>，React会销毁旧的DOM树并重新创建。这是最简单也最暴力的策略，但它在绝大多数场景下是合理的——你真的很少会把一个div直接变成span还希望保留内部状态。
第二，同类型元素通过key来匹配。这就是为什么列表渲染一定要写key，而且要写稳定的key。用数组下标当key为什么有问题？因为如果你在列表头部插入一条数据，下标会整体后移，React会误以为每个组件的内容都变了，导致不必要的重渲染甚至状态错乱（比如输入框内容对不上号）。
第三，跨层级移动不做复用。React没有实现跨层级复用DOM节点的能力，如果检测到节点移动了层级，它会销毁再重建。所以在写组件时要尽量避免把节点在层级间移动的布局变化，用CSS的transform、visibility等方案替代。
3. Hooks高频题：不只是背API，要理解设计意图
3.1 useEffect和useLayoutEffect的选用场景
题库里关于Hooks的题目一定不少，比如"useEffect和useLayoutEffect有什么区别"。这题我见过太多人答成"useLayoutEffect是同步的，useEffect是异步的"——这说法太粗糙了，而且容易误导。
准确的说法是：useEffect在浏览器绘制之后异步执行，useLayoutEffect在DOM变更之后、浏览器绘制之前同步执行。两者的执行时机差异决定了使用场景：useLayoutEffect适合读DOM布局、测量尺寸这类必须在绘制前完成的操作，否则用户会看到闪烁；useEffect适合绝大多数副作用操作，比如发请求、设置定时器、订阅事件。
实操经验：在useLayoutEffect里做状态更新会阻塞绘制，所以除非必要（比如读取DOM尺寸后要调整UI），否则别用useLayoutEffect。你可以这样验证：做一个读取元素宽度的需求，分别用useEffect和useLayoutEffect跑一下，用useEffect会看到初始值和正确值之间的闪烁，用useLayoutEffect则不会。
3.2 useMemo和useCallback到底该不该用
题库里几乎必有"useMemo和useCallback的作用和使用场景"。这道题现在有反套路倾向——**面试官可能反问你"是不是所有地方都应该用useMemo包裹？"**答案是否定的。
useMemo和useCallback也是要消耗内存的，它们本身有创建成本、依赖比较成本，如果依赖项频繁变化，缓存会不断失效重建，性能反而更差。合理的使用场景是：被包裹的计算逻辑本身代价较高（比如大量数组遍历、复杂对象深比较），或者子组件使用了React.memo，需要稳定的props引用。
我见过不少开发者写出这样的代码：
const handleClick = useCallback(() => { setCount(count + 1); }, [count]);这里useCallback完全没有必要，因为setCount本身是稳定的，即使count变化导致handleClick重新创建，对性能的影响也微乎其微。更关键的是，这段代码的依赖项写得不完整——如果handleClick还引用了其他props，这里忘了写依赖，就会产生闭包陷阱。所以我的建议是：默认不优化，遇到性能瓶颈再优化，优化时配合React DevTools的Profiler看看是不是真的有必要。
3.3 闭包陷阱与依赖数组的坑
Hooks题里，"闭包陷阱"是必考的重灾区。典型场景是这样的：
useEffect(() => { const timer = setInterval(() => { console.log(count); }, 1000); return () => clearInterval(timer); }, []);这段代码里的setInterval回调永远只能读到初始的count，因为effect闭包在挂载时捕获了当时的count值。解法有三种：把count加进依赖数组（但这会导致定时器反复重置）、用useRef保存最新的count、或者用setInterval的函数式更新setCount(c => c + 1)。
面试答这道题的时候，最好能把三种解法都列出来，并分别说明适用场景。这比只答"用useRef"要高级很多，因为你展示的不只是知道一个API，而是理解了闭包、依赖数组和函数式更新之间的关系。
4. 组件通信与状态管理：代码组织能力的试金石
4.1 从题库看React组件通信的六种方式
组件通信是前端面试里最"工程化"的题目之一。题库里相关的题有"父子组件怎么通信""跨层级组件怎么通信""兄弟组件怎么通信"。我把所有方式整理成一个表，方便对照：
| 通信场景 | 推荐方式 | 不推荐的方式 |
|---|---|---|
| 父→子 | props传参 | 直接用全局状态（过度设计） |
| 子→父 | 回调函数（props里传函数） | 用第三方状态库（杀鸡用牛刀） |
| 兄弟组件 | 状态提升到最近公共父组件 | Event Bus（难追踪数据流） |
| 跨多层 | Context | 每一层都手动传props（props drilling） |
| 任意层级 | Redux、Zustand、Jotai等 | 全部用Context（更新频繁时性能差） |
| 无关系组件 | 状态库或发布订阅模式 | 搞复杂的全局单例 |
面试时你最好不只给清单，而是讲一个真实选型案例。比如"我之前做过一个项目，用户登录信息需要全站共享，最初用的Context，后来发现很多非相关组件由于消费了Context导致重渲染，就换成了Zustand，配合选择性订阅解决了问题"。这种回答路径能展示你的工程判断力。
4.2 Redux还是Zustand：状态管理选型背后的问题
题库里占了不小篇幅的是Redux相关，比如"Redux的工作流程""什么是中间件""Redux Toolkit解决了什么问题"。但我想多说一点状态管理选型的思考，因为面试题往往引申出开放性问题。
Redux不是万能的，但也不是过时的。如果你维护一个大型项目，多角色权限、复杂联动业务、需要时间旅行调试，Redux Toolkit依然是可靠的选择。它的模式统一、约束严格，团队协作时不容易出现代码风格分裂。
如果项目规模不大，或者状态以服务端缓存为主，Zustand这类轻量方案更合适。Zustand的优势是样板代码少、可以直接在组件外读写状态、支持选择器避免多余渲染。我在实际项目中用Zustand最多的地方是全局UI状态（主题、抽屉开关、Toast队列）、用户会话信息、临时性的跨组件数据。
面试官问你"Redux和Context怎么选"时，我的建议是这样的回答思路：先说明两者解决问题的层级不同——Context是依赖注入机制，Redux是状态管理范式；小范围低频更新的状态用Context没问题，频繁更新或跨页面复杂逻辑用Redux或Zustand；然后补一句"我们项目里两者是共存的，UI主题用Context，业务数据用Redux"。
5. 性能优化与工程化：区分初级和高级的分水岭
5.1 React性能优化的正确检查顺序
题库里"如何优化React应用性能"几乎是必考的。很多人的回答是背列表：React.memo、useMemo、shouldComponentUpdate、虚拟列表……背完就结束。这种答法的问题是把优化手段当成了优化本身，没有体现性能排查的思路。
正确的答法应该是从测量开始。我自己的排查顺序是：
- 用React DevTools Profiler录制操作，找出渲染耗时的组件。
- 检查这些组件为什么渲染——是props变了、state变了还是父组件重新渲染了。
- 根据原因选择手段——props没变但父组件渲染导致子组件跟着渲染，用React.memo；组件内部有昂贵的计算，用useMemo；列表渲染卡顿，用虚拟滚动，比如react-window或react-virtualized。
- 优化后再次录制，对比渲染时长和渲染次数。
这个排查顺序非常重要，因为性能问题的根源千差万别，一上来就套useMemo很可能白费功夫。我见过一个真实案例：一个表格页面卡顿，大家第一反应是给所有子组件加React.memo，结果没什么效果；后来通过Profiler定位，发现是Table组件内部每次渲染都重新创建了一个很大的columns数组，导致Table的浅比较永远失败。把columns用useMemo或提升到组件外部之后，问题立刻解决了。
5.2 key的正确用法：一个细节拉开差距
题库里"为什么key不能用index"这道题看似简单，但它可以考出真水平。光是说出"用index会导致列表项无法正确复用"还不够，最好能举出具体的错误现象。
我给你一个完整的示例：有一个可编辑列表，每行是一个输入框，通过index渲染：
{items.map((item, index) => ( <Input key={index} defaultValue={item.name} /> ))}现在你在第一行后面插入一条新数据，React复用了index=1的DOM节点，但defaultValue只在首次挂载时生效，所以新插入的数据对应的输入框可能显示的是旧数据的值。更严重的是，如果列表项有内部状态（比如勾选状态、展开状态），所有状态都会错位。
正确做法是使用数据自带的唯一ID作为key。如果没有ID，可以在数据生成时用crypto.randomUUID()或nanoid生成。如果数据来自后端，通常会有id字段，直接用即可。面试时如果能把这个问题讲得这么细，几乎可以肯定这个考点你就拿下了。
5.3 从一道题看React 18的并发特性
题库里还应该有"React 18的新特性有哪些"。除了自动批处理，最重要的就是startTransition和useDeferredValue。
这两者解决的问题是同一个：让非紧急更新让路给紧急更新。比如你在搜索框里输入关键词，同时要渲染大量搜索结果。输入是紧急更新，必须立刻响应，否则用户觉得卡；搜索结果的渲染是非紧急的，可以延迟。
const [keyword, setKeyword] = useState(''); const [searchResults, setSearchResults] = useState([]); const handleChange = (e) => { const value = e.target.value; setKeyword(value); startTransition(() => { setSearchResults(filterData(value)); }); };这样React会在保证输入框流畅响应的情况下，再去渲染搜索结果。面试时说清楚"紧急更新、非紧急更新、可中断渲染"这三个概念，再把startTransition的实际使用场景（搜索、筛选、页面切换）讲一下，就已经超过90%的候选人了。
6. React Router与常用生态：实战能力的侧面印证
6.1 路由模式与History API的原理
题库里React Router相关题目出现的频率不低。最常见的是"BrowserRouter和HashRouter有什么区别"。这道题可以同时考察你对浏览器API的掌握程度。
BrowserRouter用的是History API，URL更干净（不带#），但需要服务器配置把所有路径都重定向到index.html，否则刷新页面会404。HashRouter用的是URL的hash部分，兼容性更好，不需要服务器配置，但URL不好看，而且hash变化不会触发浏览器向服务器发请求。
实际项目我推荐BrowserRouter，只要确保部署时做好了Nginx或Node服务器的rewrite配置就好。但如果你的应用是纯静态托管在一些不支持rewrite的平台上，HashRouter反而是更稳妥的选择。
6.2 React.memo、PureComponent和shouldComponentUpdate的对比
题库里另一类高频题是"React.memo和PureComponent有什么区别"。我来拆解一下：
| 对比项 | React.memo | PureComponent |
|---|---|---|
| 适用对象 | 函数组件 | 类组件 |
| 比较方式 | 默认浅比较props | 浅比较props和state |
| 自定义比较 | 第二参数传入自定义比较函数 | 重写shouldComponentUpdate |
| 用法 | 包裹组件导出 | 继承PureComponent |
需要特别提醒的是，浅比较只比较引用。如果你在父组件里内联创建了对象或函数props，即使内容一样，React.memo也会认为props变了，memo就失效了。这也是为什么useCallback和useMemo经常和React.memo搭配使用——useCallback保证子组件拿到的回调函数引用稳定，React.memo的浅比较才能生效。
6.3 服务端渲染与Next.js的考点
题库如果是2025、2026年整理的，一定会有SSR和Next.js相关题目。核心考点是"CSR、SSR、SSG有什么区别""为什么需要SSR""Next.js的App Router和Pages Router有什么不同"。
回答SSR核心优势时别只说"SEO友好"，要补充两个角度：首屏加载速度和社交分享的抓取兼容性。有些爬虫不执行JavaScript，CSR页面分享到社交平台抓不到标题和描述，SSR没有这个问题。但SSR也不是免费的，服务器渲染压力更大，部署更复杂，所以现在很多内容型网站用SSG静态生成，交互多的地方用CSR或hydration混合。
React生态相关的新题还有React Native（热词里也出现了"react native启动白屏""React Native如何实现循环滚轮"这些具体问题），如果你的岗位方向涉及移动端，React Native的架构演进（从旧架构到Fabric、TurboModule）也值得提前准备。
7. 刷题策略与复习路径：258题怎么刷才有效
7.1 按照"三遍刷题法"吃透题库
面对258道题，普通人如果从第一题按顺序刷到最后一题，大概率是边刷边忘。我建议用"三遍刷题法"：
第一遍快速过题，不写答案，只看题目本身能不能说出大概方向。能说出的打勾，说不出的打问号。这个阶段控制在两天内完成，目的是做一次全面的"知识体检"。
第二遍精做问号题，针对第一遍没思路的题，先自己想、再翻文档、最后写代码验证。这一遍是真正耗时间的阶段，也是收获最大的阶段。每道题都记录成笔记，用"题目+我的答案+参考依据"的结构化格式，积累下来就是你的专属面试手册。
第三遍模拟问答，把题库当成考卷，随机抽题，给自己计时，像真实面试那样口头作答。注意不是默念而是真的说出来，因为很多人在心里想的答案和嘴上说的完全是两个水平，口头表达需要刻意训练。
7.2 没答案的题怎么处理：倒推考点与构建可验证的答案
题库里"部分题没答案"，我建议你把它当作一种刻意练习素材。遇到没答案的题，按以下步骤处理：
第一步，拆解题目中的关键词。比如题目问"React中的合成事件是什么"，核心概念是"合成事件"，你要先定位到React官方文档中SyntheticEvent那一节。
第二步，写出自己能想到的所有相关知识点。合成事件至少包括：React封装了浏览器原生事件、事件委托到根容器、合成事件池（React 17前）、为什么不直接绑定到具体DOM节点。
第三步，用代码或文档验证。比如"事件委托到根容器"这一点，React 17版本之前事件挂载在document上，React 17之后挂载在root容器上。你可以打开一个React项目，在事件回调里打印e.currentTarget，看看到底是谁。
第四步，把答案整理成"结论+解释+案例"的结构。结论放第一句让面试官听到核心，解释补充原理，案例证明你实践过。
7.3 面试答题的表达技巧：结论先行加案例支撑
刷题到最后，拼的不只是知识量还有表达方式。同样一道题，会答和答得好差别很大。我给你几个实际有用的表达技巧：
多使用结论先行的方式回答。面试官每天面很多人，精力有限，你上来先给结论，他不用费力从你的一大段话里提炼重点。比如问"useEffect的执行时机"，你可以先说"useEffect在浏览器完成绘制之后异步执行"，然后解释为什么会有这个时机、和useLayoutEffect怎么区分。
在解释完原理后，补充一个你实际遇到过的案例。比如"我之前做的管理系统里有个大表格，加筛选功能后发现输入框有延迟，排查之后发现是筛选逻辑没有用useMemo，大量数据每次都重新filter导致计算量太大"。这种具体案例比任何理论都更有说服力——它证明你不是背书，而是真的做过项目踩过坑。
7.4 结合热词调整复习重心：2026年的React面试风向
再聊点趋势层面的东西。React面试题这几年的重心变化很快，从热词里能看到端倪："React Native启动白屏""React和Vue路由差异""AI Agent React""前端如何优化面试题"。这些背后对应的是一些新方向。
第一个风向是跨端能力越来越多地被考察。React Native虽然不算新，但它的启动优化、架构演进、和新原生框架的对比，是移动端或全栈岗位面试的加分项。如果时间允许，建议用React Native跑一个简单demo，知道它的核心概念和常见性能坑（比如启动白屏是JS Bundle加载耗时、图片缓存策略等），面试提到几条就够用了。
第二个风向是AI与React的结合。热词里出现"AI Agent React""react agent"，说明越来越多团队开始做AI相关的产品，面试可能问"如何在React应用里集成大模型能力""如何流式渲染LLM的输出"。如果碰到这类题，展示你对流式数据渲染（比如SSE）、流式文本展示的处理经验会很加分。
第三个风向是React与Vue的对比题仍然常驻。这道题没有标准答案，关键是体现出选型的依据：团队情况、项目规模、生态成熟度、人员技术栈匹配度。千万别说得像"React比Vue好"或"Vue比React好"，面试官要的是你具备客观分析框架业务场景的能力。
8. 写在最后的实操建议
刷完这258题，我最大的体会是：面试题本质上是技术知识图谱的索引，而不是背诵材料。它帮你发现知识盲区，告诉你要掌握哪些点，但真正能让你在面试中站稳脚跟的，是你对这些知识点的深层理解，是你亲手写过的代码，是你从报错中总结出来的教训。
给你一个实用的小技巧：把题库里的题目按"能立刻答出、有点印象、完全不会"三档分类，然后从"有点印象"的那档开始补——它离你的能力边界最近，补起来效率最高。等这一档清空了，"完全不会"的档位会自然降级成"有点印象"，如此循环推进。这个过程不需要太长时间，每天两小时，两周就能把258题过完两遍。
我当年准备React面试的时候也刷过类似的题集，但真正让我在面试现场镇定自若的，不是背熟答案，而是每一道题我都亲手写过demo、打印过日志、看过源码调用栈。把做题变成做实验，把答案变成经过验证的经验，这是我能给你的最实在的建议。
本文还有配套的精品资源，点击获取
