去优化陷阱指JIT编译器因运行时条件变化回退优化代码，导致性能下降。V8等引擎先收集类型信息并优化热点代码，但当变量类型改变、对象属性顺序不一、内联缓存失效或使用try-catch时，会触发去优化，丢弃高效机器码，恢复低速执行。为避免此问题，应保持类型稳定、对象结构一致、避免运行时修改原型、减少热路径中try-catch，并使用连续索引和单一类型数组，以提升代码可预测性，充分发挥JIT优化潜力。
在 JavaScript 的 JIT（即时）编译中，“去优化”陷阱指的是代码在运行时被优化后，由于某些条件发生变化，导致引擎必须将已优化的代码回退到解释执行或较低性能的版本。这会显著影响性能，甚至造成比从未优化更慢的结果。
什么是“去优化”陷阱？
JIT 编译器（如 V8）会先通过解释器运行代码，并收集类型和调用信息。当某段代码被频繁执行（即“热点代码”），引擎会将其编译为高度优化的机器码。但若后续执行中出现了与优化假设不符的情况（例如变量类型改变、函数参数类型不一致等），引擎就会触发“去优化”，丢弃优化后的代码，回到低效的执行模式。
常见引发去优化的情况包括：
- 动态类型变化：同一个变量在不同调用中使用不同类型（如先传 number，后传 string）
- 隐藏类不一致：对象属性添加顺序不同，导致无法共享相同的隐藏类
- 内联缓存失效：方法或属性访问的结构频繁变化
- 异常处理打断优化：try-catch 块中的代码通常不会被优化
一旦发生去优化，不仅损失了优化收益，还可能带来额外开销——因为引擎需要恢复执行上下文并重新解释代码。
立即学习“Java免费学习笔记（深入）”；
如何编写利于编译器优化的 JavaScript 代码？
为了让 JIT 编译器更高效地工作，应尽量保持代码的可预测性和一致性。以下是一些关键实践：
1. 保持类型稳定确保函数参数、变量和返回值的类型在多次调用中保持一致。避免在数字和字符串之间随意转换。
例如，不要这样写：
function add(a, b) {
return a + b;
}
add(1, 2); // number
add("1", "2"); // string — 触发去优化
应限制使用场景，或拆分为不同类型专用函数。
2. 使用一致的对象结构创建对象时，按相同顺序定义属性，避免后期随意增删属性。
推荐：
function createPoint(x, y) {
return { x, y }; // 始终先 x 后 y
}
避免：
const obj = {};
obj.x = 1;
obj.y = 2;
// 和
const obj = {};
obj.y = 2;
obj.x = 1; // 属性顺序不同，生成不同隐藏类
</p>
<font color="#0066cc"><strong>3. 避免在热代码中修改原型</strong></font>
<p>运行时修改原型会使得基于原型的优化失效。尽量在初始化阶段完成原型设置。</p>
<font color="#0066cc"><strong>4. 减少 try-catch 在热点路径中的使用</strong></font>
<p>try-catch 会阻止 V8 对其所在函数进行优化。如果必须捕获异常，考虑将其隔离到独立函数中。</p>
<pre class="brush:php;toolbar:false;"><code>function hotFunction() {
// 不要在这里写 try-catch
doSomething();
}
function safeCall() {
try {
hotFunction(); // 被优化
} catch (e) {
handleError(e);
}
}
5. 使用数组的最佳实践
使用数组时，避免稀疏数组和混合类型。优先使用连续索引和单一类型元素，以便引擎使用高效存储（如双精度数组）。
const arr = [1.1, 2.2, 3.3]; // 好：纯数字数组 // 而不是 const arr = []; arr[10000] = 1; // 稀疏数组，性能差基本上就这些。理解 JIT 的行为，写出结构清晰、类型稳定的代码，能有效避免去优化陷阱，充分发挥现代 JavaScript 引擎的性能潜力。
