react-scan

React Scan

使用有针对性的捕获来优化测量过的 Studio 交互。如果工作流可以复现，就不要仅凭源代码推断性能问题。

记录一次捕获

从仓库根目录开始：

bun run react-scan:capture

对于 Brand Studio，运行：

bun run react-scan:capture:brand

等待 Studio 完成构建，然后用浏览器打开打印出的 Studio URL，并等待页面稳定。React Scan WebMCP 工具仅在此开发捕获模式下注册。

调用 start_react_scan_recording，然后使用 browser-use 执行一个命名交互三次。之后立即调用 stop_react_scan_recording。保持录制时间较短，避免启动、HMR 和无关交互主导数据。调用 get_react_scan_recording，以获取原始事件和面向 Agent 的摘要。

获取录制结果后，按 Ctrl+C 停止 Studio。录制结果仅存在于 WebMCP 返回结果中；React Scan 不会将其发送到单独的 HTTP 收集器。

React Scan 激活时会替换 React DevTools 性能分析钩子通道。不要同时使用 React DevTools Timeline Profiler 进行录制。

分析证据

先阅读 get_react_scan_recording 返回的 summary。确认捕获内容包含提交事件，并检查 profilingHooksStatuses；不要把缺失的性能分析通道解读为应用处于空闲状态。

优先关注总自身持续时间较长、反复出现开销较大的渲染，或明显导致用户可见提交变慢的组件。包含持续时间涵盖子组件的工作，可能会重复计算子树，因此应先用它定位开销较大的边界，再结合自身持续时间和原始树结构找出实际工作。

将渲染原因作为证据，而不是自动给出的处方：

• parentRenderCount 较高，但相关的 prop、state、context 或 hook 均未变化，说明可能存在适合使用稳定记忆化的边界。
• prop 反复变化，说明应先检查源位置上的引用稳定性，再考虑添加记忆化。
• hook、state 或 context 的变化需要沿着所属更新追踪；用 memo() 包装组件无法阻止这些变化。
• 源位置指明了 JSX 调用位置。编辑之前，先搜索组件定义。

对于时间线位置相关的发现，在更改订阅或记忆化边界之前，也请阅读 ../studio-perf/SKILL.md。

验证优化

保留基线捕获。更改代码后，在相同视口下以相同次数录制同一交互，并与新的捕获结果进行比较。要求相关提交或组件指标有所改善，且行为没有退化。不要优化每一次重新渲染：通常，相比增加记忆化的复杂性，让必要且开销较低的渲染正常发生更可取。

报告测得的前后变化，以及为验证行为而执行的检查。