用途：诊断 Web 应用在构建、服务器、浏览器、数据库、网络等路径上的性能问题。诊断本身不授权修复，除非用户明确要求实施。
工作流程：先确认症状、受影响环境、路由/操作、回归时间窗、期望阈值和可重复的复现步骤；能从事务追踪、issue 或代码推断则自行推断，只询问会改变调查方向的缺失事实。随后识别框架/运行时/版本、部署拓扑、包管理器、数据存储、可观测性及近期相关变更，并区分开发环境与生产环境行为。
资源类症状（发热、风扇、电池、系统级飙升）需在应用剖析前先归因，用短暂且热安全的复现方式采样进程 CPU、内存、能耗和可用时的 GPU，并把浏览器标签页与扩展、Node/开发服务器、编译监听器、数据库及无关进程隔离；若温度、功耗或稳定性不安全应停止复现。
基线采集按症状选择工具：构建用冷/热启动与构建计时、编译器日志、监听范围；服务器用路由 span、CPU/内存剖析、冷启动、事件循环延迟、查询耗时；浏览器用标签页/任务管理器隔离、性能 trace、网络瀑布、长任务、水合、动画/合成/GPU 负载、轮询与定时器、Core Web Vitals；打包用框架支持的分析器和路由级客户端/服务端组成；数据库/网络用查询计划、连接等待、下游延迟和载荷大小。
形成排序假设后先测试成本最低且能区分的假设。大日志、看似昂贵的调用或大包只是待查证据，不等于根因。对 Next.js，需先确认主版本和缓存模型，再谈 React.cache、use cache、fetch 缓存或 Turbopack 配置；React.cache 只在单个请求内去重，不是跨请求缓存；仅当项目确实解析根目录外链接文件时才配置 turbopack.root。
若获授权实施，每次只做一个窄改动，缓存时保护用户/租户隔离、新鲜度、失效、内存边界和失败行为，保留前后对比产物，未改善目标指标的改动应回退。验证需在同一条件下重复相同复现，比较中位数和尾部值，分别测试冷/热行为，对改动过的缓存/并发跑正确性测试，并运行项目 lint/type/test/build；浏览器性能尽量结合本地实验室与真实数据。
输出：症状与复现、基线、证据、根因或剩余假设排序、仅在授权时列出改动文件、前后指标、正确性检查、置信度和下一步测量。没有观察到证据不得断言原因或改进。