代码优化
提升用户可见的性能和可靠性，同时保持代码的可理解性和运营成本的合理性。优化现有工作负载，不要为假设的未来规模增加复杂性。
工作流
- 定义目标和约束条件。 识别相关的端点、任务、查询、工作负载和期望结果。只选择重要的指标：例如，p95/p99延迟、吞吐量、CPU、内存、分配速率、数据库查询次数、依赖往返次数、错误率或饱和度。保留行为、一致性、安全性和现有错误契约。仅当缺少目标或工作负载导致无法做出合理选择时，才提出一个有针对性的问题；否则，根据请求和代码尽可能推断。
- 建立基线。 使用现有的跟踪、性能分析、查询计划、指标、测试或代表性基准。保持输入、环境和并发性在前后一致。不要凭直觉或单次不稳定计时声称加速。未经授权，避免针对生产环境运行负载测试或昂贵的查询分析。
- 找到瓶颈。 追踪端到端关键路径，并使用性能分析或检测来区分CPU工作量、阻塞、数据库时间、网络等待、序列化、锁竞争和排队。检查实际的查询/调用模式和代表性数据。优先选择基于证据的方法，而不是广泛的清理或微优化。如果未确定瓶颈，请报告不确定性，并在进行侵入性更改之前提出最小的有用测量。
- 选择最小的有效更改。 在可行的情况下，一次只优化一个实质性瓶颈。保留输出、排序、失败行为、事务语义和安全检查。不要为了基准测试成绩而牺牲正确性或可靠性。遵循仓库的约定，避免无关的重构。
- 验证两个结果。 运行相关的正确性测试，并对比相同代表性工作负载在更改前后的表现。检查目标指标是否改善，以及约束条件——特别是尾部延迟、错误、内存和依赖饱和度——是否没有退化。如果无法进行有意义的比较，请说明情况，并避免将未测量的更改呈现为已证实的优化。
- 报告结果。 简要说明瓶颈和证据、所做或推荐的更改、验证和测量的影响（或无法测量的原因），以及任何重要的权衡。对于审计或计划请求，根据证据、可能的影响、工作量和风险对发现结果进行优先级排序，而不是更改代码。
数据库与数据访问优化
- 统计查询次数并检查ORM/数据库访问模式。使用适当的连接、批处理或基于集合的操作消除N+1读写；验证查询次数并保留结果排序和缺失记录的行为。
- 仅获取所需的列和行。对大型结果集使用分页或流式处理；将合适的过滤和聚合推送到数据库，而不是将大型数据集加载到应用程序内存中。
- 使用查询计划和实际谓词来证明索引的合理性。检查选择性、排序/连接需求、现有索引以及写入/存储开销。不要添加推测性或重复的索引。在代表性数据上验证计划和延迟；仅在安全环境中使用基于执行的计划分析。
- 减少不必要的往返，并使事务和锁的范围不大于必要。不要以削弱约束、隔离性、验证或一致性作为捷径。
- 仅在测量的重用性证明其合理性时添加缓存。定义新鲜度、失效规则、键范围和失败行为；不要将缓存作为对慢查询的默认响应。
后端与服务调用优化
- 移除冗余调用，批处理兼容的请求，并且仅并行化真正独立的调用。保持并发有界，保留所需的顺序/依赖关系，并考虑下游容量。
- 重用客户端和连接池。设置适合请求预算的超时/截止时间，并在支持的地方传播取消信号。
- 仅对瞬态故障进行重试，且操作必须是安全可重试的。限制重试次数和总重试时间，使用带有抖动的退避策略，避免在多层重试中放大负载。不要在没有证明其解决的故障模式的情况下添加重试、熔断器或队列。
- 仅当过大的负载或重复序列化对测量路径有实质性影响时才减少它们。保持所需的服务故障语义不变；对可选依赖项明确进行优雅降级。
运行时、可靠性与可维护性
- 优先选择证据支持的最高杠杆修复：改进算法复杂度、消除重复工作、减少不必要的分配/复制，或者在低级微优化之前解决阻塞和竞争。
- 在并发情况下保持资源使用有界：考虑内存、队列、池、扇出、超时、取消和背压。确保故障不会导致重试风暴、无界工作或资源泄漏。
- 将性能和可靠性视为系统级成果。一个使数据库过载或增加错误率的更快调用者并非优化。
- 应用YAGNI原则：不要为假设的瓶颈添加依赖、抽象、缓存、索引、异步层、配置选项或架构更改。优先进行清晰的本地更改；如果需要复杂性，请解释其测量的收益和维护成本。
- 不要为了节省微不足道的时间而移除输入验证、授权、可观测性或安全检查。不要用更难以维护的微优化替换可读代码，除非测量的增益是实质性的。
验证说明
- 使用可重复的运行和足够的样本数量比较等效的工作负载，以区分信号和噪声。在相关情况下使用分布（特别是尾部延迟），而不仅仅是平均值。
- 验证因批处理、缓存、并行、分页、重试或并发而影响的功能行为和边界情况。添加有针对性的测试来保护有意义的不可变条件，例如查询次数、排序、超时行为或可选服务回退。
- 在更改后重新进行性能分析：瓶颈会移动，局部改进可能会将成本转移到另一个服务或资源。
- 如果优化没有产生实质性改善，或者其复杂性超过了收益，请回退更改或建议不做更改。