performance

name	performance
description	性能优化方法（语言无关）——先测量再优化、定位瓶颈、优化热点、验证。具体技术（前端 Core Web Vitals、后端查询、AI 延迟）见所用预设。

性能优化方法

这是通用方法，不绑定技术栈。具体优化手段见所用预设：

• web-fullstack：frontend 技能（Core Web Vitals、代码分割、图片优化、bundle）
• ai-app：rag 规则与 specs（嵌入缓存、向量索引、流式、延迟 P95）

铁律：先测量，再优化

不要凭感觉优化。先用数据找到真正的瓶颈，否则你优化的多半不是慢的地方。

① 测量 → ② 定位瓶颈 → ③ 优化热点 → ④ 再测量验证 → 回到①

• 没有 before/after 数字，就不算优化完成
• 优化最热的那 20%，不要均匀用力
• 每次只改一处，单独验证效果（否则不知道哪个改动起了作用）

瓶颈分类（按这四类排查）

类别	典型症状	通用对策
计算	CPU 打满、主线程卡	降复杂度、缓存结果、移出热路径、并行/异步
IO	等磁盘/数据库/文件	批量、索引、连接池、避免 N+1、流式
网络	等远程响应	并发请求、缓存、减少往返、就近部署、压缩
内存	OOM、GC 频繁、泄漏	释放引用、流式处理大数据、分页、对象复用

通用优化模式

• 缓存：对昂贵且可复用的结果做缓存（注意失效策略）
• 批量：把 N 次小调用合并成 1 次（数据库、API、嵌入生成都适用）
• 并发：互不依赖的 IO 操作并行（不要在循环里串行 await）
• 懒加载/分页：不要一次性加载/计算用不到的东西
• 避免 N+1：循环里逐条查询 → 改成一次批量查询

反模式

• 没测量就优化（"我觉得这里慢"）
• 过早优化（牺牲可读性换不必要的性能）
• 优化冷路径（一天调用一次的代码抠微秒）
• 一次改一堆，无法归因
• 用缓存掩盖根本性的算法/查询问题

输出

性能工作要给出：瓶颈在哪（数据支撑）、改了什么、before/after 对比。 具体指标阈值见预设（如 web 的 LCP<2.5s、AI 的检索 P95<3s）。