原始类型操作本身极快且无gc开销，但其使用方式会间接影响fcp、lcp、长任务、内存趋势等指标；高频字符串拼接、数值转换、布尔判断、map键误用、闭包引用及缓存未清理等场景易引发性能问题。
JavaScript原始类型（如number、string、boolean、null、undefined、symbol、bigint）本身不涉及堆内存分配，操作极快且无GC开销，但它们在性能监控中并非“隐身”——而是通过其使用方式间接影响关键指标。真正需要关注的，是原始类型如何被组织、传递、计算，从而牵动FCP、LCP、长任务、内存趋势等可观测指标。
原始类型操作对渲染类指标的影响
原始类型变量赋值、比较、算术运算本身耗时通常在纳秒级，几乎不影响帧率或主线程。但若大量原始值参与高频计算（如循环中拼接长字符串、反复解析数字、密集条件判断），可能累积成可测量的长任务。
- 字符串拼接：用
+连续拼接10万次小字符串，在旧引擎中可能触发多次内存重分配，拖慢FCP/LCP阶段的初始化逻辑 - 数值转换：
parseInt(str)或Number(str)在输入不规范时会隐式遍历字符，若在首屏渲染路径中批量调用，可能推迟LCP完成时间 - 布尔/相等判断：深层嵌套对象的
===对比虽快，但若用于虚拟列表key生成且未缓存结果，会导致重复计算，抬高INP延迟
原始类型与内存泄漏的隐蔽关联
原始类型自身不会泄漏，但它们常作为键（key）或中间值，参与引用型结构的构建。一旦设计不当，就会成为内存滞留的“锚点”。
-
Map/WeakMap选错键类型：用对象作Map键，却把原始值（如id: string）存在闭包里持续引用该对象，导致对象无法被GC回收 - 事件监听器绑定含原始参数的箭头函数：
el.addEventListener('click', () => handler(id))，每次创建新函数，且id闭包持有外层作用域，组件卸载后仍驻留 - 缓存策略误用原始值作缓存键但未清理：例如
cache[userId] = data，而userId是字符串，若用户登出后未清空对应项，长期积累造成内存占用缓慢上升
监控中需特别标注的原始类型相关行为
这些场景不产生错误，但会在PerformanceObserver或自定义打点中暴露异常模式，值得设置专项规则：
- 高频
JSON.parse(JSON.stringify(obj))深拷贝：虽操作对象，但内部大量原始值序列化/反序列化，显著增加CPU占用和长任务频次 - 正则全局匹配后未重置
lastIndex：导致后续对同一正则的原始字符串匹配无限循环，表现为单个函数执行耗时突增（>100ms），直接触发longtask上报 - 滥用
eval或Function构造动态代码：传入的原始字符串被编译为函数，每次执行都新建作用域和闭包，堆内存分配速率陡升
实用建议：轻量识别与规避
无需为原始类型单独建监控模块，但可在已有体系中加入简单守卫逻辑：
- 对关键路径中的字符串处理函数（如URL解析、状态序列化）加
performance.mark()，对比不同长度输入下的measure耗时分布 - 在
beforeunload或路由离开钩子中，检查是否存在以原始值为键的大尺寸Map/Object缓存，记录其size并上报异常增长 - 用
performance.memory（Chrome）定期采样时，若usedJSHeapSize稳定但heapUsed / heapTotal比例持续微升，应排查是否因原始值被意外保留在长生命周期闭包中
