javascript引擎对数值运算采用多阶段流水线处理：解析生成ast、运行时动态选择smi/heapnumber表示、jit基于反馈优化整数或浮点路径、底层调用cpu单元执行，严格遵循ieee-754标准。
JavaScript 引擎对数值运算的处理并非简单执行加减乘除，而是一套由解析、类型推断、优化、执行到结果返回的多阶段流水线。不同引擎（如 V8、SpiderMonkey、JavaScriptCore）细节有差异，但核心逻辑高度一致。
词法与语法解析：识别数字字面量与运算结构
源码中的 42、3.14、0x1A 或 1e5 首先被词法分析器切分为 token，再由语法分析器构造成 AST（抽象语法树）。此时数值尚未参与计算，仅标记为 Literal 节点，并附带原始字符串和初步类型提示（如是否含小数点、指数符号）。
- 整数字面量（如
123）默认按 32 位有符号整数（int32）快速路径预判，但不立即装箱 - 浮点数字面量（如
0.1 + 0.2）触发 IEEE-754 双精度浮点数（float64）语义，但实际存储和运算可能延迟到执行阶段 - 十六进制、八进制等格式在解析时就转换为十进制 Number 值，不保留进制信息
运行时类型判定与表示选择
JS 中所有数字都属于 Number 类型，底层却根据值域和使用模式动态选择存储形式。主流引擎（以 V8 为例）采用“双类型表示”：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- Smi（Small Integer）：31 位（32 位系统）或 32 位（64 位系统，利用指针低位对齐特性）有符号整数，直接存于寄存器/栈中，无需堆分配，无 GC 开销
-
HeapNumber：超出 Smi 范围（如
2**31）、浮点数、NaN、Infinity 等，分配在堆上，是包含 double 字段的对象 - 引擎在二元运算（如
a + b）前检查操作数是否均为 Smi；若任一为 HeapNumber 或结果溢出，则降级为 float64 运算
即时编译（JIT）中的数值优化路径
函数首次执行时走解释器（如 V8 的 Ignition），多次调用后触发 TurboFan 编译。此时引擎基于反馈（feedback vector）做类型特化：
- 若某次
add操作始终接收两个 Smi，生成专用整数加法指令（如 x86 的addl），并内联检查溢出；溢出则去优化（deopt）回通用路径 - 若检测到混合类型（如
number + string），跳过数值优化，转向 ToPrimitive + 字符串拼接流程 - 常量折叠（constant folding）在早期 IR 阶段完成：
2 * 3 + 4直接编译为10，不生成运行时计算指令
底层硬件协同与精度边界
最终机器码调用 CPU 的整数 ALU 或 FPU/SSE/AVX 单元执行。关键约束来自语言规范与硬件现实的折衷：
- 所有 Number 运算遵守 IEEE-754 double 规范，但整数运算（Smi 路径）实际使用 CPU 整数单元，结果再隐式转为 double 语义
-
0.1 + 0.2 !== 0.3根源在于十进制小数无法精确表示为二进制浮点，引擎严格遵循标准，不作“魔法修复” - 位运算（
|、&、）强制将操作数转为 32 位有符号整数（ToInt32），丢弃小数部分，这步转换发生在 JIT IR 的 <code>NumberToUint32或NumberToInt32节点
理解这条流水线，有助于写出更可预测的数值代码：避免无意触发 HeapNumber 分配、减少去优化、明确区分整数与浮点意图。它不是黑盒，而是可观察、可干预的工程系统。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
