javascript异步压测核心是测“稳不稳”和“扛不扛”，聚焦事件循环、内存、响应确定性；需监控长任务占比≤2%、p99延迟突增、内存持续增长及gc频率异常。
JavaScript 异步编程的性能压测，核心不是测“快不快”，而是测“稳不稳”和“扛不扛”。它关注异步任务在高并发、长时运行、资源受限等压力下的行为表现，指标需紧扣事件循环、内存、响应确定性三大维度。
长任务（Long Tasks）与主线程阻塞率
这是异步压测的第一道红线。单个任务超过 50ms 就被浏览器标记为长任务，连续多个长任务会直接导致 UI 卡顿、输入无响应。
- 通过
PerformanceObserver监听longtask类型，统计单位时间内的发生频次、平均持续时长、最大单次耗时 - 重点排查：未拆分的大循环、同步 DOM 批量操作、Promise 链中嵌入 CPU 密集计算、未用
requestIdleCallback或setTimeout(0)分片的任务 - 压测目标：在峰值 QPS 下，长任务占比 ≤ 2%，且无连续 ≥3 个长任务紧邻出现
异步任务完成延迟（Latency Distribution）
不同于同步函数的执行时间，异步操作的完成时间受队列调度、微/宏任务穿插、GC 干扰等多重影响，必须看分布而非均值。
- 采集 Promise resolve/reject 时间戳（如用
performance.now()包裹fetch().then()）、async 函数await返回点 - 分析 P50/P90/P99 延迟，尤其关注 P99 是否突增——这往往暴露了微任务堆积或事件循环饥饿
- 对比相同逻辑下
setTimeout（宏任务）与Promise.resolve().then()（微任务）的延迟差异，验证调度合理性
内存增长与 GC 频率
异步代码极易因闭包持有、事件监听未清理、缓存未释放造成隐性内存泄漏，压测中会快速放大问题。
- 使用
performance.memory（Chrome）每 5 秒采样堆内存使用量，观察是否持续上升 - 结合 DevTools Memory 面板，在压测前后抓取堆快照，比对 Detached DOM、重复闭包、未注销的
EventSource或WebSocket实例 - 监控 GC 触发频率：高频 minor GC（
并发任务吞吐与失败率稳定性
异步压测本质是测试调度器与资源池的协同能力，例如 fetch 的连接数限制、Worker 线程池饱和度、自定义 Promise 队列的限流策略效果。
- 固定并发数（如 100 个并行
fetch请求），测量实际成功完成数、超时数、网络错误数 - 逐步提升并发，记录吞吐量（RPS）拐点——当 RPS 不再线性增长甚至下降，说明底层资源（如 HTTP Agent 连接池、Node.js libuv 线程池）已达瓶颈
- 检查错误类型分布：大量
TypeError: Failed to fetch可能是 DNS 或连接池耗尽；大量AbortError则说明超时设置过激或后端响应慢
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
