chuxinneko/nekocodedesktop/code-review

代码审查

审查的产出是具体的缺陷，不是感想。每条结论都要能写成"什么输入 → 什么错误结果"。写不出来的，就不是发现。

先确定审查范围

1. 用户指定了范围就用它（某个文件、某个 PR、某个分支）。
2. 没指定就看工作区改动：git status 再 git diff（未暂存）和 git diff --staged（已暂存）。
3. 两者都空时看最近一次提交：git show --stat HEAD。
4. 改动超过 ~800 行时，先 git diff --stat 列出文件，按"核心逻辑 → 边界处理 → 测试 → 配置"排序，逐个读。

只读改动本身不够：每个被改的函数，要把它完整读一遍，再读一处调用点。diff 的上下文不足以判断改动是否破坏了调用方的假设。

按这个顺序找问题

前三类是必须查的，后两类有余力再查。

1. 正确性

• 边界值：空数组、空字符串、0、负数、单元素、最后一个元素。循环的 < 与 <=，切片的起止。
• null / undefined：新增的可选字段有没有在每个读取点判空。解构默认值只在 undefined 时生效，null 会穿透。
• 错误路径：抛出的异常有没有人接。catch 里吞掉错误的，确认这是有意的静默而不是遗漏。
• 异步：漏掉的 await；Promise 数组是并发还是串行，改动有没有让它反过来；竞态——两次调用交错时的状态。
• 类型转换：字符串与数字的隐式比较，浮点相等，时区与 UTC 混用。
• 资源：打开的文件/连接/监听器有没有对应的释放，异常路径上也要有。

2. 与既有代码的一致性

• 这段逻辑是不是已经有现成函数？搜一下相近的名字再动手。
• 命名、错误处理方式、注释密度是否和周围一致。一段风格突兀的代码，维护者会不敢改。
• 新增的抽象是否有第二个使用者。只有一个调用点的封装通常应该内联回去。

3. 测试

• 改动的分支有没有对应测试。没有测试的 bug 修复会复发——这是最该提的一类意见。
• 测试断言的是行为还是实现细节。断言内部调用次数的测试会在重构时误报。
• 新测试会不会在不改产品代码的情况下永远通过（断言太弱）。

4. 性能

只在循环内、热路径上、或数据量随输入增长时才提：

• 循环里的重复计算、重复查询（N+1）。
• 本可以一次遍历完成的多次遍历。
• 在大对象上做深拷贝。

不要为了微优化牺牲可读性，除非能指出具体的量级问题。

5. 安全

• 用户输入拼接进 SQL / shell / 路径。
• 日志或错误信息里泄露凭据、token、个人信息。
• 新增的文件读写有没有限制在预期目录内。

每条意见怎么写

<文件>:<行号>
问题：一句话说清缺陷是什么。
触发：具体输入或状态 → 实际会发生什么。
建议：改成什么。

按严重程度排序：会导致错误结果或崩溃的在最前，可读性建议在最后。

收尾

• 一条问题都没找到时，就明确说"没有发现缺陷"，并说明你查了哪些方面。不要为了凑数编造意见。
• 不确定的判断要标明不确定，并说明需要什么信息才能确认。
• 除非用户要求"顺手改掉"，否则只报告不动手。