1.React源码分析4-深度理解diff算法
2.React Fiber原理？
3.搞懂React源码系列-React Diff原理
4.React v16.0 新特性探究
5.react源码解析（二）时间管理大师fiber
6.万字长文介绍React Fiber架构的原理和工作模式

React源码分析4-深度理解diff算法

       React 每次更新，都会通过 render 阶段中的 reconcileChildren 函数进行 diff 过程。这个过程是 React 名声远播的优化技术，对新的 ReactElement 内容与旧的 fiber 树进行对比，从而构建新的 fiber 树，将差异点放入更新队列，av福利源码对真实 DOM 进行渲染。简单来说，diff 算法是为了以最低代价将旧的 fiber 树转换为新的 fiber 树。

       经典的 diff 算法在处理树结构转换时的时间复杂度为 O(n^3)，其中 n 是树中节点的个数。在处理包含 个节点的应用时，这种算法的性能将变得不可接受，需要进行优化。React 通过一系列策略，将 diff 算法的时间复杂度优化到了 O(n)，实现了高效的更新 virtual DOM。

       React 的 diff 算法优化主要基于以下三个策略：tree diff、component diff 和 element diff。tree diff 策略采用深度优先遍历，仅比较同一层级的元素。当元素跨层级移动时，React 会将它们视为独立的更新，而不是直接合并。

       component diff 策略判断组件类型是否一致，不一致则直接替换整个节点。这虽然在某些情况下可能牺牲一些性能，但考虑到实际应用中类型不一致且内容完全一致的情况较少，这种做法有助于简化 diff 算法，保持平均性能。

       element diff 策略通过 key 对元素进行比较，识别稳定的渲染元素。对于同层级元素的比较，存在插入、删除和移动三种操作。这种策略能够有效管理 DOM 更新，确保性能。

       结合源码的 diff 整体流程从 reconcileChildren 函数开始，根据当前 fiber 的存在与否决定是直接渲染新的 ReactElement 内容还是与当前 fiber 进行 Diff。主要关注的函数是 reconcileChildFibers，其中的细节与具体参数的处理方式紧密相关。不同类型的 ReactElement（如 REACT_ELEMENT_TYPE、纯文本类型和数组类型）将走不同的 diff 流程，实现更高效、针对性的处理。

       diff 流程结束后，形成新的 fiber 链表树，链表树上的 fiber 标记了插入、删除、更新等副作用。在完成 unitWork 阶段后，React 构建了一个 effectList 链表，记录了需要进行真实 DOM 更新的 fiber。在 commit 阶段，根据 effectList 进行真实的 DOM 更新。下一章将深入探讨 commit 阶段的详细内容。

React Fiber原理？

       Fiber的特点/作用

       Fiber能够使得动画、布局和页面交互变得更加的流畅。

       一：Fiber的概念

         React Fiber是react执行渲染时的一种新的调度策略，JavaScript是单线程的，一旦组件开始更新，主线程就一直被React控制，这个时候如果再次执行交互操作，就会卡顿。

         React Fiber就是通过对象记录组件上需要做或者已经完成的更新，一个组件可以对应多个Fiber。

         在render函数中创建的React Element树在第一次渲染的时候会创建一颗结构一模一样的的Fiber节点树。不同的React Element类型对应不同的Fiber节点类型。一个React Element的伪静态 htaccess 源码工作就由它对应的Fiber节点来负责。

         一个React Element可以对应不止一个Fiber，因为Fiber在update的时候，会从原来的Fiber(我们称为current)clone出一个新的Fiber(我们称之为alternate)。俩个Fiber diff出的变化(side effect)记录在alternate上。所以一个组件在更新时最多会有俩个Fiber与其对应，在更新结束后alternate会取代之前的current称为新的current节点。

         React Fiber重构这种方式，渲染过程采用切片的方式，每执行一会儿，就歇一会儿。如果有优先级更高的任务到来以后呢，就会先去执行，降低页面发生卡顿的可能性，使得React对动画等实时性要求较高的场景体验更好。

       二：什么是Fiber？

         当js在处理大型计算的时候会导致页面出现卡帧的现象，更严重的会出现页面“假死”。所以在这些情况下，必然会导致动画丢帧、不连贯，用户体验就特别差。为了解决这个问题，我们可以将大型的计算拆分成一个个小型计算，然后按照执行顺序异步调用，这样就不会长时间霸占线程，UI也能在俩次小型计算的执行间隙进行更新，从而给与用户及时的反馈，Fiber就是这样做的，并且以一种更高逼格的方式实现了。

       Driving Idea

         如果说v.0之前的React解决了HOW(如何用最少的DOM操作成本来update视图)的问题，那么这一次Fiber的出现，在这个基础上还解决了WHEN(何时update视图的哪一部分)的问题。

          分片优先级！！！

         基于上述这些原因，Fiber实现了一个虚拟调用栈，并给所有的update进行优先级排序，如下：

       'use strict';

       export type PriorityLevel = 0 | 1 | 2 | 3 | 4 | 5;

       module.exports = {

       NoWork: 0, // No work is pending.

       SynchronousPriority: 1, // 用于控制文本输入。同步的副作用.

       AnimationPriority: 2, //需要在下一帧之前完成.

       HighPriority: 3, // 需要很快完成的互动才能产生反应.

       LowPriority: 4, // 数据获取，或更新存储的结果.

       OffscreenPriority: 5, // 将不可见，但做的工作，以防它成为可见.

       };

         然后根据这些update的优先级，来决定执行的顺序。

         我们可以看到动画和页面交互都是优先级比较高的，这也是Fiber能够使得动画、布局和页面交互变得更加的流畅的原因之一。

         可以把Priority分为同步和异步两个类别，同步优先级的任务会在当前帧完成，包括SynchronousPriority和TaskPriority。异步优先级的任务则可能在接下来的几个帧中被完成，包括HighPriority、LowPriority以及OffscreenPriority。

         React v.3.2的优先级，不再这么划分，分为三类：NoWork、sync、async，前两类可以认为是同步任务，需要在当前tick完成，过期时间为null，最后一类异步任务会计算一个。

         expirationTime，在workLoop中，根据过期时间来判断是否进行下一个分片任务，scheduleWork中更新任务优先级，也就是更新这个expirationTime。至于这个时间怎么计算，可以查看源码。麒麟影音 源码 kylin

       三：Fiber的基本原则：

         更新任务分成俩个阶段，Reconcilition Phase(调和阶段)和Commit Phase(交付阶段)。Reconciliation Phase的任务干的事情是，找出要做的更新工作(Diff Fiber Tree),就是一个计算阶段，计算结果可以被缓存，也就可以被打断；Commit Phase需要提交所有更新并渲染，为了防止页面抖动，被设置为不能打断。

         PS：componentWillMount

         omponentWillReceiveProps componentWillUpdate 几个生命周期方法，在Reconciliation Phase被调用，有被打断的可能（时间用尽等情况），所以可能被多次调用。其实shouldComponentUpdate 也可能被多次调用，只是它只返回true或者false，没有副作用，可以暂时忽略。

       四：Fiber的数据结构

         fiber是个链表，有child和sibing属性，指向第一个子节点和相邻的兄弟节点，从而构成fiber tree。return 属性指向其父节点。

         更新队列，updateQueue，是一个链表，有first和last俩个属性，指向第一个和最后一个update对象。

         每个fiber有一个属性updateQueue指向其对应的更新队列。

         每个fiber(当前fiber可以称为current)有一个属性alternate，开始时指向一个自己的clone体，update的变化会先更新到alternate上，当更新完毕，alternate替换current。

       五：Fiber的执行流程

       用户操作引起setState被调用以后，先调用enqueueSetState方法，该方法可以划分成俩个阶段（个人理解），第一阶段Data Preparation，是初始化一些数据结构，比如fiber，updateQueue，update。

       新的update会通过insertUpdateIntoQueue方法，根据优先级插入到队列的对应位置，ensureUpdateQueues方法初始化俩个更新队列，queue1和current.updateQueue对应，queue2和current.alternate.updateQueue对应。

       第二阶段，Fiber Reconciler，就开始进行任务分片调度，scheduleWork首先更新每个fiber的优先级，这里并没有updatePriority这个方法，但是干了这件事。当fiber.return === null，找到父节点，把所有diff出的变化(side effect)归结到root上。

       requestWork，首先把当前的更新添加到schedule list中(addRootToSchedule),然后根据当前是否为异步渲染(isAsync参数)，异步渲染调用。scheduleCallbackWithExpriation方法，下一步高能！！

       scheduleCallbackWithExpriation这个方法在不同环境，实现不一样，chrome等浏览器中使用requestIdleCallback API，没有这个API的浏览器中，通过requestAnimationFrame模拟一个requestIdCallback，来在浏览器空闲时，完成下一个分片的工作，注意，麦商联盟 源码这个函数会传入一个expirationTime，超过这个时间活没干完，就放弃了。

       执行到performWorkOnRoot，就是fiber文档中提到的Commit Phase和Reconciliation Phase俩阶段。

       第一阶段Reconciliation Phase,在workLoop中，通过一个while循环，完成每个分片任务。

       performUnitOfWork也可以分成俩阶段，蓝色框表示。beginWork是一个入口函数，根据workInProgress的类型去实例化不同的react element class。workInProgress是通过alternate挂载一些新属性获得的。

       实例化不同的react element class时候会调用和will有关的生命周期方法。

       completeUnitOfWork是进行一些收尾工作，diff完一个节点以后，更新props和调用生命周期方法等。

       然后进入Commit Phase阶段，这个阶段不能被打断。

       六：Fiber对开发者有什么影响？

       componentWillMount,componentWillReceiveProps,componentWillUpdate几个生命周期方法不再安全，由于任务执行过程可以被打断，这几个生命周期可能会执行多次，如果它们包含副作用(比如Ajax)，会有意想不到的bug。React团队提供了替换的生命周期方法。建议如果使用以上方法，尽量使用纯函数，避免以后踩坑。

       需要关注react为任务片设置的优先级，特别是页面用动画的情况。

       如果一直有更高的级别任务，那么fiber算法会先执行级别更高的任务，执行完毕后再通过callback回到之前渲染到一半的组件，从头开始渲染。（看起来放弃已经渲染完的生命周期，会有点不合理，反而会增加渲染时长，但是react确实是这么干的）

搞懂React源码系列-React Diff原理

       时隔2年，重新审视React源码，理解了许多过去未曾明晰的内容。本文聚焦于通过实际案例结合相关React源码，集中探讨React Diff原理。我们将使用当前最新React版本：..1。

       同时，今年计划推出“搞懂React源码系列”，旨在以通俗易懂的方式深入解析React的核心部分。年，该系列将涵盖以下内容：

       React Diff原理

       React 调度原理

       搭建阅读React源码环境-支持所有版本断点调试

       React Hooks原理

       欢迎关注我的博客。

       在深入Diff算法之前，有必要先理解React Fiber。虽然Fiber并不复杂，但全面理解需要时间。本文重点是Diff原理，因此Fiber介绍将简要进行。

       Fiber是React中的抽象节点对象，它将所有节点连接成链表树。每个Fiber可能包含子Fiber、相邻Fiber以及父Fiber。React使用链表形式连接所有Fiber，形成树结构。Fiber还带有副作用标签（effectTag），如替换（Placement）和删除（Deletion），用于后续更新DOM。

       值得注意的是，React Diff过程中，除了Fiber，还涉及基本的React元素对象，如将foo编译后的qq2017源码对象为：{ type: 'div', props: { children: 'foo' } }。

       Diff过程始于reconcileChildren(...)

       总流程如下：

       reconcileChildren(...)

       在Diff时，比较中的旧内容为Fiber，而新内容为React元素、文本或数组。新内容为对象时，流程分为两步：reconcileSingleElement(...)和placeSingleChild(...)。

       以React元素为例，流程如下：

       reconcileSingleElement(...)

       这里正式开始Diff，child为旧内容Fiber，element为新内容，它们的元素类型不同。

       React将“删除”旧内容Fiber及其所有相邻Fiber（添加Deletion标签），并基于新内容生成新的Fiber。然后将新Fiber设置为父Fiber的child。

       如果新旧内容的元素类型相同，则通过fiber复用生成新的Fiber。同样设置为父Fiber的child。

       总结新内容为React元素的Diff流程：

       reconcileChildren(...)

       新内容为文本时，逻辑与新内容为React元素类似。

       新内容为数组时，通过遍历数组元素，与React元素的处理方式类似，生成新的Fiber。

       总结新内容为数组的Diff流程：

       reconcileChildrenArray(...)

       Diff的三种情况总结：

       比较结果相同：复用旧内容Fiber，结合新内容生成新Fiber

       比较结果不同：仅通过新内容创建新Fiber

       然后给旧内容Fiber添加替换标签，或给旧内容Fiber及其所有相邻元素添加删除标签。最后将新的（第一个）Fiber设为父Fiber的child。

React v.0 新特性探究

       Facebook在经历了一场关于证书争议后，迅速推出了React v.0的新版，这次更新包含了许多重大变革，如底层源码重构和新核心算法Fiber的引入。Fiber不仅优化了渲染性能，还改变了组件的渲染方式，提升了框架的响应能力。下面来深入解析这些新特性。

       早在年，Facebook就开始研发名为Fiber的新底层算法，经过两年多的努力，Fiber在v.0中成为核心。Fiber是React框架的基石，它革新了渲染和任务调度，使得在适当的时间处理适当的任务，显著提升了复杂SPA的渲染速度，通过任务优先级制度实现了更流畅的用户体验。新算法允许异步渲染，但默认并未开启，这意味着应用程序能更快响应交互。

       Fiber的工作原理基于组件的执行单元，通过虚拟堆栈结构，它允许开发者定制渲染过程，避免了旧的Stack Reconciler中可能导致的阻塞主线程问题。新算法将组件更新过程切割为短帧，每个帧执行一小部分任务，确保主线程在必要时切换至优先级更高的任务，提高了响应速度。

       在v.0中，`render()`函数的灵活性增强，不再仅限于返回完整的DOM，支持返回简单字符、数组甚至数字。这种改变减少了不必要的DOM结构，提高了性能和代码的简洁性。

       错误处理机制也得到了显著提升，当组件内部发生渲染错误时，React会以更灵活的方式处理，只渲染错误组件的子树，而不是整个应用停止。此外，新引入的Error Boundaries功能，类似于JavaScript的try-catch，可以在组件树中捕获并处理错误，保证应用的健壮性。

       Portals组件允许将内容渲染到DOM结构之外，解决了提示框等组件复用和样式管理的问题，提供了更优雅的代码结构。此外，服务端渲染得到了重大改进，支持Node Stream传输，使得内容传输更高效，响应速度更快。

       React v.0的发布，不仅在性能和用户体验上有所提升，还引入了自定义DOM标签支持，让开发更加灵活。同时，setState()函数的优化减少了不必要的渲染，而更小的体积和Rollup的使用则为项目维护带来了便利。

       尽管如此，这次更新对一些依赖旧版特性的项目可能带来迁移的挑战，但整体来看，React v.0带来了显著的进步和改进。

react源码解析（二）时间管理大师fiber

       React的渲染和对比流程在面对大规模节点时，会消耗大量资源，影响用户体验。为了改进这一情况，React引入了Fiber机制，成为时间管理大师，平衡了浏览器任务和用户交互的响应速度。

       Fiber的中文翻译为纤程，是一种内部更新机制，支持不同优先级的任务管理，具备中断与恢复功能。每个任务对应于React Element的Fiber节点。Fiber允许在每一帧绘制时间（约.7ms）内，合理分配计算资源，优化性能。

       相比于React，React引入了Scheduler调度器。当浏览器空闲时，Scheduler会决定是否执行任务。Fiber数据结构具备时间分片和暂停特性，更新流程从递归转变为可中断的循环，通过shouldYield判断剩余时间，灵活调整更新节奏。

       Scheduler的关键实现是requestIdleCallback API，它用于高效地处理碎片化时间，提高用户体验。尽管部分浏览器已支持该API，React仍提供了requestIdleCallback polyfill，以确保跨浏览器兼容性。

       在Fiber结构中，每个节点包含返回指针（而非直接的父级指针），这个设计使得子节点完成工作后能返回给父级节点。这种机制促进了任务的高效执行。

       Fiber的遍历遵循深度优先原则，类似王朝继承制度，确保每一帧内合理分配资源。通过实现深度优先遍历算法，可以构建Fiber树结构，用于渲染和更新DOM元素。

       为了深入了解Fiber，可以使用本地环境调试源码。通过创建React项目并配置调试环境，可以观察Fiber节点的结构和行为。了解Fiber的遍历流程和结构后，可以继续实现一个简单的Fiber实例，这有助于理解React渲染机制的核心。

       Fiber架构是React的核心，通过时间管理机制优化了性能，使React能够在大规模渲染时保持流畅。了解Fiber的交互流程和遍历机制，有助于深入理解React渲染流程。未来，将详细分析优先级机制、断点续传和任务收集等关键功能，揭示React是如何高效地对比和更新DOM树的。

       更多深入学习资源和讨论可参考以下链接：

       《React技术揭秘》

       《完全理解React Fiber》

       《浅谈 React Fiber》

       《React Fiber 源码解析》

       《走进 React Fiber 的世界》

万字长文介绍React Fiber架构的原理和工作模式

       我花费了5天时间深入研究Fiber的核心源码，尽管本文篇幅超过万字，但对于数十万行的Fiber源码来说，仅能算是对其基础知识的一个简要介绍。若文中存在疏漏，欢迎在评论区指出，我将及时更新。若您对Fiber有特定的专题想了解，也欢迎在评论区提出，我很乐意继续深入研究源码并分享知识。

       自React 版本开始，React引入了Fiber架构，旨在解决之前更新机制存在的问题。在长时间更新过程中，主线程可能会被阻塞，导致应用无法及时响应用户输入。本文将探讨Fiber的底层原理及其工作模式，让您对Fiber架构有一个清晰的认识。

       本文首发于我的博客「J实验室」。

       欢迎加入「独立全栈开发交流群」，共同学习交流前端和Node端技术。

       首先，我们来了解一下React的基本组成：当编写React组件并使用JSX时，React在底层会将JSX转换为元素的对象结构。例如：

       上述代码会被转换为以下形式：

       为了将这个元素渲染到DOM上，React需要创建一种内部实例，用来追踪该组件的所有信息和状态。在早期版本的React中，我们称之为“实例”或“虚拟DOM对象”。但在Fiber架构中，这个新的工作单元就叫做Fiber。

       在本质上，Fiber是一个JavaScript对象，代表React的一个工作单元，它包含了与组件相关的信息。一个简化的Fiber对象长这样：

       当React开始工作时，它会沿着Fiber树形结构进行，试图完成每个Fiber的工作（例如，比较新旧props，确定是否需要更新组件等）。如果主线程有更重要的工作（例如，响应用户输入），则React可以中断当前工作并返回执行主线程上的任务。

       因此，Fiber不仅仅是代表组件的一个内部对象，它还是React的调度和更新机制的核心组成部分。

       在React 之前的版本中，使用递归的方式处理组件树更新，称为堆栈调和（Stack Reconciliation）。这种方法一旦开始就不能中断，直到整个组件树都被遍历完。这种机制在处理大量数据或复杂视图时可能导致主线程被阻塞，从而使应用无法及时响应用户的输入或其他高优先级任务。

       Fiber的引入改变了这一情况。Fiber可以理解为是React自定义的一个带有链接关系的DOM树，每个Fiber都代表了一个工作单元，React可以在处理任何Fiber之前判断是否有足够的时间完成该工作，并在必要时中断和恢复工作。

       现在，我们来了解一下FiberNode的结构：

       其实可以理解为是一个更强大的虚拟DOM。

       Fiber工作原理中最核心的点就是：可以中断和恢复，这个特性增强了React的并发性和响应性。

       实现可中断和恢复的原因就在于：Fiber的数据结构里提供的信息让React可以追踪工作进度、管理调度和同步更新到DOM。

       了解了Fiber的工作原理后，我们可以通过阅读源码来加深对Fiber的理解。React Fiber的工作流程主要分为两个阶段：

       第一阶段：Reconciliation（调和）

       调和阶段又分为三个小阶段：

       1、创建与标记更新节点：beginWork

       2、收集副作用列表：completeUnitOfWork和completeWork

       调和阶段知识拓展

       1、为什么Fiber架构更快？

       2、调和过程可中断

       第二阶段：Commit（提交）

       源码里commitRoot和commitRootImpl是提交阶段的入口方法，在两个方法中，可以看出来提交阶段也有三个核心小阶段，我们一一讲解：

       1、遍历副作用列表：BeforeMutation

       2、正式提交：CommitMutation

       3、处理layout effects：commitLayout

       从源码里我们可以看到，一旦进入提交阶段后，React是无法中断的。

       以上内容虽无法覆盖Fiber的方方面面，但可以确保你学完后对Fiber会有一个整体上的认识，并且让你在以后阅读互联网上其它关于Fiber架构的文章时，不再因为基础知识困惑，而是能够根据已有的思路轻松地拓展你大脑里关于Fiber架构的知识网。

       欢迎加入「独立全栈开发交流群」，共同学习交流前端和Node端技术。

React设计原理，由浅入深解析 react 源码（一）

       React设计原理详解：深入理解React 源码（一）

       React的核心工具之一是jsx，它是一种语法扩展，开发者编写的代码会被Babel编译成ReactElement，进一步转化为FiberNode，这是一种虚拟DOM在React中的实现，它能表达组件状态和节点关系，同时具备可扩展性。

       FiberNode的工作方式采用深度优先遍历(DFS)策略，递归地处理ReactElement。在渲染过程中，递归分为beginWork（开始工作）和completeWork（完成工作）两个阶段。在ReactDOM的createRoot和render方法中，scheduleUpdateOnFiber和processUpdateQueue负责更新和创建子fiber节点。

       在commit阶段，关键步骤包括执行root上的mutation，以及对Host类型的FiberNode构建离屏DOM树。ChildReconciler的两个关键点是子ReactElement到子fiber的创建方式和flag标识的设置。最后，学习者需要注意的是，通过阅读本文，可以关注以下三点：

       理解jsx与FiberNode的关系

       掌握React的递归渲染过程和commit阶段的子阶段

       反思和分享你的学习体验，一起探讨React的深入知识

       如果你觉得这篇文章有价值，别忘了在留言区分享你的见解，或者将其推荐给你的朋友。让我们一起深化对React 源码的理解。

放弃 console.log 吧！用 Debugger 你能读懂各种源码

       很多同学不清楚为什么要使用debugger进行调试，难道console.log不行吗？

       即使学会了使用debugger，还是有很多代码看不懂，如何调试复杂的源码呢？

       这篇文章将为你讲解为什么要使用这些调试工具：console.log vs Debugger。

       相信绝大多数同学都会使用console.log进行调试，将想查看的变量值打印在控制台。

       这种方法可以满足基本需求，但遇到对象打印时就无法胜任了。

       比如，我想查看webpack源码中的compilation对象的值，我尝试打印了一下：

       但你会发现，当对象的值也是对象时，它不会展开，而是打印一个[Object] [Array]这样的字符串。

       更严重的是，打印的内容过长会超过缓冲区的大小，在terminal中显示不全：

       而使用debugger来运行，在这里设置一个断点查看，就没有这些问题了：

       有些同学可能会说，那打印一个简单的值时使用console.log还是很方便的。

       比如这样：

       真的吗？

       那还不如使用logpoint：

       代码执行到这里就会打印：

       而且没有污染代码，使用console.log的话，调试完成后这个console也不得不删除掉。

       而logpoint不需要，它就是一个断点的设置，不在代码中。

       当然，最重要的是debugger调试可以看到调用栈和作用域！

       首先是调用栈，它就是代码的执行路线。

       比如这个App的函数组件，你可以看到渲染这个函数组件会经历workLoop、beginWork、renderWithHooks等流程：

       你可以点击调用栈的每一帧，查看都执行了什么逻辑，用到了什么数据。比如可以看到这个函数组件的fiber节点：

       再就是作用域，点击每一个栈帧就可以看到每个函数的作用域中的变量：

       使用debugger可以看到代码的执行路径，每一步的作用域信息。而你使用console.log呢？

       只能看到那个变量的值而已。

       得到的信息量差距不是一点半点，调试时间长了，别人会对代码的运行流程越来越清晰，而你使用console.log呢？还是老样子，因为你看不到代码执行路径。

       所以，不管是调试库的源码还是业务代码，不管是调试Node.js还是网页，都推荐使用debugger打断点，别再用console.log了，即使想打印日志，也可以使用LogPoint。

       而且在排查问题的时候，使用debugger的话可以加一个异常断点，代码跑到抛异常的地方就会断住：

       可以看到调用栈来理清出错前都走了哪些代码，可以通过作用域来看到每一个变量的值。

       有了这些，排查错误就变得轻松多了！

       而你使用console.log呢？

       什么也没有，只能自己猜。

       Performance

       前面说debugger调试可以看到一条代码的执行路径，但是代码的执行路径往往比较曲折。

       比如那个React会对每个fiber节点做处理，每个节点都会调用beginWork。处理完之后又会处理下一个节点，再次调用beginWork：

       就像你走了一条小路，然后回到大路之后又走了另一条小路，使用debugger只能看到当前这条小路的执行路径，看不到其他小路的路径：

       这时候就可以结合Performance工具了，使用Performance工具看到代码执行的全貌，然后用debugger来深入每一条代码执行路径的细节。

       SourceMap

       sourcemap非常重要，因为我们执行的都是编译打包后的代码，基本是不可读的，调试这种代码也没有什么意义，而sourcemap就可以让我们直接调试最初的源码。

       比如vue，关联了sourcemap之后，我们能直接调试ts源码：

       nest.js也是：

       不使用sourcemap的话，想搞懂源码，但你调试的是编译后的代码，怎么读懂呢？

       读懂一行

       前面说的debugger、Performance、SourceMap只是调试代码的工具，那会了调试工具，依然读不懂代码怎么办呢？

       我觉得这是不可能的。

       为什么这么说呢？

       就拿react源码来说：

       switch case能读懂吧。三目运算符能读懂吧。函数调用能读懂吧。

       每一行代码都能读懂，而全部的代码不就是由这一行行代码组成的么？

       加上我们可以单步执行来知道代码执行路径。

       为啥每行代码都能读懂，连起来就读不懂了呢？

       那应该是代码太多了，而你花的时间不够而已。

       先要读懂一行，一个函数，读懂一个小功能的实现流程，慢慢积累，之后了解的越来越多之后，你能读懂的代码就会越多。

       总结

       这篇文章讲了为什么要使用调试工具，如何读懂复杂代码。

       console.log的弊端太多了，大对象打印不全，会超过terminal缓冲区，对象属性不能展开等等，不建议大家使用。即使要打印也可以使用LogPoint。

       使用debugger可以看到调用栈，也就是代码的执行路径，每个栈帧的作用域，可以知道代码从开始运行到现在都经历了什么，而console.log只能知道某个变量的值。

       此外，报错的时候也可以通过异常断点来梳理代码执行路径来排查报错原因。

       但debugger只能看到一条执行路径，可以使用Performance录制代码执行的全流程，然后再结合debugger来深入其中一条路径的执行细节。

       此外，只有调试最初的源码才有意义，不然调试编译后的代码会少很多信息。可以通过SourceMap来关联到源码，不管是Vue、React的源码还是Nest.js、Babel等的源码。

       会了调试之后，就能调试各种代码了，不存在看不懂的源码，因为每一行代码都是基础的语法，都是能看懂的，如果看不懂，只可能是代码太多了，你需要更多的耐心去读一行行代码、一个个函数、理清一个个功能的实现，慢慢积累就好了。

       掌握基于debugger、Performance、SourceMap等调试代码之后，各种网页和Node.js代码都能调试，各种源码都能读懂！