superior-performance

更高性能

改善真正受限的用户或系统结果，而不是只让代码看起来开销很大的部分。保持正确性、安全性、无障碍性和可维护性，并以可比证据为每项优化提供依据。

定义性能契约

优化前，先确定：

• 受影响的用户流程、操作、工作负载或资源；
• 指标和目标，适用时包括百分位数或分布；
• 当前基线、回归时间窗口和测量来源；
• 环境、硬件、网络、数据形态、并发度和缓存状态；
• 不可牺牲的正确性和质量约束；
• 目标是延迟、吞吐量、响应能力、容量、效率还是成本。

不要把“慢”这类未经验证的印象转化为普遍目标。如果没有明确预算，应根据产品预期和代码库证据推导暂定比较基准，并标明其为暂定值。

先测量再更改

在建立基线、选择性能分析工具、构建基准测试或比较方案时，请阅读 references/measurement-profiling-and-benchmarks.md。

• 在实际可行时，编辑前先复现有代表性的工作负载。
• 有意预热运行时和缓存；如果冷启动和预热状态都很重要，应分别报告结果。
• 相比凭直觉判断，优先使用性能分析结果、跟踪记录、查询计划、火焰图、分配数据或浏览器时间线。
• 每次只更改一个重要变量，并在相同设置下进行比较。
• 将波动、后台工作、采样、限流和测量开销纳入考量。

单次快速运行不能证明性能有所改善。合成基准测试只对其能忠实代表的行为有参考价值。

优化瓶颈所在层

对于 CPU、内存、分配、I/O、并发、队列、批处理、缓存、连接池或服务容量相关工作，请阅读 references/runtime-capacity-and-caching.md。

对于包体积、网络瀑布流、图像、字体、水合、渲染、输入响应、长任务、布局或客户端内存相关工作，请阅读 references/client-delivery-and-rendering.md。

• 在加快必要工作之前，先移除不必要的工作。
• 在拥有瓶颈的层减少工作，而不是将其悄然转移到其他服务、客户端、队列或部署阶段。
• 保持有界性和背压；更高的吞吐量若造成队列不稳定，就不算改善。
• 将缓存视为一致性和生命周期系统，而非免费的提速手段。
• 相比价值较低的语法级微优化，优先改进算法、查询、负载和往返次数。

不要仅仅因为并发、记忆化、延迟加载、预加载、压缩或缓存可能改善基准测试，就添加这些机制。应确认工作负载、失效机制、内存、延迟和运维方面的权衡。

保障正确性和体验

• 确认输出、排序、授权、错误处理、取消和幂等性仍然正确。
• 不要通过丢弃慢请求、掩盖错误、降低结果质量或排除难以处理的设备和数据来改善平均值。
• 在客户端优化中保留无障碍支持和减少动态效果的行为。
• 未经明确授权且缺少安全控制时，不要进行生产环境性能分析、负载生成、缓存清理、大范围遥测更改或资源限制调整。
• 将改变公共行为、一致性、保留策略或成本的性能变更视为契约变更，而非隐形的实现细节。

验证改进

更改后重复基线测试，并报告：

• 更改前后的分布或代表性测量结果；
• 工作负载、环境、样本数或持续时间，以及缓存状态；
• 显示瓶颈已转移或减轻的性能分析证据；
• 已执行的正确性和回归检查；
• 引入的资源或成本权衡；
• 基准测试的局限性和未覆盖的条件。

检查相邻工作负载是否出现回归。优化可能改善某个百分位、负载、路由或设备上的表现，却损害其他方面。如果结果处于测量噪声范围内，应报告为无法确定，而不是已改进。

有针对性地组合技能

• 当性能症状的成因尚不明确，且因果调查是首要任务时，使用 superior-debugging。
• 当瓶颈主要由查询计划、索引、锁、架构或数据存储容量导致时，使用 superior-database。
• 当目标、过载行为、优雅降级或恢复决定最终结果时，使用 superior-reliability。
• 当性能证据是发布门槛，或优化会改变构建或发布流程时，使用 superior-delivery。
• 当基准测试设计或性能回归自动化需要专门的测试判断时，使用 superior-testing。
• 当需要更改界面才能安全地实现经测量的改进时，使用 superior-ui、superior-responsive 或 superior-accessibility。
• 当优化会改变应用行为、并发、状态或外部调用时，使用 superior-logic。
• 在确认取得实质性性能改进，或持久性测量／运行手册更新后，使用 superior-docs。

未经明确授权，不要将有针对性的优化扩大为框架重写、基础设施迁移或可观测性平台替换。