性能研发规范

本规范适用于产品的页面、接口、后台任务和资源交付。性能是用户任务能否顺畅完成的一部分，不等于单个跑分；先定义当前产品的关键路径，再针对真实问题优化。静态资源的具体规则见静态资源与对象存储。

先定义可验收的目标

• 选出用户真正频繁使用或等待成本高的任务，例如打开列表、搜索、提交表单、上传文件和查看处理结果。记录任务完成时间、加载与交互等待、接口延迟、错误率及资源体积中与该任务有关的指标。
• 记录测试条件：设备、网络、数据量、登录状态、缓存冷热、并发规模和构建版本。目标值由项目按用户场景和现有基线确定，不把某个通用数字当作所有产品的验收线。
• 变更前留下可复现的基线；变更后用相同条件复测，并检查功能、可访问性和错误处理没有退化。线上观察还应关注真实用户与生产负载，不能只凭本机一次测试宣布优化成功。

优先减少无用工作

• 页面按任务组织数据与组件。避免首屏加载暂时不需要的图片、脚本、列表全量数据和第三方依赖；需要时再加载，但不能把必需内容藏到交互之后。
• 合并重复请求、收窄查询字段和数据范围，列表使用适合场景的分页或增量加载。先检查慢查询、索引和调用次数，再决定是否加缓存。
• 长耗时操作要有明确的进行中、成功和失败状态。能异步处理的任务应保留结果可追踪性，不能为了让页面“秒回”而丢失实际执行结果。
• 图片、字体和其他资源按用途控制体积与加载时机。格式、尺寸、压缩和存储规则以静态资源与对象存储为准。

优化留在责任模块内

由产生重复计算、慢查询或大资源的模块负责修正。缓存、预计算、并行、队列和额外服务只用于已测出的瓶颈，并写清数据权威、失效时机、并发与失败行为。缓存不能绕过授权，也不能让过期结果覆盖权威数据。不要预建“性能中心”或通用缓存框架。

每次优化保留问题、基线、改动和复测结果。若收益不可重复，或维护成本明显高于收益，就撤回复杂实现或重新定位问题。