可利用console.count与console.time组合在渲染函数埋点，识别高频无效重渲染：通过“快而频”特征（如每秒20+次、单次0.1ms）定位未memo、父组件传新引用或Context频繁变更问题。
可以利用 console.count 和 console.time/console.timeEnd 的组合，在组件渲染函数中埋点，快速识别哪些组件被高频、重复、非必要地执行了 render（尤其是无状态或 props 未变时）。关键不是单纯计数，而是结合时间标记，判断“是否在短时间内密集触发且耗时微小”，这往往是无效重渲染的典型特征。
在关键渲染入口打点：count + time 同步启动
在函数组件的顶层、类组件的 render 或 useEffect 前置逻辑中，同时调用：
-
console.count('MyComponent')—— 累计该组件本次生命周期内被调用次数； -
console.time('MyComponent-render')—— 启动计时器（同名 timer 可复用）；
注意：不要在 useEffect 内启动 time，它不覆盖 render 阶段；若想测完整更新链路（含 effect），可在 useLayoutEffect 开始处 time，在下一个微任务（如 Promise.resolve().then(() => console.timeEnd(...))）中结束 —— 但通常聚焦 render 阶段已足够定位问题。
用命名区分上下文，避免计数混淆
直接写 console.count('MyComponent') 容易掩盖多实例或不同触发源。建议加入关键上下文标识：
-
console.count(`MyComponent [props.id=${id}]`)—— 区分不同实例； -
console.count(`MyComponent [reason=state-update]`)—— 结合useState更新来源标注； -
console.count(`MyComponent [parent=List]`)—— 标明父组件触发路径。
这样在控制台展开后，能一眼看出是某个 ID 的组件被刷了 50 次，还是所有实例都被连带重绘。
结合 timeEnd 判断“快而频”是否异常
在 render 函数末尾（或 return 前）调用 console.timeEnd('MyComponent-render')。观察控制台输出：
- 如果某组件每秒触发 20+ 次
count，但每次timeEnd显示仅0.1ms，基本可断定：没做 memo、父组件盲目传新对象/函数、或 Context 值频繁变更； - 若某次
timeEnd突然飙到8ms且伴随 count 跳变，说明这次可能触发了真实 DOM diff 或 layout 计算，需重点检查该次输入差异； - 用浏览器 Performance 面板录制，筛选
console.time事件，能对齐 JS 执行帧，确认是否卡在 render 阶段。
配合 shouldComponentUpdate / React.memo 快速验证优化效果
发现高频渲染后，加一层浅比较防护：
- 类组件：在
shouldComponentUpdate(nextProps)中console.count('SCU-check')，并返回!shallowEqual(this.props, nextProps)； - 函数组件：包裹
React.memo(MyComponent)，并在其内部 render 头部加console.count；若加 memo 后 count 归零或骤降，说明此前确实是 props 引用变化导致； - 注意：若 memo 后 count 仍高，说明子组件自身状态（
useState）、useReducer或外部 Context 在持续触发更新，需继续向上溯源。
