用途：当出现可感知的性能问题（页面加载慢、查询慢、包体过大、API 延迟高）或有人提出“优化”“让它更快”时使用。核心原则是：没有测量证明问题存在，就不做优化；性能直觉通常不可靠。
主要能力：提供从建立基线、定位瓶颈、修复到验证的完整流程。基线测量维度包括页面加载延迟（Lighthouse、WebPageTest、浏览器 DevTools Performance）、API 响应时间（服务端日志、APM、time curl）、查询执行时间（EXPLAIN ANALYZE、慢查询日志、ORM 日志）、包体重量（webpack-bundle-analyzer、source-map-explorer）、内存（堆快照、process.memoryUsage()）、CPU（火焰图、perf、py-spy）。定位顺序通常为数据库查询、网络调用、序列化、计算、I/O。修复手段涵盖数据库（消除 N+1、加索引、游标分页、物化视图）、前端 Core Web Vitals（LCP<2.5s、INP<200ms、CLS<0.1，含代码分割、ESM tree-shaking、gzip/brotli）、API（稀疏字段、批量端点、Cache-Control/ETag、202 异步处理、分页压缩流式）、算法（哈希表替代嵌套循环、记忆化、异步并行、增量更新）。
使用方式：按入口协议执行——测量当前性能、设定目标阈值、用剖析器定位瓶颈、只修复该瓶颈、重新测量验证；一次只改一个变量。若改进无法测量则回退。
适用场景：用户报告变慢、遥测显示回归、性能预算被突破、常规查询超过 100ms、典型 API 响应超过 500ms。
限制：功能尚不正确时先保证正确性；不要为“将来可能变慢”或“最佳实践建议”而优化；避免过早缓存、过早加索引、微优化循环、无失效策略的缓存、在开发环境做性能剖析；不要在无剖析数据时优化，不要同时应用多个优化。
补充：资料未提供安装命令、收费方式或平台支持信息。