Sanity React Profiling 实战:用 agent-react-devtools profile 命令组定位与修复慢交互【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity本文以 Sanity 仓库内.agents/skills/react-devtools/references/profiling-guide.md的 profiling 工作流为核心,完整讲解如何用agent-react-devtoolsCLI 对运行中的 React 应用做组件级性能分析:从建立基线、录制交互、解读profile slow/profile rerenders/profile report输出,到导出 JSON 并用profile diff对比前后两次会话验证优化效果。文中所有命令均可直接复制执行,并结合 Sanity 仓库中dev/test-studio的真实接入配置(dev/test-studio/sanity.cli.ts)说明了该工具在大型内容工作室(CMS)这类组件密集应用中的落地方式与注意事项。工具背景:为什么用 CLI 做 React 性能分析agent-react-devtools是一个通过 React DevTools 协议连接运行中 React / React Native 应用的命令行工具,把组件树、props、state、hooks 和 profiling 数据以 token 高效的文本格式暴露出来,专为人机协同调试场景设计——开发者(或 AI Agent)可以直接在终端里回答这个组件为什么重渲染哪个组件渲染最慢这类问题。其完整能力描述见 SKILL.md,完整命令参考见 commands.md,连接方式说明见 setup.md。工作机制上:一个本地 daemon 监听 WebSocket(默认端口 8097),React 应用通过注入的 connect 脚本注册到 daemon,CLI 则通过 IPC 与 daemon 通信。对 Web 应用而言,npx agent-react-devtools init会自动探测框架(Vite / Next.js / CRA / Expo)并注入最小配置;对 Vite 项目,它只是在配置中追加一个插件:// vite.config.ts import {reactDevtools} from agent-react-devtools/vite export default defineConfig({ plugins: [reactDevtools(), react()], })该插件仅在 dev 模式生效,会在应用代码加载前注入 connect 脚本,无需改动任何业务代码。Profiling 数据来自 React DevTools Profiler 协议,profile export导出的 JSON 可直接导入 React DevTools 的 Profiler 标签页做可视化分析。快速开始profiling-guide 给出的最小闭环是三步:开始录制、触发慢交互、停止并查看最慢组件:agent-react-devtools profile start # Trigger the slow interaction (type, click, navigate) agent-react-devtools profile stop agent-react-devtools profile slow --limit 5注意一个关键前提:profiling 只捕获profile start与profile stop之间发生的渲染。用户报告慢的那次交互(输入、点击、路由跳转)必须落在这个窗口内,否则采集到的只是一堆无关渲染。分步工作流1. 建立基线开始 profiling 前先确认当前状态,避免对着空的或未连接的应用做无效录制:agent-react-devtools status # Confirm app is connected agent-react-devtools count # How many components are mounted agent-react-devtools get tree --depth 3 # Understand the structurestatus输出 daemon 状态、已连接应用数、组件总数与最近事件;若显示Apps: 0 connected,说明 React 应用尚未注册,需检查 dev 模式是否开启、控制台是否有 WebSocket 报错、端口 8097 是否被其他实例占用(详见 setup.md 的排查清单)。count按组件类型统计(如42 components (fn:25 host:12 memo:3 cls:2)),给你一个有多少组件会被渲染的量级感。get tree --depth 3用缩进树打印组件层级。组件树节点带有稳定标签(c1、c2……),后续所有 profiling 命令都通过这些标签引用组件;类型标记fn/cls/host/memo/fRef/susp/ctx分别表示函数组件、类组件、DOM 元素、React.memo包裹、forwardRef、Suspense 与 Context。大应用中务必用--depth限制深度,避免输出爆炸。2. 录制目标交互开始录制时给它起个有语义的名字,方便日后在多次会话中区分:agent-react-devtools profile start typing in search然后由用户执行(或用 agent-browser 等浏览器驱动工具程序化地执行)被报告为慢的那次交互。注意同一时刻只能有一个活跃的 profiling 会话。完成后停止:agent-react-devtools profile stopstop会从 React 收集数据并打印摘要(时长、commit 次数、渲染最多的组件)。3. 识别瓶颈:两个互补的视角识别慢组件时,guide 强调要用两个互补的视图,而不是只看其一:最慢组件—— 哪些组件单次渲染耗时最长:agent-react-devtools profile slow --limit 5按平均渲染时长降序排列,输出列包含标签、类型、组件名、平均时长、最大时长、渲染次数、渲染原因与 changed keys。典型输出:Slowest (by avg render time): c3 [fn] ExpensiveList avg:12.3ms max:18.1ms renders:47 causes:props-changed changed: props: items, filter c4 [fn] TodoItem avg:2.1ms max:5.0ms renders:94 causes:parent-rendered, props-changed changed: props: onToggle渲染最频繁组件—— 哪些组件渲染次数过多:agent-react-devtools profile rerenders --limit 5这两个视图互补的直觉来自 guide 中给出的算例:一个组件渲染 100 次、每次 0.1ms 总耗时 10ms —— 这是重渲染问题(次数太多),优化方向是减少不必要的渲染;一个组件渲染 2 次、每次 50ms 总耗时 100ms —— 这是慢渲染问题(单次太重),优化方向是减轻单次渲染的计算量。两者总耗时可能相近,但修复手段完全不同,所以必须两个命令都跑。4. 深入具体组件:解读渲染原因锁定嫌疑组件后,用profile report获取它的完整渲染报告:agent-react-devtools profile report c12报告会列出全部渲染原因(cause)与具体触发渲染的 changed keys,例如changed: props: onClick, className state: count。changed keys 直接告诉你该稳定化(stabilize)什么。guide 给出的原因对照表是解读这份输出的核心:CauseChanged keys 示例含义典型修复parent-rendered(无)父组件重渲染,子组件未能 bail out用React.memo()包裹子组件props-changedprops: onClick, style收到了新的 prop 引用在父组件用useMemo/useCallback稳定化列出的 propstate-changedstate: count, filter组件自身 state 变化检查列出的 state 更新是否必要hooks-changedhooks: #0, #2某个 hook 的依赖变化审查按索引列出的 hook 的依赖数组first-mount(无)首次挂载正常现象,不是问题除上表六类原因(props-changed、state-changed、hooks-changed、parent-rendered、force-update、first-mount)外,聚合报告(profile slow/profile rerenders/profile report)会对同一组件跨多次 commit 的 changed keys 去重,因此看到的 keys 是该组件在整个会话内触发过渲染的全部字段。若 React DevTools 无法定位到具体字段,changed:后缀会被省略。5. 检查组件当前的 props 与 hooks有了原因假设,再用get component查看该组件当下的实际数据,验证什么在变:agent-react-devtools get component c12输出形如:c3 [fn] TodoList props: items: [{id:1,text:Buy milk},{id:2,text:Walk dog}] onDelete: ƒ state: filter: all hooks: useState: all useMemo: [...] useCallback: ƒ其中ƒ表示函数值,超过 60 字符的值会被截断。guide 建议重点关注:函数 prop(ƒ)—— 若父组件未用useCallback包裹,每次渲染都是新引用;对象/数组 prop—— 若未用useMemo包裹,每次渲染都是新对象;更新过于频繁的 state—— 结合state-changed原因交叉验证。这一步把第 4 步的嫌疑落到具体数据上:看到onDelete: ƒ这类 prop,配合profile report报出的changed: props: onDelete,即可确认修复点。6. 修复并用同样交互复测应用修复后,用完全相同的交互再录一次,对比渲染次数与时长:agent-react-devtools profile start after fix # Same interaction agent-react-devtools profile stop agent-react-devtools profile slow --limit 5肉眼对比两次输出的 renders 计数与 avg/max 时长即可确认改进。如果前后差异较大或需要留档,使用下一节的导出 diff 工作流。导出与 Diff 工作流导出 profiling 数据停止一次 profiling 会话后,可以把数据导出为 JSON 文件。该文件既可导入 React DevTools 的 Profiler 标签页做可视化分析,也可作为profile diff的输入:agent-react-devtools profile stop agent-react-devtools profile export baseline.json对比两次会话要识别回归(regression)或验证改进,在改动前后各录一次并 diff:# Before the change agent-react-devtools profile start before # ... interact with the app ... agent-react-devtools profile stop agent-react-devtools profile export before.json # After the change agent-react-devtools profile start after # ... same interaction ... agent-react-devtools profile stop agent-react-devtools profile export after.json # Compare agent-react-devtools profile diff before.json after.jsondiff 输出会把组件分为 regressed(变慢)、improved(变快)、new(新增)、removed(消失)四类。两个参数用于调灵敏度:--threshold—— 变化百分比阈值,默认5%,低于该比例的变化不报告;--limit—— 限制每个类别展示的组件数量。profile diff是纯离线对比,不需要 daemon 处于运行状态,因此可以拿到 CI 环境或另一台机器上跑,把 before/after 文件当作性能快照归档。常见性能问题清单guide 结尾把 profiling 中最高频的四类问题归纳如下,可作为解读结果的速查表:1. Context 或上提 state 引发的级联重渲染父组件因定时器或 context 变化重渲染,所有子组件跟随重渲染,因为没有任何一层用了React.memo。特征:profile rerenders中出现大量parent-rendered原因的组件,且渲染次数随交互次数线性放大。2. 不稳定的 prop 引用父组件内联传递onClick{() ...}或style{{...}},每次渲染都产生新引用,直接击穿子组件的memo()。子组件显示props-changed原因,即便 prop 的值在语义上完全没变。changed:输出会精确指出是哪个 prop 在捣乱(如changed: props: onClick, style),修复时在父组件对相应 handler/对象使用useCallback/useMemo。3. 未记忆化的昂贵计算组件在每次渲染中重复做过滤、排序、格式化等重活,表现为profile slow中的高平均渲染时长,而渲染次数本身并不高。修复:用useMemo缓存计算结果,让计算只在输入变化时发生。4. Effect 中更新 state 造成的渲染循环某个 effect 在每次渲染后都更新 state,导致不必要的 commit 循环。特征:用profile timeline查看 commit 序列时发现 commit 数量异常偏高。agent-react-devtools profile timeline --limit 10 --offset 0 # 按时间序分页浏览 commit agent-react-devtools profile timeline --sort duration --limit 5 # 最贵的 5 个 committimeline默认按时间序输出(默认 limit 20),每次交互往往伴随多个 commit;若单个用户动作触发了远超预期的 commit 数,通常就是 effect 循环或高频 state 更新的信号。进一步用profile commit N查看指定 commit 的逐组件耗时、原因与 changed keys。在 Sanity 仓库中的真实接入上述工作流并非纸面方案。Sanity 仓库的测试工作室dev/test-studio已把agent-react-devtools作为正式的性能诊断通道接入,可以直接作为大型内容应用(组件数量远超小 demo)的参考实现。接入方式:在 dev/test-studio/sanity.cli.ts 中,vite配置函数根据环境变量ENABLE_REACT_DEVTOOLS条件性地注入插件——// dev/test-studio/sanity.cli.ts(节选) const isReactDevtoolsEnabled process.env.ENABLE_REACT_DEVTOOLS true // ... if (isReactDevtoolsEnabled) { const {reactDevtools} await import(agent-react-devtools/vite) nextConfig mergeConfig(nextConfig, {plugins: [reactDevtools()]}) }采用懒导入 环境变量开关,保证不启用时agent-react-devtools完全不进入构建依赖链。该开关对应仓库根 package.json 中的脚本:pnpm react-devtools:test-studio # 即 ENABLE_REACT_DEVTOOLStrue pnpm dev:test-studio:studio完整操作序列来自 AGENTS.md 的 Profiling studio re-renders with React DevTools 小节:# 1. 启动 daemon(端口 8097) pnpm --filter sanity-test-studio exec agent-react-devtools start # 2. 以注入 connect 脚本的方式启动工作室(隐含 ENABLE_REACT_DEVTOOLStrue) pnpm react-devtools:test-studio # 3. 浏览器打开 http://localhost:3333,然后确认应用已注册 pnpm --filter sanity-test-studio exec agent-react-devtools status # 4. 录制一次交互 pnpm --filter sanity-test-studio exec agent-react-devtools profile start # ... 与工作室交互 ... pnpm --filter sanity-test-studio exec agent-react-devtools profile stop pnpm --filter sanity-test-studio exec agent-react-devtools profile rerenders --limit 10依赖侧,dev/test-studio/package.json 同时声明了agent-react-devtools: ^0.4.0与react-devtools-core: ^8.0.0两个 devDependency,前者提供 Vite 插件与 connect 脚本,后者是应用侧真正与 daemon 通信的桥接库。从 AGENTS.md 同一小节还能读到几条 Sanity 团队沉淀出来的实操坑,值得在照搬 profiling-guide 工作流时一并遵循:浏览器必须是有头(headed)模式。Headless Chromium 对注入的 ES module 脚本执行方式不同,会导致 connect 脚本无法在 React 加载前装好 hook,应用永远注册不到 daemon。关闭 StrictMode 再 profiling:SANITY_STUDIO_REACT_STRICT_MODEfalse启动工作室,避免开发期双渲染把渲染时长虚增,使结果贴近生产环境(生产工作室不跑 StrictMode)。该插件仅 dev-server 生效:Vite 插件声明了apply: serve语义,注入的连接脚本不可能进入sanity build产物,因此线上性能问题要先在本地 dev 环境复现再定位。关键注意事项小结先status后干活:status 显示 0 个已连接应用时,任何 profiling 都是空录;标签会失效:应用 reload 或组件卸载/重挂后,cN标签全部重置,需用agent-react-devtools wait --connected等待重新连接后再get tree或find重新定位;大树一律带--depth:从--depth 3起步,只在关心的子树上加深;timeline要分页:不加--limit可能一次性倒出 300 行,默认 limit 20,配合--offset翻页、--sort duration抓最贵的 commit;录制窗口必须覆盖交互:渲染只记录在profile start到profile stop之间发生的事件。完整 profiling 工作流的原始出处是 profiling-guide.md;若某条命令的完整参数语义不确定,以 commands.md 为准,它涵盖了 daemon 管理、组件检查与 profiling 全部子命令的 flag 与边界行为说明。【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Sanity React Profiling 实战:用 agent-react-devtools profile 命令组定位与修复慢交互【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity本文以 Sanity 仓库内.agents/skills/react-devtools/references/profiling-guide.md的 profiling 工作流为核心,完整讲解如何用agent-react-devtoolsCLI 对运行中的 React 应用做组件级性能分析:从建立基线、录制交互、解读profile slow/profile rerenders/profile report输出,到导出 JSON 并用profile diff对比前后两次会话验证优化效果。文中所有命令均可直接复制执行,并结合 Sanity 仓库中dev/test-studio的真实接入配置(dev/test-studio/sanity.cli.ts)说明了该工具在大型内容工作室(CMS)这类组件密集应用中的落地方式与注意事项。工具背景:为什么用 CLI 做 React 性能分析agent-react-devtools是一个通过 React DevTools 协议连接运行中 React / React Native 应用的命令行工具,把组件树、props、state、hooks 和 profiling 数据以 token 高效的文本格式暴露出来,专为人机协同调试场景设计——开发者(或 AI Agent)可以直接在终端里回答这个组件为什么重渲染哪个组件渲染最慢这类问题。其完整能力描述见 SKILL.md,完整命令参考见 commands.md,连接方式说明见 setup.md。工作机制上:一个本地 daemon 监听 WebSocket(默认端口 8097),React 应用通过注入的 connect 脚本注册到 daemon,CLI 则通过 IPC 与 daemon 通信。对 Web 应用而言,npx agent-react-devtools init会自动探测框架(Vite / Next.js / CRA / Expo)并注入最小配置;对 Vite 项目,它只是在配置中追加一个插件:// vite.config.ts import {reactDevtools} from agent-react-devtools/vite export default defineConfig({ plugins: [reactDevtools(), react()], })该插件仅在 dev 模式生效,会在应用代码加载前注入 connect 脚本,无需改动任何业务代码。Profiling 数据来自 React DevTools Profiler 协议,profile export导出的 JSON 可直接导入 React DevTools 的 Profiler 标签页做可视化分析。快速开始profiling-guide 给出的最小闭环是三步:开始录制、触发慢交互、停止并查看最慢组件:agent-react-devtools profile start # Trigger the slow interaction (type, click, navigate) agent-react-devtools profile stop agent-react-devtools profile slow --limit 5注意一个关键前提:profiling 只捕获profile start与profile stop之间发生的渲染。用户报告慢的那次交互(输入、点击、路由跳转)必须落在这个窗口内,否则采集到的只是一堆无关渲染。分步工作流1. 建立基线开始 profiling 前先确认当前状态,避免对着空的或未连接的应用做无效录制:agent-react-devtools status # Confirm app is connected agent-react-devtools count # How many components are mounted agent-react-devtools get tree --depth 3 # Understand the structurestatus输出 daemon 状态、已连接应用数、组件总数与最近事件;若显示Apps: 0 connected,说明 React 应用尚未注册,需检查 dev 模式是否开启、控制台是否有 WebSocket 报错、端口 8097 是否被其他实例占用(详见 setup.md 的排查清单)。count按组件类型统计(如42 components (fn:25 host:12 memo:3 cls:2)),给你一个有多少组件会被渲染的量级感。get tree --depth 3用缩进树打印组件层级。组件树节点带有稳定标签(c1、c2……),后续所有 profiling 命令都通过这些标签引用组件;类型标记fn/cls/host/memo/fRef/susp/ctx分别表示函数组件、类组件、DOM 元素、React.memo包裹、forwardRef、Suspense 与 Context。大应用中务必用--depth限制深度,避免输出爆炸。2. 录制目标交互开始录制时给它起个有语义的名字,方便日后在多次会话中区分:agent-react-devtools profile start typing in search然后由用户执行(或用 agent-browser 等浏览器驱动工具程序化地执行)被报告为慢的那次交互。注意同一时刻只能有一个活跃的 profiling 会话。完成后停止:agent-react-devtools profile stopstop会从 React 收集数据并打印摘要(时长、commit 次数、渲染最多的组件)。3. 识别瓶颈:两个互补的视角识别慢组件时,guide 强调要用两个互补的视图,而不是只看其一:最慢组件—— 哪些组件单次渲染耗时最长:agent-react-devtools profile slow --limit 5按平均渲染时长降序排列,输出列包含标签、类型、组件名、平均时长、最大时长、渲染次数、渲染原因与 changed keys。典型输出:Slowest (by avg render time): c3 [fn] ExpensiveList avg:12.3ms max:18.1ms renders:47 causes:props-changed changed: props: items, filter c4 [fn] TodoItem avg:2.1ms max:5.0ms renders:94 causes:parent-rendered, props-changed changed: props: onToggle渲染最频繁组件—— 哪些组件渲染次数过多:agent-react-devtools profile rerenders --limit 5这两个视图互补的直觉来自 guide 中给出的算例:一个组件渲染 100 次、每次 0.1ms 总耗时 10ms —— 这是重渲染问题(次数太多),优化方向是减少不必要的渲染;一个组件渲染 2 次、每次 50ms 总耗时 100ms —— 这是慢渲染问题(单次太重),优化方向是减轻单次渲染的计算量。两者总耗时可能相近,但修复手段完全不同,所以必须两个命令都跑。4. 深入具体组件:解读渲染原因锁定嫌疑组件后,用profile report获取它的完整渲染报告:agent-react-devtools profile report c12报告会列出全部渲染原因(cause)与具体触发渲染的 changed keys,例如changed: props: onClick, className state: count。changed keys 直接告诉你该稳定化(stabilize)什么。guide 给出的原因对照表是解读这份输出的核心:CauseChanged keys 示例含义典型修复parent-rendered(无)父组件重渲染,子组件未能 bail out用React.memo()包裹子组件props-changedprops: onClick, style收到了新的 prop 引用在父组件用useMemo/useCallback稳定化列出的 propstate-changedstate: count, filter组件自身 state 变化检查列出的 state 更新是否必要hooks-changedhooks: #0, #2某个 hook 的依赖变化审查按索引列出的 hook 的依赖数组first-mount(无)首次挂载正常现象,不是问题除上表六类原因(props-changed、state-changed、hooks-changed、parent-rendered、force-update、first-mount)外,聚合报告(profile slow/profile rerenders/profile report)会对同一组件跨多次 commit 的 changed keys 去重,因此看到的 keys 是该组件在整个会话内触发过渲染的全部字段。若 React DevTools 无法定位到具体字段,changed:后缀会被省略。5. 检查组件当前的 props 与 hooks有了原因假设,再用get component查看该组件当下的实际数据,验证什么在变:agent-react-devtools get component c12输出形如:c3 [fn] TodoList props: items: [{id:1,text:Buy milk},{id:2,text:Walk dog}] onDelete: ƒ state: filter: all hooks: useState: all useMemo: [...] useCallback: ƒ其中ƒ表示函数值,超过 60 字符的值会被截断。guide 建议重点关注:函数 prop(ƒ)—— 若父组件未用useCallback包裹,每次渲染都是新引用;对象/数组 prop—— 若未用useMemo包裹,每次渲染都是新对象;更新过于频繁的 state—— 结合state-changed原因交叉验证。这一步把第 4 步的嫌疑落到具体数据上:看到onDelete: ƒ这类 prop,配合profile report报出的changed: props: onDelete,即可确认修复点。6. 修复并用同样交互复测应用修复后,用完全相同的交互再录一次,对比渲染次数与时长:agent-react-devtools profile start after fix # Same interaction agent-react-devtools profile stop agent-react-devtools profile slow --limit 5肉眼对比两次输出的 renders 计数与 avg/max 时长即可确认改进。如果前后差异较大或需要留档,使用下一节的导出 diff 工作流。导出与 Diff 工作流导出 profiling 数据停止一次 profiling 会话后,可以把数据导出为 JSON 文件。该文件既可导入 React DevTools 的 Profiler 标签页做可视化分析,也可作为profile diff的输入:agent-react-devtools profile stop agent-react-devtools profile export baseline.json对比两次会话要识别回归(regression)或验证改进,在改动前后各录一次并 diff:# Before the change agent-react-devtools profile start before # ... interact with the app ... agent-react-devtools profile stop agent-react-devtools profile export before.json # After the change agent-react-devtools profile start after # ... same interaction ... agent-react-devtools profile stop agent-react-devtools profile export after.json # Compare agent-react-devtools profile diff before.json after.jsondiff 输出会把组件分为 regressed(变慢)、improved(变快)、new(新增)、removed(消失)四类。两个参数用于调灵敏度:--threshold—— 变化百分比阈值,默认5%,低于该比例的变化不报告;--limit—— 限制每个类别展示的组件数量。profile diff是纯离线对比,不需要 daemon 处于运行状态,因此可以拿到 CI 环境或另一台机器上跑,把 before/after 文件当作性能快照归档。常见性能问题清单guide 结尾把 profiling 中最高频的四类问题归纳如下,可作为解读结果的速查表:1. Context 或上提 state 引发的级联重渲染父组件因定时器或 context 变化重渲染,所有子组件跟随重渲染,因为没有任何一层用了React.memo。特征:profile rerenders中出现大量parent-rendered原因的组件,且渲染次数随交互次数线性放大。2. 不稳定的 prop 引用父组件内联传递onClick{() ...}或style{{...}},每次渲染都产生新引用,直接击穿子组件的memo()。子组件显示props-changed原因,即便 prop 的值在语义上完全没变。changed:输出会精确指出是哪个 prop 在捣乱(如changed: props: onClick, style),修复时在父组件对相应 handler/对象使用useCallback/useMemo。3. 未记忆化的昂贵计算组件在每次渲染中重复做过滤、排序、格式化等重活,表现为profile slow中的高平均渲染时长,而渲染次数本身并不高。修复:用useMemo缓存计算结果,让计算只在输入变化时发生。4. Effect 中更新 state 造成的渲染循环某个 effect 在每次渲染后都更新 state,导致不必要的 commit 循环。特征:用profile timeline查看 commit 序列时发现 commit 数量异常偏高。agent-react-devtools profile timeline --limit 10 --offset 0 # 按时间序分页浏览 commit agent-react-devtools profile timeline --sort duration --limit 5 # 最贵的 5 个 committimeline默认按时间序输出(默认 limit 20),每次交互往往伴随多个 commit;若单个用户动作触发了远超预期的 commit 数,通常就是 effect 循环或高频 state 更新的信号。进一步用profile commit N查看指定 commit 的逐组件耗时、原因与 changed keys。在 Sanity 仓库中的真实接入上述工作流并非纸面方案。Sanity 仓库的测试工作室dev/test-studio已把agent-react-devtools作为正式的性能诊断通道接入,可以直接作为大型内容应用(组件数量远超小 demo)的参考实现。接入方式:在 dev/test-studio/sanity.cli.ts 中,vite配置函数根据环境变量ENABLE_REACT_DEVTOOLS条件性地注入插件——// dev/test-studio/sanity.cli.ts(节选) const isReactDevtoolsEnabled process.env.ENABLE_REACT_DEVTOOLS true // ... if (isReactDevtoolsEnabled) { const {reactDevtools} await import(agent-react-devtools/vite) nextConfig mergeConfig(nextConfig, {plugins: [reactDevtools()]}) }采用懒导入 环境变量开关,保证不启用时agent-react-devtools完全不进入构建依赖链。该开关对应仓库根 package.json 中的脚本:pnpm react-devtools:test-studio # 即 ENABLE_REACT_DEVTOOLStrue pnpm dev:test-studio:studio完整操作序列来自 AGENTS.md 的 Profiling studio re-renders with React DevTools 小节:# 1. 启动 daemon(端口 8097) pnpm --filter sanity-test-studio exec agent-react-devtools start # 2. 以注入 connect 脚本的方式启动工作室(隐含 ENABLE_REACT_DEVTOOLStrue) pnpm react-devtools:test-studio # 3. 浏览器打开 http://localhost:3333,然后确认应用已注册 pnpm --filter sanity-test-studio exec agent-react-devtools status # 4. 录制一次交互 pnpm --filter sanity-test-studio exec agent-react-devtools profile start # ... 与工作室交互 ... pnpm --filter sanity-test-studio exec agent-react-devtools profile stop pnpm --filter sanity-test-studio exec agent-react-devtools profile rerenders --limit 10依赖侧,dev/test-studio/package.json 同时声明了agent-react-devtools: ^0.4.0与react-devtools-core: ^8.0.0两个 devDependency,前者提供 Vite 插件与 connect 脚本,后者是应用侧真正与 daemon 通信的桥接库。从 AGENTS.md 同一小节还能读到几条 Sanity 团队沉淀出来的实操坑,值得在照搬 profiling-guide 工作流时一并遵循:浏览器必须是有头(headed)模式。Headless Chromium 对注入的 ES module 脚本执行方式不同,会导致 connect 脚本无法在 React 加载前装好 hook,应用永远注册不到 daemon。关闭 StrictMode 再 profiling:SANITY_STUDIO_REACT_STRICT_MODEfalse启动工作室,避免开发期双渲染把渲染时长虚增,使结果贴近生产环境(生产工作室不跑 StrictMode)。该插件仅 dev-server 生效:Vite 插件声明了apply: serve语义,注入的连接脚本不可能进入sanity build产物,因此线上性能问题要先在本地 dev 环境复现再定位。关键注意事项小结先status后干活:status 显示 0 个已连接应用时,任何 profiling 都是空录;标签会失效:应用 reload 或组件卸载/重挂后,cN标签全部重置,需用agent-react-devtools wait --connected等待重新连接后再get tree或find重新定位;大树一律带--depth:从--depth 3起步,只在关心的子树上加深;timeline要分页:不加--limit可能一次性倒出 300 行,默认 limit 20,配合--offset翻页、--sort duration抓最贵的 commit;录制窗口必须覆盖交互:渲染只记录在profile start到profile stop之间发生的事件。完整 profiling 工作流的原始出处是 profiling-guide.md;若某条命令的完整参数语义不确定,以 commands.md 为准,它涵盖了 daemon 管理、组件检查与 profiling 全部子命令的 flag 与边界行为说明。【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
