review-perf

性能审查（内部）

由 review-change / product-audit 在其对话中撰写——对于任何 Agent，请将此文件作为路由步骤内联遵循。仅报告发现；绝不修改， 绝不重构。

范围

调用方传入的差异或路径/全局匹配模式；默认审查当前变更与默认 分支的差异。在返回表格顶部注明审查范围。

检查清单（评估每一项——无一例外；不适用时必须注明）

• ✓ 变更涉及的数据访问路径不存在 N+1 查询/IO 模式（循环体中发起查询/请求——请引用）
• ✓ 对于输入可能增长的新代码路径，注明算法复杂度（用户数据上的无界 O(n²) 属于重大问题）
• ✓ 在平台采用异步机制的热路径/请求路径上，没有新增阻塞 IO/同步工作
• ✓ 变更打开的资源在所有路径（包括出错路径）上都已关闭/释放（文件、连接、订阅、计时器）
• ✓ 没有引入无界增长（无淘汰机制的缓存、只追加的数组、从不移除的监听器）
• ✓ 仅适用于 Web：注明变更对包/资源的影响（新增依赖的体积、图片大小、项目使用的延迟加载）——否则注明不适用
• ✓ 循环中重复计算的不变值已移至循环外（请引用）
• ✓ 任何新增的、读取用户规模数据的列表操作都具备分页/限制
• ✓ 也不得过早优化：未引用测量数据却为提升速度而增加复杂度，属于问题（仓库禁止过度设计）
• ✓ 声明了性能命令时提供测量证据——项目的 Agent 指南声明了一个包含 bench 命令的 Performance commands 区块，且差异涉及其基准测试覆盖的路径：在基准分支和变更分支上运行基准测试，并在 Evidence 中按以下格式引用两组数据：<cmd> → base <x> / change <y> (<±z%>)。超出噪声范围（项目声明的范围；否则为 ±5%）的回退属于重大问题；范围内的差值不构成问题。声明的命令运行失败（退出码非零）本身就是问题（性能门禁无法测量）——绝不能悄然跳过。
• ✓ 未声明性能命令 → 对上述项目原样填写 n/a — no declared perf commands（绝不能悄然跳过）；如果差异新增了输入可能增长的算法代码，还要添加一条轻微问题，建议项目通过 init-workspace 的 Performance tooling 阶段采用相关工具。

重要性标准

仅当有能力的用户所获得的结果会发生变化，或项目明确声明的规则遭到违反时，才报告一行——并在证据旁注明违反的规则。以下不属于问题：注释/标点错误、仅格式上的差异、未引用规则的风格偏好、超出 SPEC 所列场景的假设性健壮性要求。对于规范完善的变更，预期结果是空表并附上 Decision: PASS——绝不凑数。

严格按以下格式返回

REVIEW PERF — scope: <scope>

| # | Finding | Sev | Evidence | Suggested fix |
|---|---------|-----|----------|---------------|
| 1 | <what>  | critical|major|minor | <file:line — or, for measured findings, `<cmd> → base <x> / change <y> (<±z%>)`> | <smallest action> |

Checklist: <n> evaluated, <n> pass, <n> findings, <n> n/a (<which + why>)
Summary: <1-2 sentences>
Decision: PASS | FAIL

存在任何尚未解决的严重或重大问题时判定为 FAIL；否则判定为 PASS。轻微问题不会阻止通过——它们会转交调用方的分流步骤。

完成条件

• 每一项检查清单都须提供证据（文件:行号或命令输出），或明确注明不适用及原因。
• 返回上述固定格式的区块——不多不少，且不得更改任何代码。