JS性能分析思维导图应围绕“发现问题→定位瓶颈→验证优化”动线组织，聚焦DevTools实操路径：Performance面板看Flame Chart、Memory面板比堆快照、Application查缓存、Console打点；分解析编译、执行、内存、异步四阶段对应典型问题；右侧设“症状→根因→改法”速查区；底部配Lighthouse→Performance录制→Sources调试→局部替换的轻量验证闭环。
画 JS 运行时性能分析的思维导图，关键不是罗列所有 API，而是围绕“发现问题 → 定位瓶颈 → 验证优化”这条真实调试动线组织内容。重点突出浏览器 DevTools 的实操路径、常见性能陷阱的特征表现，以及代码层面可干预的节点。
核心维度：从执行流程切入
把 JavaScript 运行时拆成四个可观测阶段，每个阶段对应一类典型问题：
- 解析与编译：关注脚本体积、语法复杂度、eval/use strict 影响；大 bundle、过多内联脚本会拖慢首次解析
- 执行（主线程）：聚焦长任务（>50ms）、同步阻塞、频繁重排重绘（layout thrashing）、低效循环或递归
- 内存生命周期：识别内存泄漏模式——闭包意外保留 DOM 引用、事件监听器未解绑、定时器未清除、全局变量缓存过大
- 异步调度：检查微任务堆积（如大量 Promise.then 链）、宏任务滥用（setTimeout 嵌套）、requestIdleCallback 使用不当
工具链锚点：以 Chrome DevTools 为基准
思维导图中每个性能问题都应绑定一个可直达的调试入口：
- Performance 面板：录制后看 Flame Chart，重点关注 Tasks、Rendering、Paint 区域的宽度和堆叠深度
- Memory 面板：用 Heap Snapshot 对比前后快照，筛选“Retained Size”大的对象，追踪 Detached DOM tree
- Application 面板 → Service Workers / Cache：排查资源缓存失效、sw 更新卡顿引发的 JS 重复加载
- Console 中 performance.mark() + performance.measure()：对关键函数段做自定义打点，替代 console.time
高频反模式与修复示意
导图右侧可设“典型症状→根因→改法”三栏式速查区：
- 页面滚动卡顿 → 监听 scroll 未节流 + 每次触发 getBoundingClientRect → 改用 passive: true + requestAnimationFrame + 缓存测量结果
- 首屏白屏时间长 → 主包含大量未拆分的第三方库 + 无 code-splitting → 拆分 vendor chunk，用 dynamic import() 懒加载非首屏逻辑
- 内存持续上涨 → 绑定事件的组件卸载后未 off()，且回调里引用了外部大对象 → 改用 AbortController.signal 控制监听器生命周期
- CPU 占用高但无长任务 → 微任务队列被 Promise.allSettled 或大量 then 链撑满 → 改用 queueMicrotask 分批处理，或降级为 setTimeout(0)
轻量验证闭环：不依赖完整监控体系
导图底部建议一条最小可行验证路径：
- 用 Lighthouse 跑一次 Performance 分数，记下最差项（如 “Avoid large layout shifts”）
- 在 Performance 面板中复现该操作，定位耗时 Top 3 函数
- 在 Sources 面板打断点，观察参数、调用栈、作用域变量大小
- 局部替换（如用 for 替代 forEach、用 Set 替代 includes 数组查找），再测对比
