各位同学，大家好！欢迎来到今天的“React 内部机制深度解剖课”。
我是你们的讲师。今天我们不谈业务需求，不谈怎么把按钮做得更圆，我们谈点“硬核”的。我们今天要潜入 React 的核心代码库，去看看那个被称为“Diff 算法”的神秘黑盒。特别是当我们要处理那些看起来像迷宫一样的 Fragment，或者是嵌套得像俄罗斯套娃一样的数组时，React 是怎么保证它的“稳定性”的？
准备好了吗？让我们把 React 的源码当成一块瑞士奶酪，开始钻孔吧。
第一部分：React 是个强迫症，也是个吝啬鬼
在讲 Fragment 之前，我们得先理解 React 的世界观。React 的渲染，本质上是在做两件事：
- 计算差异： 对比旧的虚拟 DOM（Virtual DOM）树和新的虚拟 DOM 树。
- 执行更新： 只把必要的真实 DOM 节点改动掉。
React 之所以能快，是因为它极度“吝啬”。它不想去修改那些没变的东西。如果旧树里有个 div，新树里还是 div，React 会觉得：“哼，这货没变，别动它，省点力气。”
这种吝啬，就诞生了著名的“层级比较”规则。
想象一下，你面前有一棵树。React 不会从树根（根节点）开始，一层层往下数每一片叶子。它太懒了。它只会比较同层级的节点。
比如：
- 旧树：
<div><span>A</span></div> - 新树：
<div><b>B</b></div>
React 不会去对比 <span> 和 <b> 是否长得像。它只会看到 <div> 这个父节点没变，于是它就跳进了 <div> 的内部，去看看它的子节点发生了什么。如果 <div> 没了，变成了 <p>，React 才会炸毛，直接把 <div> 销毁，然后创建一个新的 <p>。
这种策略保证了算法的复杂度从 O(N³) 降低到了 O(N)。但是，这带来了一个问题：层级比较只看兄弟节点，不看上下级。
这听起来有点反直觉，对吧？但这正是 React 的精妙之处。如果它跨层级比较，那意味着你只要移动一个子节点，整个树都要重绘，那性能就崩了。
第二部分：Fragment —— 隐形人的伪装
好了，现在我们来说说 Fragment。在 JSX 里，它长这样：
return (
<React.Fragment>
<Item id="1" />
<Item id="2" />
</React.Fragment>
);或者更简单的：
return (
<>
<Item id="1" />
<Item id="2" />
</>
);很多同学会问：“Fragment 没有真实的 DOM 节点，React 怎么处理它？”
这就好比你是一个魔术师。你在舞台上把一个空的箱子递给观众，观众看得到箱子，但箱子里什么都没有。在 React 的世界里，Fragment 就是那个“空的箱子”。
关键点来了：Fragment 本身没有 key 属性。
这是 React 早期的一个设计限制。你甚至不能写 <Fragment key="foo">。为什么？因为 Fragment 是一个逻辑容器，它不渲染任何东西。如果你给它一个 key，React 甚至不知道要把这个 key 传给谁。
所以，当 React 遇到 Fragment 时，它的反应是：“哦，这是一个容器，里面装着子节点。我不需要处理这个容器本身，我直接递归处理它的子节点。”
这就引出了我们的第一个核心问题：在 Fragment 内部，React 是如何映射索引的？
第三部分：索引的陷阱与圣杯
在深入 Fragment 之前，我们必须先聊聊 key。这就像是 React 的身份证。
假设我们渲染一个列表：
const List = ({ items }) => {
return (
<ul>
{items.map((item, index) => (
<li key={index}>{item.name}</li>
))}
</ul>
);
};这里，我们使用了 index 作为 key。
场景一：列表是稳定的。
如果 items 数组的顺序永远不会变，比如是静态数据，那么使用 index 是完全没问题的。React 看到 index: 0 和 index: 1，它知道这是同一个东西，只是内容变了。它只会更新文本，不会重新创建 DOM 节点。
场景二：列表是动态的。
如果 items 是从后端拉取的，或者用户排序了，或者你插入了新数据。
// 假设 items 变成了 ['B', 'A', 'C']
// 原本: [A, B, C]
// 现在: [B, A, C]此时，React 的 Diff 算法会看着旧树和新树发呆：
- 旧节点 A (index 0) -> 新节点 B (index 0)。React 想：“咦？A 变成 B 了？好，把 A 删了，把 B 插进来。”
- 旧节点 B (index 1) -> 新节点 A (index 1)。“B 变成 A 了？删 B，插 A。”
- 旧节点 C (index 2) -> 新节点 C (index 2)。“C 没变，保留。”
结果：所有的 DOM 节点都被销毁并重建了！ 这就是“Key 失效”导致的性能灾难。
那么，Fragment 内部是如何映射索引以保证稳定性的？
答案其实很简单，也很残酷：它不能。
如果你在 Fragment 内部使用 index 作为 key，而 Fragment 内部的数组顺序发生了变化，那么 React 就会认为里面的每一个子组件都是“新来的”，从而销毁它们。
为了保证 Fragment 内部的稳定性，你必须使用稳定的 key。
比如：
const List = ({ items }) => {
return (
<React.Fragment>
{items.map((item) => (
<Item key={item.id} data={item} />
// 注意：这里用的是 item.id，而不是 index
))}
</React.Fragment>
);
};这时候，React 的 Diff 算法会看到：
- 旧 Item (id: 1) -> 新 Item (id: 1)。
- React：“哦，这是同一个组件实例！别动它！”
但是！ 这里有一个更深层的问题。如果你把 Item 组件本身拿出来，或者改变了 Fragment 的结构呢？
第四部分：嵌套数组的迷宫
现在，让我们把难度升级。我们有了 Fragment，里面还有 Fragment，里面还有数组。
const Nested = () => {
const group1 = ['A', 'B'];
const group2 = ['C', 'D'];
return (
<div>
<h3>Group 1</h3>
<ul>
{group1.map((item, idx) => (
<li key={idx}>{item}</li>
))}
</ul>
<h3>Group 2</h3>
<ul>
{group2.map((item, idx) => (
<li key={idx}>{item}</li>
))}
</ul>
</div>
);
};这个代码看起来没问题，对吧？每个 ul 里的 li 都有 key。但是，如果我们把 Fragment 的逻辑加进去呢？
const Nested = () => {
return (
<div>
<h3>Group 1</h3>
<ul>
{['A', 'B'].map((item, idx) => (
<li key={idx}>{item}</li>
))}
</ul>
<h3>Group 2</h3>
<ul>
{['C', 'D'].map((item, idx) => (
<li key={idx}>{item}</li>
))}
</ul>
</div>
);
};React 的 Diff 算法会怎么处理？
它从 <div> 开始，看到 <h3> 没变，就跳进去。它看到第一个 <ul>，发现里面的 li key 是 index。如果数组顺序没变，那就没问题。
但是，如果我们在 Fragment 里使用 map 呢？
const FragmentList = () => {
const data = [
{ id: 1, name: 'Item 1' },
{ id: 2, name: 'Item 2' },
];
return (
<React.Fragment>
{data.map(item => (
<div key={item.id}>
<h3>{item.name}</h3>
<p>Description</p>
</div>
))}
</React.Fragment>
);
};这里，React.Fragment 没有提供 Key。所以，React 的 React.Children 工具函数会介入。它会遍历 Fragment 的子节点。
关键机制：React.Children.map
React 源码里有一个非常骚的操作。当你写 {data.map(...)} 时，React 会把返回的数组包装成一个类似 Fragment 的对象，但这个对象是有结构的。
实际上，React 在处理 Fragment 时，并没有直接把 Fragment 当作一个节点。它会递归。
让我们看看 React 源码中处理 Fragment 的核心逻辑（简化版）：
// React 内部逻辑示意
function reconcileChildrenArray(current, nextChildren) {
// 这是一个非常复杂的算法，这里只讲核心思想
let resultingFirstChild = null;
let previousNewFiber = null;
for (let i = 0; i < nextChildren.length; i++) {
let child = nextChildren[i];
// 如果是 Fragment，React 会把它拆开
if (React.isValidElement(child) && child.type === React.Fragment) {
// 噻！如果遇到 Fragment，React 会直接遍历它的 children
// 所以 Fragment 的 key 传不传根本不重要，因为它是个容器
reconcileChildrenArray(current, child.props.children);
continue;
}
// 如果是普通元素，比如 <div>
let newFiber = createFiberFromElement(child);
// 这里就是映射逻辑！
// React 会根据 key 或者 index 来决定是复用还是创建
// 如果没有 key，它默认使用 index
if (newFiber.key === null || newFiber.key === undefined) {
newFiber.key = i; // 动态赋予 index 作为 key
}
// ... 复用逻辑 ...
}
}看到了吗？这就是“内部映射索引”的真相。
当你在 Fragment 里使用 map，React 内部实际上是在遍历一个数组。在这个数组遍历的过程中，React 会动态地为每一个子元素分配一个临时的 key（通常是数组索引 i）。
这保证了什么？
它保证了 React 能把新的一组子节点和旧的一组子节点对应起来。如果没有这个索引映射，React 根本不知道哪个新元素对应哪个旧元素。
但是，这带来了风险。
如果 Fragment 内部的数组顺序变了，这个动态分配的 index key 就会失效。
第五部分：如何保证稳定性？（实战篇）
现在，让我们回到最核心的问题：在 Fragment 或嵌套数组中，如何保证 Diff 算法的稳定性？
答案不是靠 React 的“魔法”，而是靠你的“数据设计”。
1. 禁止在动态列表中使用 index 作为 key
这是铁律。如果你在 Fragment 里渲染列表，一定要用唯一 ID。
// ❌ 危险！
<Fragment>
{list.map((item, i) => <Item key={i} />)}
</Fragment>
// ✅ 安全！
<Fragment>
{list.map(item => <Item key={item.id} />)}
</Fragment>2. 处理 Fragment 的 Key 传递
虽然 Fragment 本身不能有 Key，但你可以把 Key 传递给它的子元素。
<Fragment>
{list.map(item => (
<div key={item.id}> {/* 这里是关键 */}
<h1>{item.title}</h1>
<p>{item.desc}</p>
</div>
))}
</Fragment>React 的 Diff 算法会看到 div 上的 key={item.id}。它会在旧树和新树之间建立映射：{id: 1} -> {id: 1}。于是，React 会复用这个 div 节点，甚至复用里面的 h1 和 p（如果它们没变）。
3. 嵌套数组的稳定性
如果你有一个嵌套结构，比如一个父组件包含多个子组件，每个子组件内部又有一个列表：
const Parent = () => {
const groups = [
{ id: 'g1', items: [1, 2, 3] },
{ id: 'g2', items: [4, 5, 6] },
];
return (
<div>
{groups.map(group => (
<div key={group.id}>
<h2>{group.name}</h2>
<ul>
{group.items.map(item => (
<li key={item}>{item}</li> // 这里用 item 本身作为 key
))}
</ul>
</div>
))}
</div>
);
};这里，外层的 div 使用 group.id 作为 key。这保证了即使你重排了 groups 数组，React 也能正确地把 div 移动到新位置，而不是销毁重建。
内层的 li 使用 item 作为 key。这保证了即使 group.items 的顺序没变，或者你修改了数据（比如把 1 改成 10），React 也能识别出这是同一个列表项。
如果内层列表用了 index 呢？
假设 group.items 是从后端来的，顺序是不确定的：
// 假设后端返回了 [5, 1, 2, 3, 4]
// React 会认为：
// 旧 index 0 (1) -> 新 index 0 (5) -> 删除 1，创建 5
// 旧 index 1 (2) -> 新 index 1 (1) -> 删除 2，创建 1结果：整个列表闪烁，所有状态丢失。
第六部分：深入源码视角的“索引映射”
让我们稍微深入一点，看看 React 是如何处理没有 key 的 Fragment 的。这涉及到 React.Children 的映射。
当你调用 React.Children.map(children, fn) 时，React 实际上是在遍历一个数组。即使你在 JSX 里写的是 <Fragment>{children}</Fragment>，React 在内部也会把它展开。
// React.Children.map 的简化实现
function mapChildren(children, func, context) {
if (children == null) {
return children;
}
const result = [];
React.Children.forEach(children, function (child) {
if (child == null) {
return;
}
if (Array.isArray(child)) {
// 如果子节点是数组（嵌套数组）
// 递归 map
result.push.apply(result, mapChildren(child, func, context));
} else {
// 单个子节点
const mappedChild = func.call(context, child, keyIndex++, context);
if (mappedChild != null) {
if (Array.isArray(mappedChild)) {
result.push.apply(result, mappedChild);
} else {
result.push(mappedChild);
}
}
}
});
return result;
}注意看这行代码：func.call(context, child, keyIndex++, context)。
这个 keyIndex++ 就是内部映射索引的机制。
在 React 的内部实现中，即使你没有显式写 key={...}，React 也会在遍历子节点时，动态生成一个数字索引作为 key。这是为了确保 Diff 算法能正常运行。
但是！ 这个内部索引是瞬态的。它依赖于遍历顺序。一旦遍历顺序变了，这个索引就变了，Diff 算法就会崩溃。
特殊情况：条件渲染
这是一个非常常见的坑。你在一个 Fragment 里做条件渲染：
const ConditionalList = ({ showA, showB }) => {
return (
<React.Fragment>
{showA && <Item id="A" />}
{showB && <Item id="B" />}
</React.Fragment>
);
};如果 showA 变为 false，showB 变为 true，那么渲染顺序就是 [B]。React 会认为：
- 旧：[A]
- 新：[B]
- 结果：销毁 A，创建 B。
这看起来没问题，因为它们内容不同。但是，如果你在 Item 组件里用了 useEffect 或 useState，状态全丢了！因为 React 认为它们是完全不同的组件实例。
修复方法：
- 使用
key强制 React 保持引用（虽然在这种动态条件下不太推荐，因为会导致组件重新挂载）。 - 更好的做法是：不要在 Fragment 里做这种剧烈的顺序变化。如果顺序会变，确保每个元素都有唯一的、稳定的 key。
第七部分：总结与建议
好了，同学们，今天的讲座接近尾声。我们聊了很多，从 Fragment 的隐形身份，到嵌套数组的迷宫，再到 React 内部那个神秘的 keyIndex++。
让我们总结一下在 Fragment 或嵌套数组中，如何保证 Diff 算法稳定性的核心原则：
- Fragment 本身是透明的： 它没有 DOM 节点，也没有 key。React 直接透传给它的子节点。如果你在 Fragment 里渲染列表，列表元素必须有 key。
- 索引是脆弱的： React 内部会使用索引来映射子节点，但这只在你保证数据顺序不变时才有效。一旦数据重排，索引映射就会失效，导致全量 Diff。
- 嵌套数组要小心： 在嵌套结构中，每一层的 key 都必须稳定。外层 Key 保证父组件的位置，内层 Key 保证列表项的内容。
- 动态渲染是大忌： 避免在 Fragment 内部使用三元运算符或条件渲染来改变节点列表的结构，除非你明确知道自己在做什么。
最后，给各位的“防坑指南”：
- 检查清单： 每次你写
map，或者map的嵌套，或者map包裹在Fragment里，停下来问自己一个问题：“如果这个数组的顺序变了，我的界面会崩吗？” - ID 是王道： 除非数据是纯静态的，否则永远使用唯一标识符（ID、UUID）作为 key，而不是数组索引。
- 拥抱 Fragment： Fragment 本身是为了解决“多根节点”的问题，它本身不会引入性能瓶颈，滥用 key 才是。
希望今天的讲座能让你对 React 的内部世界多了一分理解。记住，React 是一个基于数据驱动的库。你的数据越稳定，React 的 Diff 算法就越开心，你的应用也就越流畅。
下课！