各位老铁，大家好！今天咱们不聊那些花里胡哨的 Hooks，也不搞什么“如何用 React 写出百万行代码”的鸡汤。咱们来点硬核的，来点“刑”的。
咱们今天要聊的是 React 源码里那个让人头皮发麻、面试必问、实际上非常“霸道”的机制——Diff 算法中的单节点协调。
特别是这个场景：Key 相同，但 Type 不同时，React 是如何“狠心”销毁旧 Fiber，然后“强行”创建新节点的？
很多人看到这里会想：“这不就是换个标签吗？比如把 div 换成 span，或者把 Button 换成 Link，React 为什么不能就地更新一下？非得给我删了重建？”
别急，今天我就带你们扒开 React 的裤衩子（不是），带你们看看它的核心引擎到底在脑子里想什么。准备好了吗？咱们开搞！
第一部分：场景设定——“同一个人，换了张脸”
想象一下，你现在手里有一张身份证，上面写着“张三”，而且这张身份证上贴着一张照片。这张照片就是我们的 Key，而“张三”这个人，就是我们的 Type。
现在，系统告诉你：“张三换了工作！”
以前他是“程序员”（div），现在他是“产品经理”（span）。
按照咱们人类的直觉，我们要么是直接把照片撕了换一张新的，要么是给这个人整容。但 React 的逻辑比较“轴”。
如果 React 看到身份证号（Key）没变，但职业（Type）变了，它的第一反应不是“给张三换个皮”，而是：“张三，你退休了！你的工位清空！现在，你被开除了！我们要招一个新来的产品经理！”
这听起来很残忍，对吧？但这背后是 React 为了保证数据一致性做出的巨大牺牲。
如果 React 试图“就地更新”，也就是把 div 的标签属性改成 span，那会发生什么灾难？
- 属性丢失：
div有className，span没有。React 能把div的className赋值给span吗？不能，因为span本身不支持这个属性，浏览器会直接忽略。 - 子节点塌陷：
div里面包了一堆p标签，span是内联元素，它不能包p。如果强行更新，里面的子节点全没了，页面会乱套。 - 副作用清零：
div上面挂了个useEffect，span上没有。如果你原地更新，useEffect的清理函数可能根本不会触发，或者触发时机不对。
所以，React 的决策是：Type 不同 = 身份核验失败 = 旧节点作废 = 全部销毁。
第二部分：源码深潜——reconcileChildren 的审判庭
要搞清楚这个过程，咱们得顺着源码走。React 的协调过程入口通常在 ReactReconciler 的 reconcileChildren 方法里。
假设我们现在在处理一个单节点的情况，代码逻辑大概长这样（为了通俗易懂，我进行了伪代码化处理，但核心逻辑一分不差）：
function reconcileChildren(
currentFiber, // 旧 Fiber 节点
workInProgressFiber, // 新的 WorkInProgress Fiber 节点
nextChildren // 新的 React Element 数组
) {
// 1. 确定当前比较的是单节点还是多节点
// 假设我们只看第一个子元素
const newFirstChild = nextChildren[0];
// 2. 核心判断：旧 Fiber 和 新 Element 的 Type 和 Key
// 注意：这里比较的是 element.type，也就是组件类型或 DOM 标签类型
const sameType =
currentFiber.elementType === newFirstChild.elementType ||
typeof currentFiber.elementType === 'object' && currentFiber.elementType.type === newFirstChild.elementType;
if (sameType) {
// 如果类型相同，那就走更新逻辑（这是咱们最熟悉的 Path）
// 比如 div 变成了 div，只是里面的 textContent 变了
reconcileSingleElement(currentFiber, workInProgressFiber, newFirstChild);
} else {
// ----------------------------------------------------------------
// 重点来了！这里就是你要的“Type 不同”的战场！
// ----------------------------------------------------------------
// 逻辑一：强制销毁旧 Fiber
// React 认为，既然类型变了，那原来的那个节点就彻底没用了
// 不管它的 key 是什么，不管它的位置在哪里，先删了再说！
if (currentFiber !== null) {
unmountFiber(currentFiber);
}
// 逻辑二：创建新 Fiber
// 既然旧的不去，新的不来。这里调用 createFiberFromTypeAndProps
// 这会根据新的 Type 创建一个全新的 Fiber 节点
const fiber = createFiberFromTypeAndProps(
newFirstChild.type,
newFirstChild.key,
newFirstChild.props,
newFirstChild.mode
);
// 逻辑三：挂载到树上
workInProgressFiber.child = fiber;
}
}看懂了吗？在这个 else 分支里，React 做了三件大事：断交、重生、入职。
第三部分：销毁旧 Fiber —— unmountFiber 的“大扫除”
当我们调用 unmountFiber 时，React 并不是简单地执行 domNode.remove()。那是 DOM 操作，不是 React 的逻辑。
React 的销毁过程是一场极其严谨的“大扫除”，它要确保不留下一丝垃圾。
让我们看看 unmountFiber 的源码逻辑（简化版）：
function unmountFiber(fiber) {
// 1. 递归销毁子节点
// 这是一个后序遍历！先处理孙子辈，再处理儿子辈，最后处理自己
// 为什么？因为子节点依赖父节点，必须先清理完“家底”
if (fiber.child) {
unmountFiber(fiber.child);
}
// 2. 销毁兄弟节点
if (fiber.sibling) {
unmountFiber(fiber.sibling);
}
// 3. 清理副作用
// 这是最关键的一步！
// 如果这个 Fiber 节点上有 useEffect，或者 useLayoutEffect，或者是 ref
// 现在就是执行清理函数的时候！
const deps = fiber.deps; // 如果有的话
if (deps) {
// 执行 cleanup 函数
deps.forEach(cleanup => cleanup());
}
// 4. 清理 Refs
if (fiber.ref) {
// 比如 <input ref={inputRef} />，现在 Fiber 被销毁了
// 我们需要把 inputRef.current 设为 null，否则内存泄漏！
fiber.ref.current = null;
}
// 5. 卸载 DOM 节点
// 只有 HostComponent（比如 div, span）才会有 DOM 节点
if (fiber.tag === HostComponent) {
const domNode = fiber.stateNode;
// 这一步是真正把节点从浏览器里删掉
if (domNode) {
// 如果有事件监听器，React 会在这里移除
removeEventListener(domNode);
// 删掉 DOM
domNode.parentNode.removeChild(domNode);
}
}
// 6. 释放内存
// Fiber 节点本身也是对象，GC（垃圾回收）会回收它
// 但 React 会把它的指针置空，防止悬空引用
fiber.stateNode = null;
fiber.return = null;
fiber.child = null;
fiber.sibling = null;
}为什么这里要递归销毁？
因为 div 里面可能有 span，span 里面可能有 button。如果只销毁 div，不销毁里面的 button，那个 button 就成了“孤魂野鬼”，还挂在 div 的 child 链表里，导致内存泄漏。
为什么这里要清理 useEffect？
因为旧组件可能监听了窗口大小变化，现在组件类型变了，组件被销毁了，窗口事件监听器必须被移除。否则，当你以后重新渲染这个组件时，可能会触发多次监听，或者监听器指向了一个已经不存在的对象。
第四部分：创建新 Fiber —— createFiberFromTypeAndProps 的“重生”
销毁完了，现在要创建新节点。这个过程在 createFiberFromTypeAndProps 中完成。
这可不是简单的 new Object()，它要根据 Type 的不同，创建不同类型的 Fiber 节点。
function createFiberFromTypeAndProps(type, key, props, mode) {
// 1. 确定组件类型
// 如果是字符串或数字，说明是 DOM 元素
let fiberTag = HostComponent;
if (typeof type === 'function') {
// 如果是函数组件
fiberTag = FunctionComponent;
// 还要判断是 class 还是 function
if (type.prototype && typeof type.prototype.render === 'function') {
fiberTag = ClassComponent;
}
} else if (typeof type === 'symbol') {
fiberTag = ContextConsumer;
} else if (typeof type === 'object' && type.$$typeof === REACT_LAZY) {
fiberTag = LazyComponent;
}
// 2. 创建 Fiber 实例
// 这里没有引用旧的 Fiber，完全是新生的一个对象
const fiber = new FiberNode(
fiberTag,
props,
mode
);
// 3. 设置 Key 和 Ref
fiber.key = key;
if (props.ref !== null) {
fiber.ref = props.ref;
}
// 4. 如果是 DOM 元素，还要初始化 stateNode（指向 DOM 节点）
if (fiberTag === HostComponent) {
fiber.stateNode = createInstance(
type,
props,
rootContainerInstance,
domNamespace,
fiber
);
}
return fiber;
}关键点：
注意看第 2 步，我们创建了 new FiberNode(...)。这个新节点和旧节点没有任何血缘关系，没有共享任何引用。
这意味着什么？
这意味着新节点上的 stateNode（DOM 节点）是全新的。React 会通过 createInstance 在浏览器里创建一个新的 div 或者 span。
第五部分：placeChild —— 为什么不复用位置？
这是很多人最容易混淆的地方。我们销毁了旧 Fiber，创建了新 Fiber。React 会把新 Fiber 放在树的哪个位置？
在 reconcileChildren 的末尾，通常会调用 placeChild。
function placeChild(fiber, lastPlacedNode, newIndex) {
// 设置新 Fiber 的 sibling 指针
fiber.sibling = lastPlacedNode.sibling;
// 设置新 Fiber 的 return 指针
fiber.return = lastPlacedNode.return;
// 核心逻辑：更新 lastPlacedNode
// 这一步是为了让兄弟节点能找到自己的位置
lastPlacedNode.sibling = fiber;
// 这里的逻辑其实是为了计算新节点的位置索引，用于后续的插入
// 但在单节点更新的场景下，我们只需要把 fiber 插入到 workInProgress 树中
}为什么不能就地复用位置？
因为旧 Fiber 被销毁了，它的 return 指针和 sibling 指针可能已经断开了。如果你试图把新 Fiber 的 return 指针指向旧 Fiber 的 return，那新 Fiber 就会挂到错误的父节点树上，导致渲染错误。
React 必须重新构建指针链。它会把新 Fiber 作为一个“孤儿”，然后把它挂载到正确的父节点下。
第六部分：实战演练——代码中的“惨案”
为了让大家更直观地感受这个过程，咱们写个 Demo。
场景：一个列表项，初始是 div，点击按钮后变成 span。
function App() {
const [type, setType] = useState('div');
const [count, setCount] = useState(0);
return (
<div>
<button onClick={() => setType('span')}>变成 span</button>
<button onClick={() => setCount(c => c + 1)}>加一</button>
{/* 核心代码 */}
{type === 'div' ? (
<div key="item" className="box">
我是 div，计数: {count}
</div>
) : (
<span key="item" style={{ color: 'red' }}>
我是 span，计数: {count}
</span>
)}
</div>
);
}流程分析：
-
初始渲染：
- React 创建 Fiber A (
type: 'div')。 - 挂载到 DOM。
- Fiber A 的
stateNode指向<div>。
- React 创建 Fiber A (
-
点击按钮：
- React 生成新的 Fiber B (
type: 'span')。 - Diff 阶段：React 发现 Fiber A (
div) 的 type 和 Fiber B (span) 的 type 不一样。 - 销毁：React 调用
unmountFiber(Fiber A)。- 清理
useEffect。 - 执行
div.parentNode.removeChild(div)。 - Fiber A 被回收。
- 清理
- 创建：React 调用
createFiberFromTypeAndProps('span')，生成 Fiber B。 - 挂载：React 创建真实的
<span>标签，挂载到 DOM 树。 - 状态：注意看，
count是如何变化的？- 如果你直接在
div里面显示count，当你点按钮变成span时，count会重置为 0。 - 为什么？因为 Fiber B 是全新的，它的
memoizedState（保存 state 的地方）也是全新的空对象。它没有继承 Fiber A 的状态。
- 如果你直接在
- React 生成新的 Fiber B (
这就是“强制销毁”的代价！ 如果你想保留 count，你就不能换 Type，你只能改 div 里面的文本。或者，你需要用其他手段（比如 useRef）来保存状态。
第七部分：Key 的玄学——为什么 Key 相同还要销毁？
这时候肯定有老铁要反驳：“老师，你刚才说了，Key 相同说明是同一个元素，Key 相同 Type 不同，React 为什么不直接把 DOM 节点的属性改了？”
咱们来做个思想实验。
假设 React 支持“就地更新”：
- 旧节点：
<div key="user-1" className="card" onClick={handleClick}>...</div> - 新节点：
<span key="user-1" onClick={handleClick}>...</span>
如果 React 尝试原地更新：
- 它会把
div的className属性移除（因为span不支持className）。 - 它会把
div变成span标签。 - 但是，
div里面的子元素怎么办？div是块级元素，span是行内元素。如果div里面有个p标签，改成span后，那个p标签会跑到哪里去？它会变成span的子元素，但span是行内元素，它不能包含块级元素。结果就是p标签直接崩了，或者跑到了span外面。
结论：结构不兼容，绝对不能原地更新。
Key 相同意味着 React 试图“保留身份”，但 Type 不同意味着“身份属性变了”。既然属性变了，结构肯定也变了（比如从块级变行内，或者从容器变内容）。
所以，React 的策略是：“既然你都换工作了（Type变了），那原来的工位（旧DOM）就别留了，太乱了。咱们直接在旁边盖个新楼（新DOM）吧。”
第八部分：性能与安全的博弈
你可能会问：“销毁重建太慢了吧？直接改属性不是快多了吗？”
React 考虑过这个问题，但选择了安全。
- DOM 操作成本：其实，销毁一个 DOM 节点（
removeChild）和创建一个 DOM 节点（createElement），在现代浏览器中，性能开销并没有你想象的那么大。而且，React 的 Diff 算法是非常快地比较指针和引用，真正的 DOM 操作是批量提交的。 - 逻辑一致性：如果 React 允许就地更新，它会引入巨大的逻辑复杂度。它需要处理所有可能的属性冲突、子节点结构冲突、样式继承冲突。为了省那一点点 DOM 操作时间，引入 Bug 的风险太大了。
- 副作用清理：这是最根本的原因。你不能简单地“替换”一个组件。生命周期（
componentWillUnmount）、副作用（useEffect）、Ref 引用，这些都是“附着”在组件实例上的。一旦组件实例变了（Type变了），这些副作用必须被清理。原地更新（替换节点）无法触发unmount钩子。
第九部分：源码中的细节——unmountFiber 的递归与 commit
在源码中，reconcileChildren 只是协调器（Scheduler/Reconciler）的工作。它只是在内存里修改 Fiber 树的指针，创建和销毁对象。
真正的“销毁”和“创建”发生在 Commit 阶段。
在 Commit 阶段，React 会遍历 Fiber 树，找出所有被标记为 deletion（删除）和 placement（插入）的节点。
-
Deletion Pass：
React 递归遍历被标记为删除的 Fiber 节点。
它调用commitDeletion。
在这个函数里，它会：- 把 DOM 节点从父节点移除。
- 执行
unmountFiber里的逻辑（清理 Ref，清理 Effect）。 - 清理浏览器的事件监听。
-
Placement Pass：
React 递归遍历被标记为插入的 Fiber 节点。
它调用commitPlacement。
在这个函数里，它会：- 创建 DOM 节点（如果还没有创建的话）。
- 把 DOM 节点插入到正确的父节点中。
- 调用
componentDidMount或useEffect。
为什么分两步？
因为 React 必须先删除旧的，再插入新的。如果先插入新的，再删除旧的，那么在删除旧的瞬间，用户可能会看到页面闪烁（新节点闪现了一下又没了）。
第十部分：总结——React 的“断舍离”哲学
好了，老铁们，咱们今天的源码解析就到这儿。
回顾一下，当我们在 React 中遇到 Key 相同但 Type 不同 的情况时，React 的内部流程是这样的：
- 判定冲突：
reconcileChildren发现 Type 不匹配。 - 执行断交：调用
unmountFiber，递归销毁旧 Fiber 及其所有子节点。- 清理 DOM 节点。
- 清理 Ref。
- 执行
useEffect清理函数。
- 执行重生：调用
createFiberFromTypeAndProps，创建全新的 Fiber 节点。- 根据新 Type 创建新的 Fiber 对象。
- 根据新 Type 创建新的 DOM 节点。
- 重新挂载：将新 Fiber 挂载到 WorkInProgress 树的正确位置。
这个过程看起来很“暴力”，很“浪费资源”，但它保证了 React 树的结构绝对正确和副作用绝对干净。
React 就像一个极度强迫症的建筑师。如果你告诉他：“我要把承重墙（旧 Fiber）变成隔断墙（新 Fiber）”，他会二话不说，先把旧墙拆了，把地清了，再给你砌一堵新的墙。
如果你只是想刷个墙（改 textContent），那他可能会直接给你刷了。但如果你想拆墙重建，那必须得按规矩来。
所以，下次在代码里写 div 变 span，或者 ComponentA 变 ComponentB 的时候，记得心里默念一句：“React，拜托了，别给我乱动，直接删了重建吧，我信你！”
这就是 React 单节点 Diff 的核心逻辑。希望这篇文章能让你在面试的时候，不仅能说出“Type 不同要销毁”，还能说出“因为要清理副作用和 Ref，为了结构一致性，所以必须销毁”。
咱们下期再见，代码里见！