应使用Chrome Performance面板定位函数性能瓶颈，通过Main轨道耗时块、Call Tree排序、FPS轨道悬停分析强制布局与长任务，并结合PerformanceObserver监听瞬态慢函数、Memory面板检测内存分配抖动，最后用Stats.js和Performance对比验证优化效果。
函数执行过慢，不能只看控制台报错或凭感觉猜——得用工具把“哪一行、在哪一帧、为什么慢”三层信息都挖出来。关键不是找“最慢的函数”，而是定位它在主线程中如何挤占了渲染时间、是否触发了意外布局、有没有高频内存分配拖慢帧节奏。
用 Chrome Performance 面板抓真实调用栈
这是最直接的方式，无需改代码就能看到函数在真实交互中的行为：
- 打开 DevTools → Performance → 点录制 → 执行目标操作（比如点击按钮触发该函数）→ 停止
- 重点看 Main 轨道里黄色/红色的长条：哪怕只有 20–30ms，只要出现在 16ms 帧预算内，就可能造成微观卡顿
- 点击任一耗时块 → 展开 Call Tree → 按 Self Time 排序，找到真正消耗时间的叶子函数（例如某个 getter 读取 offsetTop 触发强制布局，或 JSON.parse 在循环中反复调用）
- 鼠标悬停 FPS 轨道某帧，下方 Summary 显示 “Forced Layout” 或 “Long Task”，说明这个函数是帧内瓶颈源头
用 PerformanceObserver 主动捕获瞬态慢函数
有些函数只在特定时机执行（如 scroll 后 debounce 触发、定时器回调），手动录制容易错过。这时要靠代码监听：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 监听 longtask 类型，捕获 ≥ 50ms 的任务，并记录 startTime 和 duration，便于关联上下文
- 对可疑函数加 performance.mark() 打点，再用 performance.measure() 测量其实际耗时，比 console.time() 更精准稳定
- 示例：在函数入口和出口分别 mark，然后 measure 对应区间，可发现“看似不长，但每帧都执行 8ms”的累积型问题
结合 Memory 面板查隐性拖累
函数本身不长，但帧率仍掉？可能是它引发的内存抖动间接拖慢了主线程：
- 切换到 Memory 面板 → 开启 Allocation instrumentation on timeline → 录制操作过程
- 观察是否在函数执行期间出现密集的小对象分配（如每次调用都 new Array、生成闭包、创建 Promise 中间值）
- 这类高频分配会触发频繁 minor GC，打断渲染帧节奏，即使单次函数执行仅 10ms，也可能导致连续几帧抖动
验证优化是否真正生效
改完别急着合代码，用量化方式确认效果：
- 用 Stats.js 在页面角落实时显示 FPS 或每帧 ms 值，对比优化前后波动幅度
- 重复录制 Performance 面板，对比 Main 轨道中对应函数块的宽度、颜色深浅及是否还触发 Forced Layout
- 若函数被拆分或节流，检查 Long Task 是否消失，且 FPS 轨道绿色条是否更连续
