+
+
+
+## mount 阶段
+
+在 mount 流程中，首先会通过 createInstance 创建 FiberNode 所对应的 DOM 元素：
+
+```js
+function createInstance(type, props, rootContainerInstance, hostContext, internalInstanceHandle){
+ //...
+ if(typeof props.children === 'string' || typeof props.chidlren === 'number'){
+ // children 为 string 或者 number 时做一些特殊处理
+ }
+
+ // 创建 DOM 元素
+ const domElement = createElement(type, props, rootContainerInstance, parentNamespace);
+
+ //...
+ return domElement;
+}
+```
+
+接下来会执行 appendAllChildren，该方法的作用是将下一层 DOM 元素插入到通过 createInstance 方法所创建的 DOM 元素中，具体的逻辑如下：
+
+- 从当前的 FiberNode 向下遍历，将遍历到的第一层 DOM 元素类型（HostComponent、HostText）通过 appendChild 方法插入到 parent 末尾
+- 对兄弟 FiberNode 执行步骤 1
+- 如果没有兄弟 FiberNode，则对父 FiberNode 的兄弟执行步骤 1
+- 当遍历流程回到最初执行步骤 1 所在层或者 parent 所在层时终止
+
+相关的代码如下：
+
+```js
+appendAllChildren = function(parent, workInProgress, ...){
+ let node = workInProgress.child;
+
+ while(node !== null){
+ // 步骤 1，向下遍历，对第一层 DOM 元素执行 appendChild
+ if(node.tag === HostComponent || node.tag === HostText){
+ // 对 HostComponent、HostText 执行 appendChild
+ appendInitialChild(parent, node.stateNode);
+ } else if(node.child !== null) {
+ // 继续向下遍历，直到找到第一层 DOM 元素类型
+ node.child.return = node;
+ node = node.child;
+ continue;
+ }
+ // 终止情况 1: 遍历到 parent 对应的 FiberNode
+ if(node === workInProgress) {
+ return;
+ }
+ // 如果没有兄弟 FiberNode，则向父 FiberNode 遍历
+ while(node.sibling === null){
+ // 终止情况 2: 回到最初执行步骤 1 所在层
+ if(node.return === null || node.return === workInProgress) {
+ return;
+ }
+ node = node.return
+ }
+ // 对兄弟 FiberNode 执行步骤 1
+ node.sibling.return = node.return;
+ node = node.sibling;
+ }
+}
+```
+
+appendAllChildren 方法实际上就是在处理下一级的 DOM 元素，而且在 appendAllChildren 里面的遍历过程会更复杂一些，会多一些判断，因为 FiberNode 最终形成的 FiberTree 的层次和最终 DOMTree 的层次可能是有区别：
+
+```jsx
+function World(){
+ return 
+
+每个阶段，又分为三个子阶段：
+
+- commitXXXEffects
+- commitXXXEffects_begin
+- commitXXXEffects_complete
+
+
+
+所分成的这三个子阶段，是有一些共同的事情要做的
+
+
+
+**commitXXXEffects**
+
+该函数是每个子阶段的入口函数，finishedWork 会作为 firstChild 参数传入进去，相关代码如下：
+
+```js
+function commitXXXEffects(root, firstChild){
+ nextEffect = firstChild;
+ // 省略标记全局变量
+ commitXXXEffects_begin();
+ // 省略重置全局变量
+}
+```
+
+因此在该函数中，主要的工作就是将 firstChild 赋值给全局变量 nextEffect，然后执行 commitXXXEffects_begin
+
+
+
+**commitXXXEffects_begin**
+
+向下遍历 FiberNode。遍历的时候会遍历直到第一个满足如下条件之一的 FiberNode：
+
+- 当前的 FiberNode 的子 FiberNode 不包含该子阶段对应的 flags
+- 当前的 FiberNode 不存在子 FiberNode
+
+接下来会对目标 FiberNode 执行 commitXXXEffects_complete 方法，commitXXXEffects_begin 相关代码如下：
+
+```js
+function commitXXXEffects_begin(){
+ while(nextEffect !== null) {
+ let fiber = nextEffect;
+ let child = fiber.child;
+
+ // 省略该子阶段的一些特有操作
+
+ if(fiber.subtreeFlags !== NoFlags && child !== null){
+ // 继续向下遍历
+ nextEffect = child;
+ } else {
+ commitXXXEffects_complete();
+ }
+ }
+}
+```
+
+
+
+**commitXXXEffects_complete**
+
+该方法主要就是针对 flags 做具体的操作了，主要包含以下三个步骤：
+
+- 对当前 FiberNode 执行 flags 对应的操作，也就是执行 commitXXXEffectsOnFiber
+- 如果当前 FiberNode 存在兄弟 FiberNode，则对兄弟 FiberNode 执行 commitXXXEffects_begin
+- 如果不存在兄弟 FiberNode，则对父 FiberNode 执行 commitXXXEffects_complete
+
+相关代码如下：
+
+```js
+function commitXXXEffects_complete(root){
+ while(nextEffect !== null){
+ let fiber = nextEffect;
+
+ try{
+ commitXXXEffectsOnFiber(fiber, root);
+ } catch(error){
+ // 错误处理
+ }
+
+ let sibling = fiber.sibling;
+
+ if(sibling !== null){
+ // ...
+ nextEffect = sibling;
+ return
+ }
+
+ nextEffect = fiber.return;
+ }
+}
+```
+
+
+
+总结一下，每个子阶段都会以 DFS 的原则来进行遍历，最终会在 commitXXXEffectsOnFiber 中针对不同的 flags 做出不同的处理。
+
+
+
+## BeforeMutation 阶段
+
+BeforeMutation 阶段的主要工作发生在 commitBeforeMutationEffects_complete 中的 commitBeforeMutationEffectsOnFiber 方法，相关代码如下：
+
+```js
+function commitBeforeMutationEffectsOnFiber(finishedWork){
+ const current = finishedWork.alternate;
+ const flags = finishedWork.falgs;
+
+ //...
+ // Snapshot 表示 ClassComponent 存在更新，且定义了 getSnapsshotBeforeUpdate 方法
+ if(flags & Snapshot !== NoFlags) {
+ switch(finishedWork.tag){
+ case ClassComponent: {
+ if(current !== null){
+ const prevProps = current.memoizedProps;
+ const prevState = current.memoizedState;
+ const instance = finishedWork.stateNode;
+
+ // 执行 getSnapsshotBeforeUpdate
+ const snapshot = instance.getSnapsshotBeforeUpdate(
+ finishedWork.elementType === finishedWork.type ?
+ prevProps : resolveDefaultProps(finishedWork.type, prevProps),
+ prevState
+ )
+ }
+ break;
+ }
+ case HostRoot: {
+ // 清空 HostRoot 挂载的内容，方便 Mutation 阶段渲染
+ if(supportsMutation){
+ const root = finishedWork.stateNode;
+ clearCOntainer(root.containerInfo);
+ }
+ break;
+ }
+ }
+ }
+}
+```
+
+上面代码的整个过程中，主要是处理如下两种类型的 FiberNode：
+
+- ClassComponent：执行 getSnapsshotBeforeUpdate 方法
+- HostRoot：清空 HostRoot 挂载的内容，方便 Mutation 阶段进行渲染
+
+
+
+## Mutation 阶段
+
+对于 HostComponent，Mutation 阶段的主要工作就是对 DOM 元素及进行增、删、改
+
+
+
+### 删除 DOM 元素
+
+删除 DOM 元素相关代码如下：
+
+```js
+function commitMutationEffects_begin(root){
+ while(nextEffect !== null){
+ const fiber = nextEffect;
+ // 删除 DOM 元素
+ const deletions = fiber.deletions;
+
+ if(deletions !== null){
+ for(let i=0;i
+
+
+```
+
+当你删除最外层的 div 这个 DOM 元素时，需要考虑：
+
+- 执行 SomeClassComponent 类组件对应的 componentWillUnmount 方法
+- 执行 SomeFunctionComponent 函数组件中的 useEffect、useLayoutEffect 这些 hook 中的 destory 方法
+- divRef 的卸载操作
+
+整个删除操作是以 DFS 的顺序，遍历子树的每个 FiberNode，执行对应的操作。
+
+
+
+### 插入、移动 DOM 元素
+
+上面的删除操作是在 commitMutationEffects_begin 方法里面执行的，而插入和移动 DOM 元素则是在 commitMutationEffects_complete 方法里面的 commitMutationEffectsOnFiber 方法里面执行的，相关代码如下：
+
+```js
+function commitMutationEffectsOnFiber(finishedWork, root){
+ const flags = finishedWork.flags;
+
+ // ...
+
+ const primaryFlags = flags & (Placement | Update | Hydrating);
+
+ outer: switch(primaryFlags){
+ case Placement:{
+ // 执行 Placement 对应操作
+ commitPlacement(finishedWork);
+ // 执行完 Placement 对应操作后，移除 Placement flag
+ finishedWork.falgs &= ~Placement;
+ break;
+ }
+ case PlacementAndUpdate:{
+ // 执行 Placement 对应操作
+ commitPlacement(finishedWork);
+ // 执行完 Placement 对应操作后，移除 Placement flag
+ finishedWork.falgs &= ~Placement;
+
+ // 执行 Update 对应操作
+ const current = finishedWork.alternate;
+ commitWork(current, finishedWork);
+ break;
+ }
+
+ // ...
+ }
+
+
+}
+```
+
+可以看出， Placement flag 对应的操作方法为 commitPlacement，代码如下：
+
+```js
+function commitPlacement(finishedWork){
+ // 获取 Host 类型的祖先 FiberNode
+ const parentFiber = getHostParentFiber(finishedWork);
+
+ // 省略根据 parentFiber 获取对应 DOM 元素的逻辑
+
+ let parent;
+
+ // 目标 DOM 元素会插入至 before 左边
+ const before = getHostSibling(finishedWork);
+
+ // 省略分支逻辑
+ // 执行插入或移动操作
+ insertOrAppendPlacementNode(finishedWork, before, parent);
+}
+```
+
+整个 commitPlacement 方法的执行流程可以分为三个步骤：
+
+- 从当前 FiberNode 向上遍历，获取第一个类型为 HostComponent、HostRoot、HostPortal 三者之一的祖先 FiberNode，其对应的 DOM 元素是执行 DOM 操作的目标元素的父级 DOM 元素
+- 获取用于执行 parentNode.insertBefore(child, before) 方法的 “before 对应的 DOM 元素”
+- 执行 parentNode.insertBefore 方法（存在 before）或者 parentNode.appendChild 方法（不存在 before）
+
+对于“还没有插入的DOM元素”（对应的就是 mount 场景），insertBefore 会将目标 DOM 元素插入到 before 之前，appendChild 会将目标DOM元素作为父DOM元素的最后一个子元素插入
+
+对于“UI中已经存在的 DOM 元素”（对应 update 场景），insertBefore 会将目标 DOM 元素移动到 before 之前，appendChild 会将目标 DOM 元素移动到同级最后。
+
+因此这也是为什么在 React 中，插入和移动所对应的 flag 都是 Placement flag 的原因。（可能面试的时候会被问到）
+
+
+
+### 更新 DOM 元素
+
+更新 DOM 元素，一个最主要的工作就是更新对应的属性，执行的方法为 commitWork，相关代码如下：
+
+```js
+function commitWork(current, finishedWork){
+ switch(finishedWork.tag){
+ // 省略其他类型处理逻辑
+ case HostComponent:{
+ const instance = finishedWork.stateNode;
+ if(instance != null){
+ const newProps = finishedWork.memoizedProps;
+ const oldProps = current !== null ? current.memoizedProps : newProps;
+ const type = finishedWork.type;
+
+ const updatePayload = finishedWork.updateQueue;
+ finishedWork.updateQueue = null;
+ if(updatePayload !== null){
+ // 存在变化的属性
+ commitUpdate(instance, updatePayload, type, oldProps, newProps, finishedWork);
+ }
+ }
+ return;
+ }
+ }
+}
+```
+
+之前有讲过，变化的属性会以 key、value 相邻的形式保存在 FiberNode.updateQueue ，最终在 FiberNode.updateQueue 里面所保存的要变化的属性就会在一个名为 updateDOMProperties 方法被遍历然后进行处理，这里的处理主要是处理如下的四种数据：
+
+- style 属性变化
+- innerHTML
+- 直接文本节点变化
+- 其他元素属性
+
+相关代码如下：
+
+```js
+function updateDOMProperties(domElement, updatePayload, wasCustomComponentTag, isCustomComponentTag){
+ for(let i=0;i< updatePayload.length; i+=2){
+ const propKey = updatePayload[i];
+ const propValue = updatePayload[i+1];
+ if(propKey === STYLE){
+ // 处理 style
+ setValueForStyle(domElement, propValue);
+ } else if(propKey === DANGEROUSLY_SET_INNER_HTML){
+ // 处理 innerHTML
+ setInnerHTML(domElement, propValue);
+ } else if(propsKey === CHILDREN){
+ // 处理直接的文本节点
+ setTextContent(domElement, propValue);
+ } else {
+ // 处理其他元素
+ setValueForProperty(domElement, propKey, propValue, isCustomComponentTag);
+ }
+ }
+}
+```
+
+
+
+当 Mutation 阶段的主要工作完成后，在进入 Layout 阶段之前，会执行如下的代码来完成 FiberTree 的切换：
+
+```js
+root.current = finishedWork;
+```
+
+
+
+## Layout 阶段
+
+有关 DOM 元素的操作，在 Mutation 阶段已经结束了。
+
+在 Layout 阶段，主要的工作集中在 commitLayoutEffectsOnFiber 方法中，在该方法内部，会针对不同类型的 FiberNode 执行不同的操作：
+
+- 对于 ClassComponent：该阶段会执行 componentDidMount/Update 方法
+- 对于 FunctionComponent：该阶段会执行 useLayoutEffect 的回调函数
+
+
+
+## 真题解答
+
+> 题目：commit 阶段的工作流程是怎样的？此阶段可以分为哪些模块？每个模块在做什么？
+>
+> 参考答案：
+>
+> 整个 commit 可以分为三个子阶段
+>
+> - BeforeMutation 阶段
+> - Mutation 阶段
+> - Layout 阶段
+>
+> 每个子阶段又可以分为 commitXXXEffects、commitXXXEffects_beigin 和 commitXXXEffects_complete
+>
+> 其中 commitXXXEffects_beigin 主要是在做遍历节点的操作，commitXXXEffects_complete 主要是在处理副作用
+>
+> BeforeMutation 阶段整个过程主要处理如下两种类型的 FiberNode：
+>
+> - ClassComponent，执行 getSnapsshotBeforeUpdate 方法
+> - HostRoot，清空 HostRoot 挂载的内容，方便 Mutation 阶段渲染
+>
+> 对于 HostComponent，Mutation 阶段的工作主要是进行 DOM 元素的增、删、改。当 Mutation 阶段的主要工作完成后，在进入 Layout 阶段之前，会执行如下的代码完成 Fiber Tree 的切换。
+>
+> Layout 阶段会对遍历到的每个 FiberNode 执行 commitLayoutEffectOnFiber，根据 FiberNode 的不同，执行不同的操作，例如：
+>
+> - 对于 ClassComponent，该阶段执行 componentDidMount/Update 方法
+> - 对于 FunctionComponent，该阶段执行 useLayoutEffect callback 方法
\ No newline at end of file
diff --git a/就业篇/02. 第二章/2-17. lane模型/lane模型.md b/就业篇/02. 第二章/2-17. lane模型/lane模型.md
new file mode 100644
index 0000000..ddffa8f
--- /dev/null
+++ b/就业篇/02. 第二章/2-17. lane模型/lane模型.md
@@ -0,0 +1,225 @@
+# lane模型
+
+> 面试题：是否了解过 React 中的 lane 模型？为什么要从之前的 expirationTime 模型转换为 lane 模型？
+
+
+
+## React 和 Scheduler 优先级的介绍
+
+之前我们已经介绍过 Scheduler，React 团队是打算将 Scheduler 进行独立发布。
+
+在 React 内部，还会有一个粒度更细的优先级算法，这个就是 lane 模型。
+
+接下来我们来看一下两套优先级模型的一个转换。
+
+
+
+在 Scheduler 内部，拥有 5 种优先级：
+
+```js
+export const NoPriority = 0;
+export const ImmediatePriority = 1;
+export const UserBlockingPriority = 2;
+export const NormalPriority = 3;
+export const LowPriority = 4;
+export const IdlePriority = 5;
+```
+
+作为一个独立的包，需要考虑到通用性，Scheduler 和 React 的优先级并不共通，在 React 内部，有四种优先级，如下四种：
+
+```js
+export const DiscreteEventPriority: EventPriority = SyncLane;
+export const ContinuousEventPriority: EventPriority = InputContinuousLane;
+export const DefaultEventPriority: EventPriority = DefaultLane;
+export const IdleEventPriority: EventPriority = IdleLane;
+```
+
+由于 React 中不同的交互对应的事件回调中产生的 update 会有不同的优先级，因此优先级与事件有关，因此在 React 内部的优先级也被称之为 EventPriority，各种优先级的含义如下：
+
+- DiscreteEventPriority：对应离散事件优先级，例如 click、input、focus、blur、touchstart 等事件都是离散触发的
+- ContinuousEventPriority：对应连续事件的优先级，例如 drag、mousemove、scroll、touchmove 等事件都是连续触发的
+- DefaultEventPriority：对应默认的优先级，例如通过计时器周期性触发更新，这种情况下产生的 update 不属于交互产生 update，所以优先级是默认的优先级
+- IdleEventPriority：对应空闲情况的优先级
+
+在上面的代码中，我们还可以观察出一件事情，不同级别的 EventPriority 对应的是不同的 lane
+
+
+
+既然 React 与 Scheduler 优先级不互通，那么这里就会涉及到一个转换的问题，这里分为：
+
+- React 优先级转为 Scheduler 的优先级
+- Scheduler 的优先级转为 React 的优先级
+
+
+
+**React 优先级转为 Scheduler 的优先级**
+
+整体会经历两次转换：
+
+- 首先是将 lanes 转为 EventPriority，涉及到的方法如下：
+
+```js
+export function lanesToEventPriority(lanes: Lanes): EventPriority {
+ // getHighestPriorityLane 方法用于分离出优先级最高的 lane
+ const lane = getHighestPriorityLane(lanes);
+ if (!isHigherEventPriority(DiscreteEventPriority, lane)) {
+ return DiscreteEventPriority;
+ }
+ if (!isHigherEventPriority(ContinuousEventPriority, lane)) {
+ return ContinuousEventPriority;
+ }
+ if (includesNonIdleWork(lane)) {
+ return DefaultEventPriority;
+ }
+ return IdleEventPriority;
+}
+```
+
+- 将 EventPriority 转换为 Scheduler 的优先级，方法如下：
+
+```js
+// ...
+let schedulerPriorityLevel;
+switch (lanesToEventPriority(nextLanes)) {
+ case DiscreteEventPriority:
+ schedulerPriorityLevel = ImmediateSchedulerPriority;
+ break;
+ case ContinuousEventPriority:
+ schedulerPriorityLevel = UserBlockingSchedulerPriority;
+ break;
+ case DefaultEventPriority:
+ schedulerPriorityLevel = NormalSchedulerPriority;
+ break;
+ case IdleEventPriority:
+ schedulerPriorityLevel = IdleSchedulerPriority;
+ break;
+ default:
+ schedulerPriorityLevel = NormalSchedulerPriority;
+ break;
+}
+// ...
+```
+
+举一个例子，假设现在有一个点击事件，在 onClick 中对应有一个回调函数来触发更新，该更新属于 DiscreteEventPriority，经过上面的两套转换规则进行转换之后，最终得到的 Scheduler 对应的优先级就是 ImmediateSchedulerPriority
+
+
+
+**Scheduler 的优先级转为 React 的优先级**
+
+转换相关的代码如下：
+
+```js
+const schedulerPriority = getCurrentSchedulerPriorityLevel();
+switch (schedulerPriority) {
+ case ImmediateSchedulerPriority:
+ return DiscreteEventPriority;
+ case UserBlockingSchedulerPriority:
+ return ContinuousEventPriority;
+ case NormalSchedulerPriority:
+ case LowSchedulerPriority:
+ return DefaultEventPriority;
+ case IdleSchedulerPriority:
+ return IdleEventPriority;
+ default:
+ return DefaultEventPriority;
+}
+```
+
+
+
+这里会涉及到一个问题，在同一时间可能存在很多的更新，究竟先去更新哪一个？
+
+- 从众多的有优先级的 update 中选出一个优先级最高的
+- 表达批的概念
+
+React 在表达方式上面实际上经历了两次迭代：
+
+- 基于 expirationTime 的算法
+- 基于 lane 的算法
+
+
+
+## expirationTime 模型
+
+React 早期采用的就是 expirationTime 的算法，这一点和 Scheduler 里面的设计是一致的。
+
+在 Scheduler 中，设计了 5 种优先级，不同的优先级会对应不同的 timeout，最终会对应不同的 expirationTime，然后 task 根据 expirationTime 来进行任务的排序。
+
+早期的时候在 React 中延续了这种设计，update 的优先级与触发事件的当前时间以及优先级对应的延迟时间相关，这样的算法实际上是比较简单易懂的，每当进入 schedule 的时候，就会选出优先级最高的 update 进行一个调度。
+
+但是这种算法在表示“批”的概念上不够灵活。
+
+在基于 expirationTime 模型的算法中，有如下的表达：
+
+```js
+const isUpdateIncludedInBatch = priorityOfUpdate >= priorityOfBatch;
+```
+
+priorityOfUpdate 表示的是当前 update 的优先级，priorityOfBatch 代表的是批对应的优先级下限，也就是说，当前的 update 只要大于等于 priorityOfBatch，就会被划分为同一批：
+
+
+
+但是此时就会存在一个问题，如何将某一范围的某几个优先级划为同一批？
+
+
+
+在上图中，我们想要将 u1、u2、u3 和 u4 划分为同一批，但是以前的 expirationTime 模型是无法做到的。
+
+究其原因，是因为 expirationTime 模型优先级算法耦合了“优先级”和“批”的概念，限制了模型的表达能力。优先级算法的本质是为 update 进行一个排序，但是 expirationTime 模型在完成排序的同时还默认的划定了“批”。
+
+
+
+## lane 模型
+
+因此，基于上述的原因，React 中引入了 lane 模型。
+
+不管新引入什么模型，比如要保证以下两个问题得到解决：
+
+- 以优先级为依据，对 update 进行一个排序
+- 表达批的概念
+
+
+
+针对第一个问题，lane模型中设置了很多的 lane，每一个lane实际上是一个二进制数，通过二进制来表达优先级，越低的位代表越高的优先级，例如：
+
+```js
+export const SyncLane: Lane = /* */ 0b0000000000000000000000000000001;
+export const InputContinuousLane: Lane = /* */ 0b0000000000000000000000000000100;
+export const DefaultLane: Lane = /* */ 0b0000000000000000000000000010000;
+export const IdleLane: Lane = /* */ 0b0100000000000000000000000000000;
+export const OffscreenLane: Lane = /* */ 0b1000000000000000000000000000000;
+```
+
+在上面的代码中，SyncLane 是最高优先级，OffscreenLane 是最低优先级。
+
+
+
+对于第二个问题，lane模型能够非常灵活的表达批的概念：
+
+```js
+// 要使用的批
+let batch = 0;
+// laneA 和 laneB。是不相邻的优先级
+const laneA = 0b0000000000000000000000001000000;
+const laneB = 0b0000000000000000000000000000001;
+// 将 laneA 纳入批中
+batch |= laneA;
+// 将 laneB 纳入批中
+batch |= laneB;
+```
+
+
+
+## 真题解答
+
+> 题目：是否了解过 React 中的 lane 模型？为什么要从之前的 expirationTime 模型转换为 lane 模型？
+>
+> 参考答案：
+>
+> 在 React 中有一套独立的粒度更细的优先级算法，这就是 lane 模型。
+>
+> 这是一个基于位运算的算法，每一个 lane 是一个 32 bit Integer，不同的优先级对应了不同的 lane，越低的位代表越高的优先级。
+>
+> 早期的 React 并没有使用 lane 模型，而是采用的的基于 expirationTime 模型的算法，但是这种算法耦合了“优先级”和“批”这两个概念，限制了模型的表达能力。优先级算法的本质是“为 update 排序”，但 expirationTime 模型在完成排序的同时还默认的划定了“批”。
+>
+> 使用 lane 模型就不存在这个问题，因为是基于位运算，所以在批的划分上会更加的灵活。
\ No newline at end of file
diff --git a/就业篇/02. 第二章/2-24. Update/Update.md b/就业篇/02. 第二章/2-24. Update/Update.md
new file mode 100644
index 0000000..e181f2d
--- /dev/null
+++ b/就业篇/02. 第二章/2-24. Update/Update.md
@@ -0,0 +1,222 @@
+# Update
+
+> 面试题：说一说 React 中的 updateQueue
+
+在 React 中，有许多触发状态更新的方法，比如：
+
+- ReactDOM.createRoot
+- this.setState
+- this.forceUpdate
+- useState dispatcher
+- useReducer dispatcher
+
+虽然这些方法执行的场景会有所不同，但是都可以接入同样的更新流程，原因是因为它们使用同一种数据结构来表示更新，这种数据结构就是 Update。
+
+
+
+## Update 数据结构
+
+在 React 中，更新实际上是存在优先级的，其心智模型有一些类似于“代码版本管理工具”。
+
+举个例子，假设现在我们在开发一个软件，当前软件处于正常的迭代中，拥有 A、B、C 三个正常需求，此时突然来了一个紧急的线上 Bug，整体流程如下：
+
+
+
+为了修复线上 Bug D，你需要先完成需求 A、B、C，之后才能进行 D 的修复，这样的设计实际上是不合理的。
+
+有了代码版本管理工具之后，有紧急线上 Bug 需要修复时，可以先暂存当前分支的修改，在 master 分支修复 Bug D 并紧急上线：
+
+
+
+当 Bug 修复完毕后，再正常的来迭代 A、B、C 需求，之后的迭代会基于 D 这个版本：
+
+
+
+
+
+并发更新的 React 也拥有相似的能力，不同的 update 是有不同的优先级，高优先级的 update 能够中断低优先级的 update，当高优先级的 update 完成更新之后，后续的低优先级更新会在高优先级 update 更新后的 state 的基础上再来进行更新。
+
+
+
+接下来我们来看一下 Update 的一个数据结构。
+
+在前面我们说了在 React 中，有不同的触发更新的方法，不同的方法实际上对应了不同的组件：
+
+- ReactDOM.createRoot 对应 HostRoot
+- this.setState 对应 ClassComponent
+- this.forceUpdate 对应 ClassComponent
+- useState dispatcher 对应 FunctionComponent
+- useReducer dispatcher 对应 FunctionComponent
+
+不同的组件类型，所对应的 Update 的数据结构是不同的。
+
+HostRoot 和 ClassComponent 这一类组件所对应的 Update 数据结构如下：
+
+```js
+function createUpdate(eventTime, lane){
+ const update = {
+ eventTime,
+ lane,
+ // 区分触发更新的场景
+ tag: UpdateState,
+ payload: null,
+ // UI 渲染后触发的回调函数
+ callback: null,
+ next: null,
+ };
+ return update;
+}
+```
+
+在上面的 Update 数据结构中，tag 字段是用于区分触发更新的场景的，选项包括：
+
+- ReplaceState：代表在 ClassComponent 生命周期函数中直接改变 this.state
+- UpdateState：默认情况，通过 ReactDOM.createRoot 或者 this.setState 触发更新
+- CaptureUpdate：代表发生错误的情况下在 ClassComponent 或 HostRoot 中触发更新（比如通过 getDerivedStateFormError 方法）
+- ForceUpdate：代表通过 this.forceUpdate 触发更新
+
+接下来来看一下 FunctionComponent 所对应的 Update 数据结构：
+
+```js
+const update = {
+ lane,
+ action,
+ // 优化策略相关字段
+ hasEagerState: false,
+ eagerState: null,
+ next: null
+}
+```
+
+在上面的数据结构中，有 hasEagerState 和 eagerState 这两个字段，它们和后面要介绍的 React 内部的性能优化策略（eagerState 策略）相关。
+
+
+
+在 Update 数据结构中，有三个问题是需要考虑：
+
+- 更新所承载的更新内容是什么
+
+对于HostRoot以及类组件来讲，承载更新内容的字段为 payload 字段
+
+```js
+// HostRoot
+ReactDOM.createRoot(rootEle).render(
+
+之后进入新的一轮 render，在该 FiberNode 的 beginWork 中，shared.pending 所指向的环状链表就会被拆分，拆分之后接入到 baseUpdate 链表后面：
+
+
+
+接下来就会遍历 updateQueue.baseUpdate，基于 updateQueue.baseState 来计算每个符合优先级条件的 update（这个过程有点类似于 Array.prototype.reduce），最终计算出最新的 state，该 state 被称之为 memoizedState。
+
+
+
+因此我们总结一下，整个 state 的计算流程可以分为两步：
+
+- 将 shared.pending 所指向的环状链表进行拆分并且和 baseUpdate 进行拼接，形成新的链表
+- 遍历连接后的链表，根据 wipRootRenderLanes 来选定优先级，基于符合优先级条件的 update 来计算 state
+
+
+
+## 真题解答
+
+> 题目：面试题：说一说 React 中的 updateQueue
+>
+> 参考答案：
+>
+> update 是计算 state 的最小单位，一条 updateQueue 代表由 update 所组成的链表，其中几个重要的属性列举如下：
+>
+> - baseState：参与计算的初始 state，update 基于该 state 计算新的 state，可以类比为心智模型中的 master 分支。
+> - firstBaseUpdate 与 lastBaseUpdate：表示更新前该 FiberNode 中已保存的 update，以链表的形式串联起来。链表头部为 firstBaseUpdate，链表尾部为 lastBaseUpdate。
+> - shared.pending：触发更新后，产生的 update 会保存在 shared.pending 中形成单向环状链表。计算 state 时，该环状链表会被拆分并拼接在 lastBaseUpdate 后面。
+>
+> 整个 state 的计算流程可以分为两步：
+>
+> - 将 shared.pending 所指向的环状链表进行拆分并且和 baseUpdate 进行拼接，形成新的链表
+> - 遍历连接后的链表，根据 wipRootRenderLanes 来选定优先级，基于符合优先级条件的 update 来计算 state
\ No newline at end of file
diff --git a/就业篇/02. 第二章/2-26. 性能优化策略之bailout/性能优化策略之bailout.md b/就业篇/02. 第二章/2-26. 性能优化策略之bailout/性能优化策略之bailout.md
new file mode 100644
index 0000000..a52de81
--- /dev/null
+++ b/就业篇/02. 第二章/2-26. 性能优化策略之bailout/性能优化策略之bailout.md
@@ -0,0 +1,283 @@
+# 性能优化策略之bailout
+
+> 面试题：谈一谈 React 中的 bailout 策略
+
+前面我们学习 beginWork 的时候，我们知道 beginWork 的作用主要是生成 wipFiberNode 的子 FiberNode，要达到这个目录存在两种方式：
+
+- 通过 reconcile 流程生成子 FiberNode
+- 通过命中 bailout 策略来复用子 FiberNode
+
+在前面我们讲过，所有的变化都是由“自变量”的改变造成的，在 React 中自变量：
+
+- state
+- props
+- context
+
+因此是否命中 bailout 主要也是围绕这三个变量展开的，整体的工作流程如下：
+
+
+
+从上图可以看出，bailout 是否命中发生在 update 阶段，在进入 beginWork 后，会有两次是否命中 bailout 策略的相关判断
+
+
+
+## 第一次判断
+
+第一次判断发生在确定了是 update 后，立马就会进行是否能够复用的判断：
+
+- oldProps 全等于 newProps
+- Legacy Context 没有变化
+- FiberNode.type 没有变化
+- 当前 FiberNode 没有更新发生
+
+
+
+**oldProps 全等于 newProps**
+
+注意这里是做的一个全等比较。组件在 render 之后，拿到的是一个 React 元素，会针对 React 元素的 props 进行一个全等比较。但是由于每一次组件 render 的时候，会生成一个全新的对象引用，因此 oldProps 和 newProps 并不会全等，此时是没有办法命中 bailout。
+
+只有当父 FiberNode 命中 bailout 策略时，复用子 FiberNode，在子 FiberNode 的 beginWork 中，oldProps 才有可能和 newProps 全等。
+
+> 备注：视频中这里讲解有误，不是针对 props 属性每一项进行比较，而是针对 props 对象进行全等比较。上面的笔记内容已修改。
+
+
+
+**Legacy Context 没有变化**
+
+Legacy Context指的是旧的 ContextAPI，ContextAPI重构过一次，之所以重构，就是和 bailout策略相关。
+
+
+
+**FiberNode.type 没有变化**
+
+这里所指的 FiberNode.type 没有变化，指的是不能有例如从 div 变为 p 这种变化。
+
+```jsx
+function App(){
+ const Child = () => child
+ return {num}
+} + +// 父组件 +function App() { + return ( +耗时的组件
; +} + +function App() { + const [num, updateNum] = useState(0); + + return ( + <> + updateNum(e.target.value)} /> +num is {num}
+耗时的组件
; +} + +function Input() { + const [num, updateNum] = useState(0); + + return ( +
+ updateNum(e.target.value)} />
+
+ );
+}
+
+function App() {
+ return (
+ <>
+
+ num is {num}
+耗时的组件
; +} + + +function App() { + const [num, updateNum] = useState(0); + + return ( +
+ updateNum(e.target.value)} />
+
+ );
+}
+
+export default App;
+```
+
+那么此时我们可以通过 children 来达到分离的目的，如下：
+
+```jsx
+import React, { useState } from "react";
+
+function ExpensiveCom() {
+ const now = performance.now();
+ while (performance.now() - now < 200) {}
+ return num is {num}
+耗时的组件
; +} + +function Counter({ children }) { + const [num, updateNum] = useState(0); + return ( +
+ updateNum(e.target.value)} />
+
+ );
+}
+
+function App() {
+ // 在该 App 当中就没有维护数据了，也就不存在 state 的变化
+ return (
+ num is {num}
+ {children} +