运行时性能分析聚焦js真实执行表现，核心测cpu占用、主线程卡顿（≥50ms为长任务）、帧率稳定性（≤16.6ms/帧）、内存泄漏趋势及node.js事件循环健康度。

运行时性能分析，就是观察 JavaScript 代码在真实执行过程中“跑得怎么样”——不看打包体积、不看语法对错，只盯它在浏览器或 Node.js 里实际占用多少 CPU、卡不卡主线程、内存涨没涨、帧率稳不稳。核心是测执行、抓瓶颈、看影响。

chartjs-reporter

此技能用于在用户需要将结构化数据（查询结果、CSV 摘要、JSON 记录或 Python 字典/列表）转换为独立的 HTML 页面时使用。

下载

主线程是否被长时间霸占

浏览器 UI 渲染和事件响应都依赖主线程，一旦某段 JS 运行 ≥50ms，用户就会感知卡顿。这就是长任务（Long Tasks）： - 使用 PerformanceObserver 监听 entryTypes: ['longtask'] 可捕获每个超时任务 - 每个条目含 startTime、duration 和 attribution（能定位到具体脚本或框架） - 开发中可在 DevTools → Performance 面板录制后查看“Main”轨，黄色/红色长条即为风险点

FPS 与帧耗时是否稳定

动画或滚动流畅的底线是每帧 ≤16.6ms（对应 60fps）： - 用 requestAnimationFrame 套壳计时，持续记录帧渲染耗时 - DevTools Performance 面板的“Frames”轨会标出掉帧（红色块），点击可查对应 JS 执行栈 - 若连续多帧 >20ms，大概率存在布局抖动、强制同步样式计算或未优化的重绘逻辑

内存是否在悄悄泄漏或过度消耗

内存问题往往滞后爆发，但监控必须前置： - 浏览器端可通过 performance.memory（需开启 flag）或 DevTools Memory 面板拍堆快照比对 - Node.js 端调用 process.memoryUsage() 查 heapUsed 和 heapTotal，长期高于 70% 堆限制需警惕 - 关键不是绝对数值，而是趋势：对象数量持续上升 + GC 频次增加 = 典型内存泄漏信号

事件循环是否健康

Node.js 尤其关注这点，因为阻塞事件循环等于拒绝所有新请求： - 用 perf_hooks 的 monitorEventLoopDelay() 测延迟，理想值 console.time() 在可疑函数前后打点，快速验证耗时分布

不复杂但容易忽略