用途：当出现卡顿、吞吐量低、资源占用过高、包体积过大，或需要评估预期峰值容量时使用；也可用于审查已有优化建议是否具备可测量基线与假设，而非凭直觉。若目标是搭建生产指标/告警体系，应改用可观测性相关技能；此处聚焦于诊断并解决已观察或疑似存在的具体性能问题。瓶颈在查询或索引时可结合 PostgreSQL 相关技能，需要流水线自动护栏时结合交付工程相关技能。
流程：在动代码前先定义旅程、指标、目标百分位、预期负载与性能预算；用有代表性的环境与数据量复现问题，不要用极小的开发数据集诊断；测量当前基线并按边界（客户端、网络、应用、数据库、外部依赖）分解耗时；针对已识别边界提出具体假设并使用匹配的 profiler/trace；每次只改一个相关因素并在与基线相同条件下重测；验证修复在真实负载、超时与重试下保持正确性；建立护栏（性能回归测试、流水线预算）防止回归被忽视。
规范：使用 p50、p95、p99 及完整分布而非仅平均值；明确区分客户端、网络、应用、数据库与外部依赖延迟；同时测量冷热缓存与真实并发条件；在证明无缓存路径成本并定义失效策略前不要加缓存层；负载、超时与重试下必须保持正确性；控制观测者效应，测量前做好预热；按真实峰值场景而非当前平均流量定义容量与余量。
反模式：没有测量基线就优化；未定位真实瓶颈边界便加索引、缓存或并行；比较两版本均值而非相同负载下的同一百分位分布；未排查 N+1 查询、串行调用与多余网络往返就扩容硬件；未在同条件下留存前后基线就宣称“更快”。
验证：保留可复现基准与归档基线；按分解证据选择 CPU、内存、I/O 或查询 profiling；负载测试需明确成功标准并设安全上限；流水线自动回归的灵敏度应与指标历史稳定性匹配，噪声大的指标需更大余量。相关资料指向 references/standards.md 以获取 Web Vitals、基准方法、负载测试、profiling 与性能预算的官方来源；具体命令与安装方式暂未提供。