渲染掉帧排查，性能记录要能定位到组件
复杂看板、长列表和画布出现交互卡顿时，Long Task 只能说明主线程忙，无法直接指出是哪个 React 子树造成的。此时不宜先给所有组件套React.memo；应先捕获更新发生的阶段和组件树的渲染开销。
本文使用 React 的<Profiler>与可观测平台关联慢渲染记录。Profiler 数据需要结合浏览器的长任务、布局和脚本火焰图判断，不能单独等同于用户感知的卡顿。
React 渲染测量原理与 Profiler 采集管线
React 的渲染可以分为两个阶段：
- Render 阶段：计算 Fiber 树节点的 Diff，决定哪些 DOM 节点需要更新。这个阶段会被并发调度切碎，但总 CPU 耗时依然存在。
- Commit 阶段：React 将变更写入真实 DOM 并调用
useLayoutEffect/useEffect。
传统console.time()只能测量外层函数的执行耗时，根本捕获不到并发更新（Concurrent Mode）下组件被多次 Re-render 的真实阶段。
React 官方提供的<Profiler>组件可以在 Commit 阶段精准回调onRender函数，暴露出actualDuration（渲染当前批次耗时）与baseDuration（不使用 memo 时的预计全量渲染耗时）。
该管线可以为超过阈值的组件树更新附上组件 ID、阶段和耗时。16.6ms 是 60Hz 屏幕的一帧预算，不同刷新率、交互优先级和页面工作量会影响阈值选择。
生产级 React Profiler 可观测组件实现
下面是我们封装的生产级<TraceProfiler>组件代码。采用 React 18 + TypeScript 编写，支持按阈值过滤、采样率控制以及与 OpenTelemetry Span 的无缝对接。
import React, { Profiler, ProfilerOnRenderCallback, ReactNode } from "react"; import { trace, SpanStatusCode } from "@opentelemetry/api"; export interface TraceProfilerProps { id: string; // 组件树唯一标识，如 "GanttChartTree" thresholdMs?: number; // 告警阈值，默认 16.6ms (掉帧门禁) sampleRate?: number; // 采样率 0.0 - 1.0 children: ReactNode; } const tracer = trace.getTracer("react-performance-profiler", "1.0.0"); export const TraceProfiler: React.FC<TraceProfilerProps> = ({ id, thresholdMs = 16.6, sampleRate = 1.0, children, }) => { const handleRender: ProfilerOnRenderCallback = ( profilerId, phase, actualDuration, baseDuration, startTime, commitTime ) => { // 采样率过滤 if (Math.random() > sampleRate) return; // 只有当实际渲染耗时突破掉帧阈值时，才留存现场 Trace 证据 if (actualDuration >= thresholdMs) { const span = tracer.startSpan(`React_Render_SlowTask:${profilerId}`, { startTime: startTime, }); span.setAttributes({ "react.profiler.id": profilerId, "react.profiler.phase": phase, // "mount" | "update" "react.profiler.actual_duration_ms": actualDuration, "react.profiler.base_duration_ms": baseDuration, "react.profiler.commit_time": commitTime, "react.profiler.actual_to_base_ratio": baseDuration > 0 ? actualDuration / baseDuration : 1, "user_agent": typeof navigator !== "undefined" ? navigator.userAgent : "unknown", }); if (actualDuration > 50) { span.setStatus({ code: SpanStatusCode.ERROR, message: `严重的卡顿任务: [${profilerId}] ${phase} 阶段耗时 ${actualDuration.toFixed(2)}ms`, }); } else { span.setStatus({ code: SpanStatusCode.OK }); } console.warn( `🚨 [React Profiler] 检测到组件树 [${profilerId}] 慢渲染! Phase: ${phase}, Actual: ${actualDuration.toFixed( 2 )}ms, Base: ${baseDuration.toFixed(2)}ms` ); span.end(commitTime); } }; return ( <Profiler id={id} onRender={handleRender}> {children} </Profiler> ); };用证据定位重渲染来源
例如，搜索输入导致表格整体更新时，可先在表格树外包一层 Profiler，并在浏览器性能面板中确认输入、脚本和渲染的时间关系。actualDuration接近baseDuration往往说明本次更新没有跳过太多工作，但它不是memo是否失效的充分证据；baseDuration是估算值，也会随组件树变化。
若发现 Context value 每次渲染都创建新对象或函数，应检查这是否扩大了订阅更新范围，例如：
// 罪魁祸首：匿名函数在每次 render 时重新生成引用 <TableContext.Provider value={{ search: (val) => doSearch(val) }}>可通过useCallback、useMemo稳定 Context value 中确需稳定的引用，或将高频的searchInputValue拆到更小的 Context。改动后需要在同一数据量、浏览器和输入脚本下重新采样，并确认搜索结果和无障碍行为没有回归。
三个使用注意点
memo是否有效要结合 props、Context 订阅和 Profiler 数据判断。- 线上使用 Profiler 前应以采样方式验证开销；采样率取决于流量、隐私要求和监控预算。
- 慢渲染记录应带组件 ID、路由、版本和匿名化上下文，才能与 Long Task 等证据关联。
