React 核心原理与高级特性
-
面试官问题示例： “请深入解释一下React Fiber架构解决了什么问题？它是如何实现并发模式的？”
-
回答框架：
-
背景问题： “在Fiber架构之前，React的Reconciler（协调器）采用的是递归算法，一旦开始更新，就会一口气执行到底，无法中断。这在大型应用或复杂更新时，容易导致主线程长时间被占用，造成页面卡顿、用户输入无响应（Jank）的问题，用户体验受损。”
-
Fiber 的引入与解决的问题： “Fiber架构的引入，将原来同步的递归更新过程，改造成了异步可中断的更新。它将Reconciliation过程拆分成多个小单元（Fiber） ，每个Fiber代表一个工作单元。这样，React可以在每次处理完一个或一批Fiber后，将控制权交还给浏览器，让浏览器有机会处理更高优先级的任务（如用户输入、动画），避免了长时间阻塞主线程。”
-
实现并发模式的原理：
- 可中断性与优先级： “Fiber的核心就是实现了任务的可中断、可恢复和优先级调度。React会根据任务的优先级（如用户输入优先级最高，数据请求次之，非必要渲染优先级最低）来调度Fiber的执行。高优先级的任务可以打断低优先级的任务。”
- 双缓冲机制： “Fiber内部采用双缓冲（Double Buffering）机制。在更新过程中，React会在内存中构建一颗新的Fiber Tree（work-in-progress tree），所有计算和变更都在这棵树上进行。只有当这棵新树完全构建并准备就绪后，才会一次性地切换到屏幕上（commit阶段），确保了UI更新的原子性，避免了中间状态的闪烁。”
- 调度器 (Scheduler)： “React内部有一个独立的Scheduler模块，它利用
requestIdleCallback（或者更底层的机制）来调度Fiber的执行，确保在浏览器空闲时执行低优先级任务，在必要时（如用户交互）立即执行高优先级任务。”
-
总结： “所以，Fiber架构的核心目标是提高用户体验，通过可中断的异步更新和优先级调度，实现了并发模式，让React应用在复杂场景下也能保持流畅和响应。”
-
-
-
面试官问题示例： “你如何理解
useEffect的依赖项？当依赖项为空数组时，会发生什么？为什么会出现闭包陷阱？”-
回答框架：
useEffect依赖项的理解： “useEffect的第二个参数是一个依赖项数组，它告诉React这个effect应该在哪些依赖值发生变化时才重新执行。React会进行浅比较，如果依赖项中的任何一个值与上次渲染时的值不同，effect就会重新运行。如果省略依赖项数组，effect会在每次渲染后都执行；如果传入空数组[]，则表示这个effect只会在组件挂载时执行一次，并在组件卸载时执行清理函数（如果有的话） 。”- 依赖项为空数组
[]： “当依赖项为空数组时，useEffect的行为类似于类组件的componentDidMount和componentWillUnmount（如果返回清理函数）。这意味着effect内部的代码只在组件首次渲染后运行一次，并且它的闭包会捕获到首次渲染时的状态和props。后续组件的重渲染不会触发这个effect的重新执行。” - 闭包陷阱： “闭包陷阱的发生，是因为JavaScript的闭包特性。当
useEffect的依赖项为空数组时，effect函数形成了一个闭包，它会‘记住’创建时作用域中的变量值。如果effect内部使用了组件的状态（useState）或属性（props），而这些状态或属性在后续渲染中发生了变化，但effect没有被重新执行（因为它依赖项为空），那么effect内部访问到的仍然是旧的、过时的值。这就造成了数据不一致或逻辑错误。” - 举例说明 (可简述)： “例如，一个按钮点击后，
useEffect里要记录一个count值。如果count是组件状态，useEffect依赖项是[]，那么每次点击后，useEffect里拿到的count始终是初始值0，因为闭包捕获的是0。” - 如何避免： “避免闭包陷阱的关键在于，确保
useEffect的依赖项数组是完整且正确的。凡是在effect内部使用到的、且可能在组件生命周期内发生变化的状态、props、函数等，都应该被列入依赖项。如果函数需要稳定，可以使用useCallback和useMemo来优化。”
-
“你在项目中遇到过哪些性能瓶颈？是如何定位和解决的？请举例说明。”
在使用实时数据渲染时，由于推送过快，可能导致，页面渲染不及时，导致数据丢失，先查看服务推送情况，然后检查network ，这个数据的推送情况，然后分析导致的原因，然后进行优化，由于需要需要严格顺序 优化的手段
1.任务队列，但由于渲染问题，可能导致不及时， 2.定时聚合渲染，800ms渲染一次
页面首屏加载慢。
- 问题： “项目首次加载JS包体积过大，首屏白屏时间较长。”
- 分析： “通过
Network和Webpack Bundle Analyzer分析，发现打包文件中包含了大量非首屏必需的代码和重复的库。” - 解决方案： “实施了代码分割（Code Splitting） ，利用
React.lazy和Suspense实现路由懒加载。将不常用的库独立打包，并利用Webpack的splitChunks优化公共模块。同时，对图片进行WebP格式转换和尺寸压缩，并启用Gzip压缩服务器响应。” - 结果： “首屏加载时间从X秒缩短到Y秒，LCP指标显著改善，用户体验明显提升。”
