原始类型操作本身极快，但不当使用（如循环中反复装箱、隐式转换、误用全局变量）会间接拖慢执行；应通过 performance.mark()/measure() 精确捕获其累积影响，避免 Date.now()。
原始类型（如 number、string、boolean、symbol、bigint、null、undefined）的操作本身极快，通常不构成性能瓶颈，但不当使用仍可能间接拖慢执行——比如在循环中反复装箱、隐式类型转换、或误用全局变量导致作用域链变长。分析这类问题，关键不是测“单个加法多慢”，而是看它们如何被放大、组合、嵌套，最终影响主线程调度和内存行为。
用 Performance API 精确捕获原始操作开销
浏览器原生的 performance.mark() 和 performance.measure() 是最轻量、最可信的方式，适合验证基础操作在真实上下文中的累积影响：
- 避免用
Date.now()，它精度低且受系统时钟干扰；始终用performance.now() - 对高频路径打标记，例如：
performance.mark('start-loop');<br>for (let i = 0; i < 1e6; i++) {<br> const s = 'hello' + i; // 字符串拼接（触发隐式 toString）<br>}<br>performance.mark('end-loop');<br>performance.measure('string-concat', 'start-loop', 'end-loop'); - 调用
performance.getEntriesByName('string-concat')查看毫秒级耗时，对比改用模板字面量或数组join的差异
借助 Chrome DevTools Coverage 面向实际执行路径
原始类型操作常出现在条件分支、默认值处理、类型校验等逻辑中。Coverage 面板能告诉你：哪些 typeof 判断、== 比较、?? 或 && 表达式根本没被执行过，是否冗余？是否因过度防御性编程引入了无谓开销？
- 打开 DevTools →
Ctrl+Shift+P→ 输入 “Coverage” → 启动录制 - 完整走一遍用户流程（含边界操作，如空输入、快速连点）
- 停止后查看 JS 文件中灰色未执行代码段——特别是大量
if (typeof x === 'string')或x || 'default'类型判断 - 删减或合并重复校验逻辑，可减少 JIT 编译压力与执行跳转次数
用 JSPerf 快速横向比对原始操作写法
当怀疑某类写法存在隐式成本（比如 parseInt(str) vs Number(str) vs 一元加号 +str），JSPerf 提供可控、隔离的基准测试环境：
- 访问 jsperf.com，新建测试用例
- 为每种写法单独建一个“test”，确保只测纯原始类型转换/比较/构造，不带 DOM 或异步
- 重点观察 ops/sec（每秒执行次数）和标准差：差异超 20% 即值得优化
- 示例结论：
+str通常比parseInt(str, 10)快 3–5 倍，且更安全（不截断）
警惕闭包与全局污染带来的间接损耗
原始值本身不占堆内存，但若被闭包长期持有，或意外挂到全局，会阻碍垃圾回收，拉高内存水位，间接影响所有操作响应速度：
- 用 Memory 面板拍两次堆快照：一次空闲态，一次执行完密集原始计算后 → 对比
Closure下是否有异常增长的Array或Object，检查是否因缓存了本该是局部的字符串/数字数组 - 检查是否把计数器、状态标志等原始值定义在函数外（如
let count = 0在模块顶层）→ 改为函数参数或局部const可提升 V8 优化概率 - 避免
window.cache = new Map()存大量键为字符串的缓存 → 改用WeakMap（若键是对象）或严格控制生命周期
