前阵子帮朋友做模拟面试他React用了快三年简历上写了三个项目结果我问他父组件一次setState从触发到屏幕更新中间React到底干了什么他愣了半天说不就是重新render一下吗这个回答不算错但正是这种知其然不知其所以然的状态让很多人在第二轮、第三轮就挂掉了。React面试看起来是考记忆——考你背没背过生命周期函数、Hooks规则、diff算法实际上所有追问链的终点都是同一个东西你有没有真正理解React的决策模型。写业务和吃透框架是两码事面试官只要连续追三句就能把你归到哪一类清清楚楚。这篇文章把React面试里最高频、也最容易被问崩的几个主题串一遍从生命周期函数到渲染机制从Hooks的闭包陷阱到状态管理选型从性能优化到React 18/19的新特性。最后我会复盘一次React Native启动白屏的完整排查过程——这类实战题现在面试官越来越爱问因为编不了。内容不追求面面俱到但每一条都会给出可以直接用的回答思路和例子。1. 面试官问的从来不是API而是你的为什么1.1 为什么背API式准备越来越不奏效前几年React面经还流行背诵体生命周期几个阶段、Hooks规则几条、diff算法三步。现在这套越来越不灵了原因有两个。第一React本身迭代太快。你背的是16.x的componentWillMount人家项目早用到18、19了新的并发特性、Suspense、Actions光靠背根本追不上。第二面试官也学精了。他们知道网上有海量面经背题成本极低所以会把问题改成场景题、对比题和追问链专门检验你是用过还是理解。举个例子我在面试里特别爱出的一道题现在有一个列表点击某项要展开详情展开时要请求数据这个展开状态应该放哪大多数人第一反应是放state里但这只是第一层。接着追问这个列表项是子组件状态如果放父组件会导致整个列表重渲染你怎么办这时候就需要你讲清楚setState的传播路径、React.memo的作用边界、状态提升与下沉的取舍。一套组合拳下来有没有深度立刻现原形。所以准备React面试第一个建议是把这个API怎么用换成这个机制为什么存在。你要让面试官觉得你不是在用React而是在理解React。1.2 一条完整的追问链虚拟DOM到底解决了什么几乎所有公司都会问谈谈你对虚拟DOM的理解但真正拉开差距的是后面的追问。模拟一下完整链路面试官问虚拟DOM比直接操作DOM更快吗如果你答是的因为它减少了DOM操作次数那就等着被反杀。真实答案是不一定。一个按钮点击改一行文字直接document.getElementById(xxx).textContent yyy可能比虚拟DOM diff还快。虚拟DOM真正的价值在于——把UI从命令式改成了声明式。回忆一下JQuery时代你脑子里必须维护一个隐形的状态机用户点了A之后B、C、D各自要变成什么样子DOM更新的顺序错了就会出现脏状态。你改的是DOM但业务逻辑散落在各个事件回调里。React出现之后你只需要说当state长这样UI就长这样至于怎么从旧UI变成新UI是React替你算的。为了支撑这套声明式模型React需要一个统一的数据结构来描述UI这就是虚拟DOM——本质上就是一个普通的JavaScript对象const element { type: div, props: { className: card, children: [ Hello, , { type: span, props: { children: React } } ] } };有了这层抽象同一套逻辑可以跑在浏览器DOM上react-dom也可以跑在原生视图上React Native甚至可以在测试环境里完全不依赖真实DOM。所以回答虚拟DOM时别只盯着减少DOM操作要往抽象可预测跨端上靠这才是面试官想听的内容。再往下追就是diff算法React怎么高效地发现两棵vdom树的差异核心思路是三条预设——不同的元素类型直接重建、同类型元素走props更新、兄弟节点用key识别。做了这层约束React才能把整棵树的新旧比较从朴素的O(n^3)级别压到接近O(n)。比较深拷贝树再递归比较这种朴素方案这个工程取舍才是精髓。这条追问链串起来的其实就是React的决策模型vdom描述UI - diff找差异 - commit应用到真实DOM。后面第3节会更细地拆这条链路。2. 生命周期函数从背钩子到讲流程设计2.1 React 18里你还记得哪几个阶段生命周期函数这么多年一直挂在React热词榜前几可见面试必考。但现在考法变了不再是背出五个钩子而是让你把类组件生命周期和Hooks等价关系讲清楚。先花三十秒对齐基础。类组件生命周期可以归成三大阶段挂载、更新、卸载。阶段类组件钩子Hooks对应挂载前constructoruseState初始值 / useReducer init渲染前getDerivedStateFromProps一般不直接对应通过父组件传新props渲染render函数组件本身DOM挂载后componentDidMountuseEffect(fn, []) / useLayoutEffect更新前shouldComponentUpdateReact.memo父级控制更新后componentDidUpdateuseEffect(fn, [deps])卸载前componentWillUnmountuseEffect的cleanup函数这张表看着简单背后藏着一个关键认知函数组件里没有真正的生命周期这个说法只有副作用在什么时候执行。哪个阶段到哪类副作用这个转换就够聊三分钟的。2.2 从哪个阶段到流程设计怎么答才高级面试官问生命周期如果只背阶段表分数最多及格。真正加分的是展示出流程设计能力。几个最常被追问的点第一数据请求放哪类组件时代规范是componentDidMount函数组件时代是useEffect。为什么不能放在render里因为render必须保持纯函数否则每次渲染都可能触发副作用轻则重复请求重则死循环。这个为什么一讲出来就和背API的人拉开了距离。第二清理工作怎么设计监听事件、定时器、WebSocket连接都要在卸载时清理。useEffect的cleanup就是componentWillUnmount的替代品useEffect(() { const timer setInterval(() { setCount(c c 1); }, 1000); return () clearInterval(timer); }, []);第三注意React 18之后开发模式的StrictMode会故意把effect执行两次挂载 - 清理 - 挂载这是为了逼你把effect写成可重复执行的而不是只跑一次。很多候选人不知道这个行为开发时看到接口被请求两次就慌了以为代码写错了。面试时主动说出这一点反而是加分项。还有一招进阶useEffect和useLayoutEffect怎么选。useEffect在浏览器绘制完成后异步执行用户可能先看到一帧旧内容再看到新内容useLayoutEffect在DOM变更后、绘制前同步执行适合测量布局、同步改样式。我做过一个拖拽定位组件用useEffect做定位总是一闪换成useLayoutEffect就稳了。面试里能把这个区别讲出实际案例说明真的踩过坑。2.3 面试官最爱挖的坑请求竞态生命周期问题里还有一个杀招——请求竞态。比如用户进入A页面发请求马上又切到B页面发请求结果A的响应后到把B页面的数据覆盖了。解法也不复杂在useEffect里用一个作废标志useEffect(() { let cancelled false; fetch(/api/detail?id${id}) .then(res res.json()) .then(data { if (!cancelled) setData(data); }); return () { cancelled true; }; }, [id]);componentWillUnmount能清理DOM事件但没法取消一个已经发出的Promise所以用cancelled标志来忽略过期响应。这个问题能聊清楚面试官对你的评价会从会用跳到懂并发下的状态一致性——这正好是React 18并发特性的思想雏形。3. 渲染机制与diff算法必问但多数人答不透的底层3.1 一次渲染的完整链路Render、Reconcile、Commit第二个必考大模块是渲染机制。面试官问setState之后到底发生了什么你要是只答触发render一定会被追问到怀疑人生。正确的回答框架是三步Render阶段构建setState触发更新React从根节点开始遍历生成新的虚拟DOM树。这一步可以被打断、被抢占对应Fiber架构。Reconcile阶段协调把新旧树做diff算出哪些DOM节点要增删改同时构建一份更新指令。注意这个阶段也是可中断的。Commit阶段提交把diff结果一次性同步应用到真实DOM触发componentDidMount/Update、useEffect等副作用。Commit是同步不可中断的因为浏览器DOM更新必须原子化。为什么要引入Fiber因为老的递归栈结构一旦开始遍历就不能停整棵树太大时会出现长时间占用主线程、页面卡顿的现象。Fiber把任务拆成一个个小的工作单元通过链表结构保存现场做完一部分发现时间不够就把控制权还给浏览器下一帧再接上——这就是并发特性的地基。3.2 diff的三条策略以及key为什么是保命符React的diff快靠的不是黑科技而是三条很务实的预设策略不同类型的元素div变成p或组件A变成组件B直接销毁重建不做精细比较同类型元素只比较props差异更新变化的部分子元素列表通过key判断元素是新增、删除还是复用。前两条好理解第三条是面试必考。key的语义不是唯一标识而是稳定身份。你在列表中间插入一条数据如果key用的是数组下标React会认为后面的每一项都没变位置然后把旧props复用到错误的节点上轻则UI错乱重则表单失焦、状态错配。// 错误示范中间插入数据会导致后续项状态错位 {todos.map((todo, index) Todo key{index} todo{todo} /)} // 正确示范用稳定唯一的id {todos.map(todo Todo key{todo.id} todo{todo} /)}所以回答key能不能用index时别只说不行要讲出后果用index的列表在删除、插入、排序时会复用错节点React的diff算法认为节点类型没变、只是props变了从而跳过卸载重建带着旧state的组件就被错误复用了。能说出这一层才证明你理解key在协调阶段的作用而不只是知道要写key。3.3 不可变数据为什么是React的宪法与渲染机制绑定的还有不可变数据原则。React做props比较时基本用的是Object.is浅比较React.memo、shouldComponentUpdate同理。如果你直接修改state里的对象属性新旧对象引用相同浅比较会判定没变化更新直接被跳过页面不刷新bug还特别难查。const [user, setUser] useState({ name: 张三, age: 18 }); // 错误直接改了原对象 user.age 19; setUser(user); // Object.is(旧, 新) trueReact可能不渲染 // 正确生成新引用 setUser({ ...user, age: 19 });官方要求不可变更新不是为了道德洁癖而是为了让React能用引用比较快速判断要不要更新省掉深比较的开销。展开讲这还牵涉到状态管理库的设计Redux的reducer也是这个逻辑和性能优化。面试里把引用相等和值相等的区别讲清楚四两拨千斤。4. Hooks三大核心问题闭包、依赖、执行时机Hooks模块现在比生命周期更常考尤其是几个隐蔽的坑几乎每个都是我见过真实候选人当场翻车的点。4.1 useState闭包陷阱setInterval里那个永远不变的count先说最经典的坑。下面这段代码预期每秒count加1实际上它永远停在1const [count, setCount] useState(0); useEffect(() { const timer setInterval(() { setCount(count 1); // 闭包捕获的是首次渲染的count0 }, 1000); return () clearInterval(timer); }, []);原因很简单effect是在第一次渲染时创建的它闭包捕获了当时的count0。后面每次渲染虽然重新执行了组件函数但setInterval的回调始终是第一次创建的那个函数。解法有三种按场景选// 方案一函数式更新不依赖外部count setCount(c c 1); // 方案二把count加进依赖数组但会导致定时器每次重新创建 useEffect(() { /* ... */ }, [count]); // 方案三用useRef保存最新值 const countRef useRef(0); countRef.current count; setInterval(() { setCount(countRef.current 1); }, 1000);面试时能把这个坑和三种解法讲全再顺带说一句函数式更新可以脱离闭包捕获基本就稳了。4.2 useEffect依赖数组多一个少一个都是坑依赖数组是Hooks面试的重灾区。少了依赖effect读到的是过期值多了依赖effect频繁触发。经典的数据请求例子useEffect(() { let cancelled false; fetch(/api/user/${userId}).then(res res.json()) .then(data { if (!cancelled) setUser(data); }); return () { cancelled true; }; }, [userId]);如果把userId漏掉组件切到另一个用户effect不会重跑页面显示的永远是第一个用户的数据。现代工程一般用eslint-plugin-react-hooks的exhaustive-deps规则拦截但面试里没人看你装了插件需要你自己讲出依赖数组是effect的入参这个本质。依赖变了effect就该重跑不想重跑就要想清楚是不是依赖选多了。4.3 useCallback与useMemo用对是优化用错是负担然后是useCallback和useMemo现在出现频率极高因为很多人滥用。先给结论这两兄弟解决的都不是当前组件慢的问题而是帮助子组件跳过渲染的问题配合React.memo才会生效。const handleClick useCallback(() { doSomething(id); }, [id]); const list useMemo(() expensiveCompute(items), [items]); return Child onClick{handleClick} list{list} /;如果不包useCallback每次父组件渲染都会生成新的函数引用Child即使用了React.memo也会因为props引用变了而重渲染。但注意如果Child本身没有memouseCallback纯属给函数加锁没有任何收益还多了一次依赖比较的开销。useMemo同理计算不重的场景包上它反而比直接算更慢。正确姿势是先有性能问题渲染链路经过Profiler确认再考虑这两个API。4.4 自定义Hook的设计套路与Hooks规则自定义Hook是设计题的高频考点。面试官会让你手写一个useDebounce设计一个useLocalStorage。套路很固定提取逻辑、返回状态与操作、用use开头命名。举个例子function useDebounce(value, delay 300) { const [debounced, setDebounced] useState(value); useEffect(() { const timer setTimeout(() setDebounced(value), delay); return () clearTimeout(timer); }, [value, delay]); return debounced; }Hooks规则两条顶层调用不能在条件、循环、嵌套函数里调用因为React靠调用顺序记录hook对应关系只在函数组件或自定义Hook里调用。这两条背出来不难但你还要补充一句为什么不能条件调用——React内部用一条链表按顺序存放每个hook的状态如果某次渲染跳过了某个hook下一次渲染就对不上号了。把这个机制讲出来比单纯背规则高一个段位。5. 状态管理方案选型面试中的场景题怎么答5.1 先分清楚你要管理的其实是四类状态状态管理选型几乎是高级岗位必考但面试官通常不是让你推荐一个库而是抛一个场景让你设计方案。我建议先把状态分类这步本身就能让面试官眼前一亮组件内部状态某个弹窗开关、表单输入值useState/useReducer就够了URL状态筛选条件、分页页码放URL里方便分享和刷新保留不要盲目塞进store服务端状态用户信息、列表数据、缓存本质是服务端数据的本地缓存用React Query这类库管理比手动useEffectuseState强得多全局客户端状态主题、登录态、跨组件的复杂交互状态才需要考虑Context或Redux/Zustand。大多数候选人张口就是用Redux吧或者用Context吧压根没分析状态的性质。你先把分类讲出来就已经赢了一半。5.2 场景题的答案框架Context、Redux还是Zustand假设面试题是多级嵌套的组件树要共享一个购物车数据状态要跨页面保留怎么选型我心中的回答框架分三步。第一步看更新频率和数据量。购物车会频繁增删改且多个无关组件要读同一份数据这就排除了把所有东西塞Context的偷懒方案因为Context每次value变化会通知所有consumers重渲染组件树一大就会吃亏。第二步看团队规模与工程约束。Redux的优势不是快而是可预测、可追踪、中间件生态成熟。Redux Toolkit已经把样板代码压得很低适合多人协作的中大型项目。Zustand的优势是轻、不需要Provider包裹、按selector订阅每次更新只通知用到的组件。我个人的选型口诀小项目优先Zustand或纯Context团队体系成熟、状态流复杂到需要时间旅行调试时上Redux Toolkit。第三步给出一个可落地组合。比如购物车数据用Zustand建一个store用selector精确订阅数量和小计登录信息这种低频数据放Context列表页筛选条件放进URL query。这样全局状态不打架也不用全家桶式地把所有东西都塞进store。5.3 高频追问为什么Context一变全部子组件都跟着重渲染这里有个高频坑必须单独讲。很多人以为用了React.memo包住子组件Context更新时子组件就安全了结果发现还是全部重渲染。原因是Context的value只要是一个新对象引用所有useContext消费方都会强制重渲染memo的props浅比较根本拦不住。// 错误每次渲染都生成新对象所有消费方遭殃 MyContext.Provider value{{ theme, setTheme }} {children} /MyContext.Provider // 改进用useMemo稳定value引用 const value useMemo(() ({ theme, setTheme }), [theme]); MyContext.Provider value{value}{children}/MyContext.Provider再进阶一层如果不同组件只关心value里的某一部分可以把一个大Context拆成ThemeContext和LocaleContext两个小Context实现分频道广播。这个方案面试官很吃。另外可以对比说Zustand这类基于外部store的方案组件通过订阅器读取数据不经过Context通道所以天然能精准更新。能讲到这一步状态管理这道题基本满分。6. 性能优化从背优化手段到先证明问题出在哪6.1 一段真实经历图表大列表筛选卡顿的排查性能优化这块热词榜上的react 图表react画布说明很多人在React里做可视化时都会遇到性能瓶颈。我自己就踩过一次一个数据大屏左侧筛选器右侧一张几千数据点的图表外加一个长列表。筛选器输入两个字符整个页面卡到掉帧。一开始我本能地去给组件加React.memo给方法包useCallback折腾一小时没好转。后来打开React DevTools Profiler录了一段操作才看到瓶颈根本不是子组件重渲染而是筛选器输入触发的列表过滤是同步大计算把主线程占满了。这里有个反直觉的结论性能问题不一定来自渲染也可能来自计算和事件处理。对应的解法是把过滤计算变成增量或延迟用useMemo缓存过滤结果配合useDeferredValueReact 18让输入框即时响应计算在后台做UI不卡列表再长一点就上虚拟滚动react-window只渲染可视区域的几百行而不是全量几千行。优化完输入丝滑图表也不抖了。6.2 三件套的正确打开方式React.memo、useMemo、useCallback上面那段经历的核心是先定位再优化但该掌握的手段也要掌握。给三件套的正确打开逻辑React.memo包住组件让组件只在props浅比较结果变化时重渲染。解决的是父组件重渲染导致子组件无辜跟着渲染。useMemo缓存计算结果避免重复执行昂贵计算。解决的是渲染函数内部的大计算。useCallback缓存函数引用配合React.memo让子组件不因为函数引用的变化而重渲染。本质是引用稳定性问题。一个组合示例const Chart React.memo(function Chart({ data, onBrush }) { return canvas ref{...} /; }); function Dashboard({ rawData }) { const chartData useMemo(() preprocess(rawData), [rawData]); const handleBrush useCallback((range) { setRange(range); }, []); return Chart data{chartData} onBrush{handleBrush} /; }记住它们解决的是不必要的重渲染和重复计算不是慢的第一次渲染。如果组件本身只渲染一次包memo就是脱裤子放屁。6.3 渲染隔离和虚拟列表提出来就是加分再补两个容易被忽略但很加分的点。第一个是渲染隔离父组件更新了一个跟子组件完全不相关的状态其他子组件也会跟着重新渲染。想避免可以把稳定的子树作为children传下去——children prop是父组件渲染时创建好的React元素它本身不受父组件无关状态变化影响配合React.memo能起到隔离效果。这个技巧面试里提出来面试官一般会眼前一亮。第二个是虚拟列表。渲染几千个DOM节点再怎么优化单个组件的重渲染也只是治标治本是把节点总量降下来。虚拟滚动就是只渲染可视区域加少量缓冲区的节点。做可视化、表格、长列表时这是核心手段配合useMemo效果更佳。6.4 优化前先做的事用Profiler证明最后强调方法论。面试官问你做过哪些性能优化最高级的回答不是罗列手段而是说我有一套定位流程。我的流程是先在React DevTools的Profiler里录制一段真实操作看哪个组件实际渲染耗时高、哪个组件渲染次数异常多再结合代码判断是计算问题还是diff问题最后才动手优化优化完再录一次对比火焰图验证。这条链路本身就是工程能力的体现比背十个优化手段都管用。7. React 18/19新特性并发特性和必须更新的认知7.1 自动批处理setState的合并到底发生在哪React 18带来的第一个颠覆性变化是自动批处理。简单说React 17里只有事件回调内的多次setState会合并成一次渲染Promise回调、setTimeout、原生事件监听器里都不会合并会导致多次渲染。React 18把这些场景全部纳入自动批处理// React 17: setTimeout里两次setState触发两次渲染 setTimeout(() { setA(1); setB(2); }, 0); // React 18: 自动批处理合并成一次渲染 setTimeout(() { setA(1); setB(2); }, 0);面试考这个点其实是在考你是否了解渲染次数和state更新的关系。批处理的本质是把多次state变更合并提交减少不必要的渲染开销。但要注意批处理不代表状态更新会同步生效——setState之后立刻读取state还是旧值因为state的更新要到下一次渲染才反映到组件里。7.2 useTransition与useDeferredValue如何让出主线程React 18的并发特性是面试大热门最常考的是useTransition和useDeferredValue。它们解决同一类问题有一个很重的更新比如过滤一万条数据如果和输入框的更新混在一起输入会卡到飞起。解法是把重的更新标记为低优先级让紧急的输入先响应。const [isPending, startTransition] useTransition(); const [keyword, setKeyword] useState(); function handleChange(e) { setKeyword(e.target.value); // 紧急输入框要立即响应 startTransition(() { setFiltered(filterData(e.target.value)); // 低优先级慢慢算 }); }useDeferredValue则是一个更轻的版本不需要手动包transition只要把一个值包起来React会自动延迟这个值对应的低优先级更新。一句话向面试官总结并发特性让React可以把渲染切成多个优先级把不紧急的工作延后保证最核心的交互不卡顿。这个思想已经超出了生命周期和diff算法是现在面试里最能拉开代差的知识点。7.3 React 19的新东西Actions、use Hook与编译器React 19虽然刚出不久但已经开始进面试题了。重点有三个一是Actions表单处理被内建到框架里。form action{handleAction}配合useActionState可以拿到表单提交的pending状态、返回值和错误不用再手动管理loading和error。这个设计把异步动作和状态绑定成一体面试时能主动提出来说明你在跟进上游更新。二是use这个Hook它可以在渲染阶段直接读取Promise或Context配合Suspense处理数据获取让直接在组件里等数据成为可能。注意use是可以被条件调用的打破了之前Hooks必须无条件调用的规则算是一个概念突破。三是React Compiler它会在编译期自动做useMemo、useCallback、React.memo的优化开发者不再需要手动加记忆化。这意味着很多手写的useMemo将来可以删掉。如果面试官问你怎么看React Compiler比较好的切入点是自动记忆化的前提是组件符合不可变数据和纯函数规则所以深入了解渲染机制反而更重要了。8. 一次React Native启动白屏的排查复盘热词榜上的react native 启动白屏是个真问题我自己就踩过一次。虽然这篇文章主线是面试但这类实战案例现在面试里出现得越来越频繁——把线上问题的定位过程讲清楚比背十道题都管用。8.1 现象冷启动白屏三秒热更新后消失背景是老项目从裸RN升级到新架构某次发版后测试反馈iOS冷启动进App第一屏要白两三秒才出来热更新之后大概率恢复正常。白屏期间没有任何报错导航路由也没崩就是干等。这个热更新后消失的细节很关键——它说明问题不在原生层更像JS侧执行时间不稳定热更新时代码已加载过表现不明显。这类问题看起来无从下手其实是标准的首帧时间问题。白屏的实质就是JS bundle还没跑完首帧视图没有被渲染出来原生容器背景是白的这段时间就对着你摊着一块白板。8.2 排查链路从日志、二分法到真凶当时我的排查顺序是这样的指标先行在App启动路径上埋console.time和性能点确认白屏期间JS线程在干嘛。耗时大头既不是bundle下载也不是原生初始化而是注册根组件之前的一串同步代码。二分法注释把App入口处按功能模块注释掉一组一组测试启动耗时。先后排除掉网络请求、数据库初始化、埋点SDK最后命中了一个从本地存储同步读取用户偏好并初始化主题模块的代码它内部还同步拼了一个大型配置对象。复现与验证在真机Profile JS线程发现这段代码同步占用了主线程将近两秒。两秒对用户体验来说已经是不可接受的白屏。真凶找到了根组件渲染前有一段重而不可中断的同步逻辑它把启动时需要的东西全部串行做完才交出渲染权。低端机上还要更严重因为同步操作吃CPU更慢。8.3 根因解释为什么数据准备好了再渲染是反模式很多人写启动逻辑有一个执念我要等数据都准备好了再渲染第一屏这样用户看到的就是完整页面。这个执念在Web上尚可容忍有loading态但在RN里直接变成了白色裸屏。正确的思路是先渲染壳再填数据再补充初始化首帧只渲染最必要的骨架或空容器让视图尽快出现在屏幕上同步读取本地存储这类操作挪到原生层预取或者改异步并在随后分发事件导航容器要在根视图挂载完、SplashScreen隐藏之前准备好。白屏另一个常见兄弟问题是SplashScreen隐藏得太早视图还没就绪逻辑一模一样。8.4 修复合集与通用方法论那次修复做了三件事把同步读存储拼配置重构成异步并延后到首帧之后执行初始化结果通过React Context逐层下发而不是在入口处阻塞等待SplashScreen的隐藏时机从App启动改为首帧onLayout回调触发。改完冷启动白屏消失首屏可交互时间快了接近一倍。这个case沉淀出的通用方法论是遇到任何启动白屏白屏一闪不要急着怀疑某个具体库先问三个问题——JS线程在首帧前做了什么首帧视图是什么时候提交的Splash要隐藏的时刻和首帧就绪的时刻是不是对齐的把这三个问题查清楚90%的白屏问题都能定位。面试中讲出这套排查框架比说出我遇到过白屏然后改了xxx有说服力得多。9. 高频追问串烧被反复追问的小问题9.1 函数组件和类组件你到底站哪边几乎每次面试都有这个问题。我的立场很明确新代码一律函数组件Hooks老代码理解类组件生命周期以便维护。函数组件的优势在于心智模型统一到渲染state的函数副作用由Hooks显式声明没有this绑定问题也没有生命周期函数把逻辑拆得七零八落。类组件的优势在于有实例可以存任意数据、getSnapshotBeforeUpdate这类生命周期在某些场景仍不可替代错误边界目前也必须用类组件写。回答这个问题的加分点是承认工具各有适用场景而不是无脑站队。9.2 key到底能不能用数组下标第3节讲过diff策略这里补充面试现场的完整回答句式如果列表是静态的、不增删不排序index勉强能用但只要涉及插入、删除、重排用index会导致节点复用错位、组件state错乱。正规做法永远是用业务稳定id实在没有id再考虑生成唯一key。注意静态列表可以用index这个前提很重要能体现你思考的颗粒度而不是一刀切。9.3 错误边界为什么只有类组件能写React的错误边界ErrorBoundary目前只能用类组件实现因为要依靠componentDidCatch或getDerivedStateFromError这两个生命周期方法函数组件即便用Hooks也没有对应的原生机制。实务上通常封装一个ErrorBoundary类组件再用包裹方式复用。面试里顺带提一句React团队有计划让函数组件也能更方便地捕获错误但现阶段还是类组件方案会显得信息很新。9.4 受控组件与非受控组件的边界还有一道高频基础题受控组件就是value由React state完全掌控每次用户输入都走setState然后再回流到input非受控组件则是让DOM自己保存状态React只在需要时通过ref读取。大多数场景推荐受控因为数据源单一、便于校验和联动但某些场景文件上传、偶尔读取一次的input非受控更省事。能说出受控是把DOM状态提升到React state非控是把状态留在DOM这个本质这道题就过了。9.5 面试最后30秒的加分动作说个很实用的经验答完技术问题后通常还有几十秒收尾时间。不要干坐着等对方问你有什么想问的可以主动补一句我刚才提到React 19的Actions和Compiler如果你团队正在做技术升级我可以聊聊实践中的边界情况。这句话的潜台词是我不只会背知识点我能把知识挂到真实工程的决策树上。这个动作比多说十个API都有效。最后说点真心话。我面了这么多候选人最大的感受是能背对知识的人很多能把知识连成决策链的人很少。面试题会变框架会升级但渲染模型——状态来源——更新成本这条主线不会过时。你可以在业余时间做一个小项目强制自己不用任何状态管理库、不用脚手架从零搭一个React应用然后在DevTools里观察每一次setState引起的渲染链路你会发现那些面试题突然都有了意义。祝各位都能拿到心仪的offer也欢迎有同道中人一起交流最近遇到的React新面试题。