类型检查（Guard）是JIT编译器基于运行时类型反馈插入的轻量级运行时验证逻辑，用于保障推测性优化安全；其开销主要来自类型突变引发的去优化，而非检查本身。
JavaScript 原始类型在 JIT 编译器中的“类型检查（Guard）”开销，本质是引擎为保障推测性优化安全而插入的运行时验证逻辑。它不是语法层面的 typeof 或 instanceof 调用，而是编译器自动生成的轻量级条件判断，嵌入在优化后的机器码中。
类型检查（Guard）是怎么产生的
JIT 编译器（如 V8 的 TurboFan）在深度优化函数时，会基于运行时收集的类型反馈（type feedback）做出假设。例如：
- 某个参数
x在前 100 次调用中始终是number - 某个对象属性
obj.a总是整数，且obj具有固定隐藏类
此时编译器会生成特化版本的机器码：直接使用整数加法指令、按固定偏移读取属性等。但为防止后续调用传入 string 或新增属性打破假设，它必须在入口或关键路径插入 Guard —— 一条类似 if (x 的类型标签 ≠ kNumber) → 去优化 的汇编级分支。
原始类型 Guard 的特点与开销来源
-
轻量但高频：原始类型（
number,string,boolean,undefined,null,symbol,bigint）在 JS 中占比极高，其类型标签（tagged value）存储在值本身低位，检查只需一次位运算 + 分支预测，单次开销极小（纳秒级）。立即学习“Java免费学习笔记（深入）”；
-
真正开销在于分支失败：
- ✅ 多数情况下 Guard 命中，流程直通优化代码，无感知
- ⚠️ 一旦类型突变（如
x第 101 次传入"42"），触发去优化（deoptimization）：- 当前执行栈被丢弃
- 控制权交还 Ignition 解释器
- 后续重新收集反馈，可能生成新版本代码
- 这一过程涉及内存回收、上下文重建，耗时可达微秒至毫秒级，且中断执行流
-
隐式转换加剧 Guard 压力：
function add(a, b) { return a + b; } add(1, 2); // Guard: a,b 都是 number → 生成整数加法 add(1, "2"); // Guard 失败 → 去优化 → 重走解释器 → 触发字符串拼接逻辑同一函数因输入类型组合不同，可能积累多个 Guard 分支，甚至退化为多态（megamorphic）状态，使内联缓存失效。
如何降低原始类型的 Guard 开销
-
保持参数类型稳定：热函数避免混用数字与字符串调用，尤其不要依赖
+的隐式转换 -
避免意外装箱：
new Number(42)创建对象，破坏原始类型假设；应直接用42 -
结构化数据优先用字面量：
{ x: 1, y: 2 }比动态构造obj.x = 1; obj.y = 2更易维持隐藏类和类型一致性 -
必要时主动提示类型：TypeScript 编译不改变运行时，但清晰的类型声明有助于开发者规避易触发 Guard 的写法（如
any→number）
Guard 不是缺陷，而是动态语言获得接近静态语言性能的必要代价。它的存在让 JIT 敢于激进优化，而开销是否明显，取决于代码是否尊重了引擎的优化预期。
