React Fiber全局变量在ReactFiberWorkLoop.js闭包内初始化，为工作循环内部状态寄存器，非导出常量；初始值严格有序（如executionContext=0b0000000、workInProgress=null），依赖位掩码常量控制执行阶段，不可重置或手动清理。
全局变量初始化发生在 ReactFiberWorkLoop.js 闭包内
React 的 Fiber 工作循环依赖一组严格时序控制的全局变量，它们全部定义在 ReactFiberWorkLoop.js 的顶层函数闭包中，**不是模块导出的常量，也不通过 import 引入**。这意味着：它们在模块首次执行时就完成初始化，且生命周期与整个 React 运行时绑定。
这些变量不是“配置项”，而是协调器内部状态寄存器——比如 workInProgress 指向当前正在构造的 Fiber 节点，executionContext 是位掩码型上下文标识，workInProgressRoot 记录当前渲染的 root 实例。
-
executionContext初始化为NoContext（即0b0000000），后续靠位运算（|=）动态叠加如RenderContext、CommitContext -
workInProgress和workInProgressRoot初始值都是null，首次render或update触发时才被赋值 -
subtreeRenderLanes和workInProgressRootRenderLanes初始为NoLanes（即0），代表无待处理优先级 - 所有栈游标（如
subtreeRenderLanesCursor）由createCursor(NoLanes)创建，本质是带初始值的链表头指针
Fiber 中没有“全局常量”，只有位掩码型上下文常量
所谓“全局常量”在 Fiber 架构里实际是硬编码的位标志（bitmask），全部定义在 ReactFiberWorkLoop.js 开头，用于 executionContext 的状态判断。它们不参与运行时修改，但直接决定调度分支逻辑。
例如：LegacyUnbatchedContext 是 0b0001000，RenderContext 是 0b0010000。当代码写 if (executionContext & RenderContext)，就是在检查当前是否处于 render 阶段。
- 这些常量不可重定义，也不能通过配置覆盖；改一个二进制位会导致整个工作循环逻辑错乱
- 它们和
Lane模型中的常量（如SyncLane、DefaultLane）属于不同语义层：前者管执行阶段，后者管更新优先级 - 调试时若看到
executionContext值为0b0010010，说明同时处于EventContext+RenderContext—— 即事件触发后立刻进入同步 render
初始化顺序不能颠倒，依赖关系隐含在赋值位置
这些变量虽同处闭包，但初始化顺序有隐含依赖。比如 subtreeRenderLanesCursor 必须在 subtreeRenderLanes 之后初始化，因为它的 createCursor 构造函数要传入后者作为默认值。
更关键的是：所有变量都必须在 workLoop 函数定义之前完成声明和初值设定。一旦 workLoop 开始执行，任何对这些变量的未预期写入（比如在副作用中直接赋值 workInProgress = null）都会破坏 Fiber 树构造的原子性。
- 切勿在自定义 Hook 或组件内试图读写
workInProgress或executionContext—— 它们不在作用域内，且强行访问会报ReferenceError - 调试 Fiber 状态时，唯一安全入口是
React DevTools的 fiber inspector，或在beginWork/completeWork打 patch 断点观察局部变量 - 源码中所有
workInProgress*变量命名都带workInProgress前缀，这是刻意为之的信号：它们只在单次 work loop 生命周期内有效，跨 loop 不保留
Fiber 全局状态不支持热重置或手动清理
这些变量没有 reset 接口，也没有 dispose 机制。React 不提供任何 API 让你“清空当前 fiber 状态”或“重启工作循环”。一旦 workInProgressRoot 被设为某个 FiberRoot 实例，它就会持续持有引用直到该 root 被卸载（unmountComponentAtNode）。
这意味着：服务端渲染（SSR）场景下，若复用同一份 React 包实例处理多个请求，必须确保每个请求走独立的 FiberRoot，否则 workInProgressRoot 会残留上一个请求的状态，引发内存泄漏或 UI 错乱。
- 常见误操作：在 Express 中间件里调用
ReactDOMServer.renderToString后，没等异步资源 resolve 就返回响应，导致workInProgressRoot仍处于 pending 状态 - 正确做法：SSR 必须配合
React.unstable_batchedUpdates或renderToPipeableStream确保 work loop 完全退出后再释放上下文 - 最易被忽略的一点：即使组件树为空（
null），workInProgressRoot仍可能非null—— 它反映的是“是否有正在进行的 render”，而非“DOM 是否挂载”
