JavaScript原始类型包括undefined、null、boolean、number、string、symbol和bigint共7种，引用类型统称为object，包含数组、函数、日期等；typeof适用于判断原始类型但对null返回"object"属历史bug，instanceof用于检测引用类型实例，Object.prototype.toString.call()和Array.isArray()可精准识别引用类型。
原始类型操作（如数字计算、布尔判断、字符串拼接、属性访问）的性能差异虽小，但高频调用时会放大影响。可靠测试不能靠单次 performance.now() 或 console.time()，必须控制变量、消除干扰、多次采样并分析误差。
用 Benchmark.js 做稳定对比
这是目前最稳妥的方式，它自动完成热身、JIT 预热、循环次数自适应调整，并输出带误差范围（±%）的结果。
- 安装：
npm install benchmark（Node 环境）或通过 CDN 引入浏览器环境 - 结构要点：创建
Suite→add多个命名函数 → 绑定cycle和complete事件 → 调用run({ async: true }) - 关键看 Hz（每秒执行次数） 和 ±%（相对标准误差）；若误差 >1.5%，说明环境不稳定，需重测
- 原始类型测试中，务必避免在被测函数内写
console.log、Math.random()、Date.now()等副作用操作
准备数据要“体外化”
原始类型本身轻量，但测试过程容易被无关开销污染。例如测 a + b 和 a.concat(b)（字符串），不能每次都在函数里生成新字符串。
- 所有输入值（如
let a = 'hello'; let b = 'world';）应在add之前定义好 - 避免在测试体中做属性读取以外的 DOM 操作、对象创建、闭包捕获等——这些不属于原始类型操作范畴
- 比如测
obj.propvsobj['prop']，应提前构造好obj，只把访问语句放进测试函数
覆盖典型访问模式与边界情况
原始类型性能对上下文敏感。同一操作在不同场景下表现可能相反。
- 属性访问：对比
obj.x、obj['x']、obj?.x，分别用普通对象、带 getter 的对象、稀疏对象测试 - 数值运算：测
i++vsi += 1vsi = i + 1，注意 V8 对后两者常做相同优化，但某些旧引擎仍有差异 - 字符串比较：短串（=== vs
==vslocaleCompare - 布尔转换：测
!!x、Boolean(x)、x == true在null、0、''、[]等值上的实际开销（注意：语义不同，仅比纯转换路径）
结合 DevTools 验证执行细节
Benchmark.js 告诉你“谁快”，Chrome DevTools Performance 面板能告诉你“为什么”。尤其适合排查原始类型操作背后的隐藏成本。
- F12 → Performance → Record → 执行你的基准测试函数 → 停止后看火焰图
- 重点关注：脚本执行是否出现长任务（>50ms）、是否存在意外的 GC（垃圾回收）标记暂停、调用栈是否意外深层嵌套
- 例如测
map.get(key)，火焰图可能暴露 key 类型（Symbol vs string）导致的哈希计算差异；测obj.x可能发现 getter 触发了意外计算 - 开启 “JavaScript samples” 和 “Memory” 录制，确认没有隐式装箱（如
new Number(42)）或临时字符串创建
