各位同学，大家好，欢迎来到今天的编译器实验室。我是你们的带教老师，一个在代码堆里摸爬滚打多年，头上的头发比 React 的依赖树还要稀疏的资深工程师。
今天我们不聊业务逻辑，不聊怎么把那个该死的按钮做成圆角，也不聊怎么把那个丑陋的表单变成彩虹色。今天我们要聊的是 React 的“底层黑话”，是那些藏在 npm install 背后的魔法。我们要探讨一个听起来很硬核，但实际上每天都在发生的魔法——React 指令转换协议。
简单来说，就是我们要搞清楚：那个长着 HTML 脸的 JSX，到底是怎么摇身一变，变成运行时内核能读懂的“语言”的？
第一部分：JSX 的伪装术
首先，咱们得明白一件事：浏览器其实是个很“笨”的家伙。如果你对它说 <div>Hello</div>，它大概率会一脸懵逼地给你吐个错。浏览器只认识 JavaScript，它不认识 HTML 标签，它也不认识什么 className，它只认识 document.createElement。
那么，JSX 是怎么骗过浏览器的呢？它靠的是编译器。
想象一下，你是个只会写食谱的大厨，但你必须给一个只会用机械臂的机器人做饭。你不能给机器人看“把肉切成丁”，你得给它看“输入指令：机械臂移动到坐标 X，速度 V，执行切割动作”。
JSX 就是那个“肉丁食谱”，而 Babel 或者 SWC 就是那个“翻译官”。
当我们写下这段代码时：
const App = (
<div className="container" style={{ color: 'red' }}>
<h1>Hello, World!</h1>
</div>
);在人类程序员眼里，这是优雅的 HTML 结构。但在编译器眼里，这就是一堆待处理的字符串。编译器开始工作了，它拿着语法分析器（Parser）把这段字符串拆解成抽象语法树。AST 是编译器的“乐高积木”，它把代码拆成了一个个节点。
但 AST 还不能直接扔给 React 去渲染。AST 只是“结构”，不是“指令”。我们需要一种更底层的格式，一种能让 React 的各个内核（DOM、Native、Canvas）都能听懂的通用语言。这就是我们今天要讲的主角——IR（中间表示）。
第二部分：古老的 React.createElement 协议
在 React 16 之前，或者说在 Babel 还没进化成现在这么强大的时候，这个协议非常简单，甚至有点“土味”。它基本上就是把 JSX 直接翻译成了 JavaScript 的 React.createElement 函数调用。
这是当年的“指令”格式：
const App = React.createElement(
'div', // type: 标签名
{ className: 'container', style: { color: 'red' } }, // props: 属性字典
React.createElement(
'h1',
null,
'Hello, World!' // children: 子元素
)
);大家看，这就是最早的 IR。它是一个扁平的调用栈。
为什么这种格式很烂？
因为如果页面很复杂，嵌套很深，这堆代码会堆成一座大山。而且，React 每次渲染都要重新解析这个巨大的调用栈，效率极低。就像你每次做饭都要重新把肉拿出来切，而不是直接用切好的肉。
但是，这种格式有一个巨大的优点：通用性。它不需要 React 核心库就能理解结构。你只要有一个 createElement 函数，你就能构建出树状结构。
第三部分：现代编译器与优化的 IR
随着 React 16 引入了 Fiber 架构，我们需要一种更高效的方式来表示树结构。这时候，现代编译器（Babel, SWC, Esbuild）登场了。
现在的编译器不仅仅是翻译，它们是“优化大师”。它们在生成 IR 之前，会进行一系列骚操作，比如作用域提升、死代码消除、Tree Shaking。
咱们来看看现代编译器生成的 IR 是什么样子的。虽然编译器内部使用的是更复杂的 AST 和字节码，但最终交给 React 运行时的，依然是那个核心的 ReactElement 对象结构。
现在的“指令”协议长这样：
// 编译器生成的最终产物（简化版）
const element = {
$$typeof: Symbol.for('react.element'), // 标记：这是一个合法的 React 元素
type: 'div', // 组件类型：字符串表示的 HTML 标签
key: null, // 优化键：用于列表 Diff 算法
ref: null, // 引用：用于获取 DOM 节点
props: { // 属性列表
className: 'container',
style: { color: 'red' },
children: [
{
$$typeof: Symbol.for('react.element'),
type: 'h1',
key: null,
ref: null,
props: { children: 'Hello, World!' }
}
]
},
_owner: null, // Fiber 架构下的所有者信息（React 内部用）
_store: {} // 内部状态
};看到这个 $$typeof 了吗？这是协议的灵魂。它是一个 Symbol。React 运行时在执行时，会检查这个属性。如果是 undefined 或者不是这个 Symbol，React 就会报错：“喂，你给我传了个什么东西？这不是我认识的 React 元素！”
第四部分：适配不同内核的“翻译官”
React 的厉害之处在于它的多内核适配能力。同一个 JSX，可以跑在浏览器里，可以跑在 Android/iOS 上，甚至可以跑在 Canvas 上（React Art）。
这就需要一套统一的 IR 协议，然后针对不同的内核进行“转译”。
1. React DOM 内核（浏览器端）
这是最常见的内核。它的任务是把我们的指令变成浏览器认识的 DOM 节点。
当 React 遇到 type: 'div'，它会去查找浏览器的 document.createElement('div')。当它遇到 props 里的 className，它知道浏览器不认识这个，它会自动把它翻译成 class。当它遇到 style 对象，它会遍历这个对象，把 CSS 属性一个个塞进去。
// React DOM 内核的逻辑（伪代码）
function createDOM(element) {
if (typeof element.type === 'string') {
const dom = document.createElement(element.type); // 创建 div
// 处理 props
for (const key in element.props) {
if (key === 'children') continue;
if (key === 'className') dom.setAttribute('class', element.props[key]);
else if (key === 'style') {
// 把 style 对象变成 style.cssText
dom.style.cssText = element.props[key].cssText || '';
} else {
dom.setAttribute(key, element.props[key]);
}
}
// 递归处理 children
if (element.props.children) {
element.props.children.forEach(child => {
dom.appendChild(createDOM(child));
});
}
return dom;
}
}2. React Native 内核（移动端）
到了移动端，情况就变了。React Native 不认识 DOM，它认识的是 View 和 Text。
这时候，IR 协议的 type 字段就派上用场了。编译器生成的 IR 里，type 可能不再是字符串 'div'，而是一个组件函数，或者是一个特定的标识。
// React Native 内核的逻辑（伪代码）
function createNativeComponent(element) {
// 如果 type 是字符串，映射为原生组件
const NativeType = mapStringToNativeType(element.type);
const view = new NativeType(); // 创建 View
// 处理样式
const style = transformStyle(element.props.style); // 转换为 RN 样式对象
view.setNativeProps({ style });
return view;
}这里有个大坑： 在 React Native 中，className 和 style 的处理方式与浏览器完全不同。浏览器用 CSS，Native 用 StyleSheet。编译器生成的 IR 必须包含足够的信息，让 Native 内核知道如何把这些信息映射到原生的样式系统上。
3. React Art 内核（离屏渲染）
有时候我们需要在 Canvas 上画画，或者生成图片。这时候 React 就会切换到 Art 内核。它的任务是构建一个指令序列，而不是 DOM 树。
// React Art 内核的逻辑
function createArtCommand(element) {
const ctx = getContext(); // 获取 Canvas 上下文
ctx.fillStyle = element.props.style.color;
ctx.fillRect(0, 0, 100, 100);
// ...
}第五部分：指令的优化与 Fiber 架构
早期的 React IR 是一棵树。树是很好理解的，但树很难遍历。为了解决这个问题，React 16 引入了 Fiber 架构。
Fiber 本质上是对 IR 的一种链表化改造。现在的 IR 不再是死板的树，而是一个个互相连接的节点。
// Fiber 节点的 IR 结构（简化版）
const fiberNode = {
return: parentFiber, // 指向父节点（链表结构）
child: firstChild, // 指向第一个子节点
sibling: nextSibling, // 指向下一个兄弟节点
stateNode: domElement, // 对应的真实 DOM 节点
alternate: null, // 双缓存机制用的
// ... 其他属性
};为什么要这么做？
因为现代浏览器是多线程的，或者至少是事件驱动的。我们不能一次性把整棵树算完，那样会卡死界面。我们需要把渲染任务切分成一个个小片段。
编译器生成的 IR 现在必须包含优先级信息。比如，<div> 是高优的，而 <footer> 这种在屏幕底部的元素，可以晚点渲染。
// 带有优先级的 IR 指令
const element = {
type: 'div',
priority: 0, // 0: Normal, 1: Update, 2: Suspend
props: { ... },
// ...
};React 运行时会拿着这个带有优先级的 IR，去调度器那里排队。调度器会根据优先级，决定什么时候把指令发给渲染线程。
第六部分：特殊指令与协议边缘情况
在实际开发中，我们经常使用一些特殊的语法，比如 ref，比如 key，还有那些奇怪的 dangerouslySetInnerHTML。这些在 IR 协议里是怎么表示的呢？
1. ref 指令
ref 允许我们拿到 DOM 节点的引用。在 IR 中，ref 会被保留，并传递给 FiberNode。
const inputRef = React.createRef();
const element = {
type: 'input',
ref: inputRef, // 这里的 ref 是一个对象 { current: null }
props: { value: 'test' }
};当 React 渲染完这个节点后，它会自动把 DOM 节点塞进 inputRef.current 里面。
2. key 指令
key 是列表渲染优化神器。在 IR 中，它直接作为 element.key 存在。
const items = [1, 2, 3];
const listElement = {
type: 'ul',
props: {
children: items.map(item => ({
type: 'li',
key: item, // 关键指令：告诉 React 这个节点是谁
props: { children: item.toString() }
}))
}
};如果 React 发现新进来的 IR 里有一个 key 是 2，而旧的 IR 里也有一个 key 是 2，React 就会复用那个旧的 DOM 节点，而不是销毁重建。这就像是你去理发店，理发师看到你是老客（key=2），他会直接给你修一下，而不是把你头发全剃光重新剪。
3. dangerouslySetInnerHTML
这个属性允许我们插入 HTML 字符串。在 IR 中，它是一个特殊的对象。
const element = {
type: 'div',
props: {
dangerouslySetInnerHTML: { __html: '<span>Injected HTML</span>' }
}
};React 运行时看到这个属性，会跳过正常的文本节点处理，直接把 HTML 字符串注入进去。当然，名字里带 dangerously 就是在提醒你：小心，这玩意儿不安全，别往里塞用户输入的东西，不然你的页面就挂了。
第七部分：服务端渲染（SSR）与指令的旅行
最后，咱们聊聊服务端渲染（SSR）。这是 React IR 协议最神奇的地方。
当你在服务端渲染一个组件时，React 不会去调用 document.createElement，因为它没有浏览器环境。它会生成一个JSON 字符串。
// 服务端生成的 IR 字符串
const serverString = JSON.stringify({
$$typeof: Symbol.for('react.element'),
type: 'div',
key: null,
ref: null,
props: {
children: [
{
$$typeof: Symbol.for('react.element'),
type: 'h1',
key: null,
ref: null,
props: { children: 'Hello from Server' }
}
]
}
});这个字符串被发送到浏览器。浏览器收到后，会进行Hydration（水合）。Hydration 的过程就是：拿着这个字符串，在浏览器里重新构建一遍 IR，然后对比浏览器里已经存在的 DOM。如果匹配，就复用；如果不匹配，就替换。
这就像是你提前把菜做好了（SSR），端上来的时候，你只需要加热一下（Hydration），而不是从零开始做饭。这大大提升了首屏加载速度。
第八部分：未来展望
随着 React Server Components 的推出，IR 协议正在发生变化。现在，指令不仅仅是在客户端和服务端之间传递，它还可以跨越服务器边界。
当一个组件在服务端渲染时，它可能会返回一个“指令”告诉客户端：“嘿，这个 <Image> 组件，你（客户端）去请求一下这个 URL，然后渲染它。”
这种跨边界的指令协议，让 React 的性能达到了新的高度。
总结一下（虽然我不喜欢总结，但为了完整性）
React 指令转换协议，就是 JSX 到运行时内核之间的翻译指南。
- 编译器：把 JSX 解析成 AST，再优化成 IR。
- IR 协议：规定了元素必须长什么样（
$$typeof,type,key,ref,props），确保内核能识别。 - 运行时内核：根据 IR 的指令，调用不同的底层 API（DOM、Native、Canvas）。
- Fiber 架构：把静态的 IR 改造成动态的、可调度的链表，支持并发渲染。
所以，下次当你写 <div> 的时候，别忘了，你正在编写一套精密的指令，这些指令正在跨越编译器、运行时和操作系统的鸿沟，最终在屏幕上点亮像素。这就是 React 的魔力，也是前端工程的魅力。
好了，今天的讲座就到这里。下课！记得去把你的 key 写对，别让 React 疯了！