performance-audit-standard

Performance Audit Standard 是一套系统化的代码库性能审计方法，目标是识别并修复性能瓶颈。

一、用途 当需要剖析应用、定位瓶颈或优化热点路径时，可按该标准执行审计。它聚焦于“代码实际执行频率高或处理大数据集”的部分，而不是凭直觉猜测。

二、审计流程

1. 识别热点路径（Hot Paths）：请求处理器（每个 HTTP 请求）、事件处理器（每条 WebSocket 消息）、处理集合的循环体（每项）、间隔定时器（每 N 秒）、中间件/拦截器（每个请求）。对每个热点追问：这段代码每秒执行多少次？典型输入规模多大？
2. 分析复杂度：为每个热点确定真实的 Big O。文档给出的模式包括：array.includes(x) 为 O(n)；array.find(x => ...) 为 O(n)；array.filter().map().filter() 为 O(3n) 加 3 次分配；Object.entries().find() 为 O(n)；用 array.sort() 求最小值/最大值为 O(n log n)，对单个值是过度设计；嵌套循环中的 includes 为 O(n*m)，即二次方。
3. 应用修复：按反模式逐项替换。

三、主要能力（常见性能反模式与修复）

1. O(n) 成员判断改为 Set：savedIds.includes 在循环中变成 O(n*m)，改用 new Set(savedIds) 后，每次判断 O(1)，总体 O(n+m)。文档称对 1000 项集合可产生约 1000 倍差距（100 万次比较降到 1000 次）。
2. O(n log n) 选择改为单次遍历：filter + sort + 取首个改为一次 O(n) 循环找最小 lastUsed，文档称快 10–50 倍，且无中间数组。
3. 线性查找改为 Map 索引：tokens.find 改为用 Map 建索引后 get，文档称每次查找快 10–20 倍，需在增删时维护索引。
4. 每次请求解析改为初始化时缓存：代理池示例中，把 split 正则与字符串拼接放到构造函数，random() 直接取；文档称提升 100–1000 倍。
5. 同步文件 I/O 改为异步：fs.writeFileSync 阻塞事件循环 5–50ms，改用 fs.promises.writeFile；更进一步用 MD5 哈希判断内容未变则跳过写入。
6. 每次请求创建客户端改为单例：Rust 示例中每次新建 reqwest::Client 会带来新的 TLS 握手与连接池，改为 Lazy 静态单例复用。
7. 持锁跨 I/O 改为克隆后释放：在写盘前先克隆数据、释放锁，再用异步写。
8. 循环内重复计算改为提升（hoist）：把 keyword.toLowerCase() 预先算好，避免每个元素重复计算。
9. 多次数组遍历改为单次遍历：把 resale 与 normal 的 filter/map 合并为一次循环，减少中间数组。
10. 数据库 N+1 查询：用 include/with/Preload 一次取回，从 1+N 次查询降为 2 次；建议按请求记录查询数、设置预算、超限则测试失败。
11. 数据库缺失索引：用 EXPLAIN ANALYZE 发现顺序扫描；热点查询中 WHERE、JOIN、ORDER BY 涉及的列都需要索引，复合索引顺序与查询一致（等值列在前，范围列在后）。
12. 前端包体积与 Core Web Vitals：给出 LCP < 2.5s、INP < 200ms、CLS < 0.1、初始 JS（gzip）< 170KB 的参考值，工具包括 Lighthouse、web-vitals、rollup-plugin-visualizer、source-map-explorer；常见优化有路由代码分割、图片 loading="lazy"、图标库 tree-shaking、替换大体积 polyfill。

四、使用方式 文档提供“优先级速赢矩阵”报告格式，建议按 优先级、修复、位置（file:line）、工作量、加速比 列出发现，并按影响/成本比排序，估算总体 CPU 降低。语言特定工具：JavaScript/Node.js 使用 node --prof 与 --prof-process、clinic.js、0x、process.memoryUsage()；Rust 使用 cargo flamegraph、criterion、dhat、tokio-console、perf/Instruments；Go 使用 pprof、go test -bench、trace；Swift/iOS 使用 Instruments（Time Profiler、Allocations、Leaks）、Xcode Memory Graph Debugger、os_signpost。

五、适用场景与限制 适用于存在高频执行路径、大数据集处理、数据库热点查询或前端性能指标不达标的代码库审计。文档明确列出“不该优化”的情形：每秒执行少于 100 次且元素少于 100 个；优化带来显著复杂度但收益不足 2 倍；瓶颈在 I/O（网络、磁盘）而非 CPU；剖析显示该代码并不热。核心原则是先测量再优化（Profile first, optimize second），优化前后都要测量。文档未提供针对具体项目的完整实施步骤、价格或收费信息。