JS性能分析需规避“测不准、测不全、测了白测”，应使用Performance API、关注高频调用累积耗时、排查长任务与V8去优化，而非依赖console打点或内存快照。
JS 运行时性能分析本身不是瓶颈，但分析过程若依赖错误手段或忽视真实执行环境，反而会掩盖问题、误导优化方向。常见反模式集中在“测不准”“测不全”“测了白测”三类，规避关键在于回归主线程行为本质、用对工具、关注可复现指标。
别在生产环境用 console.time + 手动打点
这类方式看似简单，实则干扰严重：console 方法本身有开销，尤其在输出大型对象时会触发序列化和主线程阻塞；且无法捕获异步任务调度、微任务排队、渲染帧耗时等关键链路。
- 改用 Performance.mark() / Performance.measure()，它轻量、高精度、支持跨上下文关联
- 配合 PerformanceObserver 监听 longtask、layout-shift、navigation 等生命周期事件，自动采集不侵入业务逻辑
- 生产环境需关闭 console 输出，避免日志拖慢主线程
别只看单次执行时间，忽略调用频率与累积效应
一个函数单次执行 0.2ms，但如果每秒被调用 500 次，就占用了 100ms 主线程——已超 60fps 帧预算（16.6ms/帧）。很多卡顿源于高频低耗操作的叠加。
- 用 Chrome DevTools 的 Performance 面板录制真实用户交互流，重点关注 Top Down 和 Bottom Up 视图中的“Self Time”与“Total Time”比值
- 对高频回调（如 scroll、input、animationframe）加节流或防抖，或改用 IntersectionObserver / ResizeObserver 替代轮询
- 检查是否在事件监听中重复绑定、未清理，导致同一逻辑被多次执行
别把内存快照当性能证据
Heap Snapshot 能定位内存泄漏，但不能说明运行卡顿。一个内存占用稳定的应用，仍可能因长任务（long task）频繁阻塞主线程而卡死。
- 先看 Tasks 列表：筛选 >50ms 的任务，定位 JS 执行热点
- 结合 Call Tree 查看是否某函数反复调用自身（如未终止的递归）、或大量创建临时对象（触发高频 GC）
- 用 Memory 面板的 Allocation Instrumentation on Timeline 录制期间对象分配位置，确认是否在循环中无意识新建对象或字符串
别跳过 V8 引擎特性盲区
V8 对某些写法会主动放弃优化（deoptimize），比如函数内使用 eval、arguments、动态属性访问（obj[key]）、或参数类型不稳定。这类函数即使逻辑简单，实际执行也极慢。
- 用 chrome://inspect → V8 Runtime Call Stats 查看函数是否被标记为 “deoptimized”
- 避免在热路径函数中使用
eval、with、delete动态 key、或arguments.callee - 保持函数参数类型一致（如始终传 number，而非 number/string 混用），利于 IC（Inline Cache）命中
