Performance API 不支持直接监控回流次数，因浏览器未将回流暴露为 PerformanceEntry 类型；可通过监听长任务、User Timing 打点、DevTools 渲染面板及拦截强制同步布局等方式间接评估其影响。
Performance API 本身不直接提供“回流（Reflow）次数”这一指标的原生采集能力。浏览器未暴露回流事件作为 PerformanceEntry 类型，无法像监听 paint 或 longtask 那样通过 PerformanceObserver 实时捕获回流发生。这是关键前提——不是用法不对，而是规范上暂不支持。
为什么不能直接监控回流频率？
回流是浏览器渲染管线中的内部行为，属于布局计算阶段，它由样式变更、DOM操作、几何属性读取等触发，但浏览器不将其作为可观察的性能条目（entryType）上报。当前 PerformanceObserver 支持的 entryTypes（如 'paint'、'layout-shift'、'longtask'、'navigation'、'resource'）中，没有 'reflow' 或 'layout' 类型。
虽然存在 Layout Shift（通过 layout-shift 类型捕获意外布局偏移），但它反映的是视觉稳定性（CLS 指标），而非回流执行频次或耗时。
间接评估回流影响的实用方法
虽不能计数，但可通过以下方式定位和量化回流带来的性能代价：
-
监控长任务（Long Tasks）：回流常发生在主线程密集计算中。启用
PerformanceObserver监听'longtask'，若某段脚本频繁触发 >50ms 的长任务，大概率包含强制同步回流（如读取 offsetTop 后立即修改 class） -
结合 User Timing 标记可疑操作区间：在可能引发批量回流的代码前后打点，测量耗时
performance.mark('before-batch-update');<br>batchDOMUpdates(); // 如连续修改10个元素宽高<br>performance.mark('after-batch-update');<br>performance.measure('reflow-impact', 'before-batch-update', 'after-batch-update'); - 利用 DevTools 的 Rendering 面板手动验证：开启 “Paint flashing” 和 “Layout Shift Regions”，配合“FPS Meter”，可直观看到回流/重绘区域与帧率下降的对应关系，适合调试阶段定位高频源头
-
检测强制同步回流（Forced Synchronous Layout）：在开发环境注入轻量钩子，拦截常见触发属性读取（如
offsetHeight、getBoundingClientRect()），配合 console.warn 提示风险位置（注意仅用于调试，不可上线）
更有效的替代方向：预防优于监控
与其耗费精力统计回流次数，不如从代码层减少其发生：
- 批量读取几何信息（先读完所有 offsetTop/scrollWidth，再统一写样式）
- 用
transform和opacity替代 top/left/width 触发回流的动画 - 对频繁更新的 DOM 使用
documentFragment或虚拟 DOM 批量操作 - 避免在循环中读写交替（如 for { el.offsetWidth; el.style.width = ... }）
真正影响用户体验的是回流的耗时和频率叠加导致的掉帧，而不是单纯次数。关注 LCP、INP、CLS 等用户可感指标，再逆向排查是否由不当回流引起，路径更高效。
