# 代码质量检查项

## 错误处理

- 异常被 catch 后直接丢弃，没有重新抛出也没有实质处理
- 捕获异常后只打 log，调用方无法感知失败，流程继续执行
- async 函数没有 await，或 Promise 没有 catch，失败静默丢失
- 降级逻辑掩盖了真实错误，让问题更难排查

## 性能与缓存

- 循环内部触发 N+1 query 或重复 I/O（每次迭代都查一次数据库）
- 热路径上有高开销操作（序列化、反射、大对象创建）
- cache key 缺少关键维度，导致不同请求拿到相同缓存数据
- 集合或缓冲区无界增长，随时间或并发量线性膨胀

## 边界条件

- 访问 null/nil/undefined 前没有 guard check
- 对空集合直接取第一个元素，或对空字符串做字符串操作
- 存在除零风险（分母来自外部输入或计算结果）
- off-by-one 错误：边界用 `<` 还是 `<=`，索引从 0 还是 1 开始
- `0`、`false`、`""` 这类合法值被 falsy 判断误判为"无值"
- 对整数范围的假设未校验（例如假设数值一定为正）

## 资源管理

- 连接、文件句柄、锁、数据库 session 没有在所有路径上释放（包括异常路径）
- try-finally 或 with/defer 只覆盖了正常路径，异常路径漏掉了
- 对象从容器中移除后，底层资源（连接池、文件描述符）仍然存活

## 并发

- 多线程/协程场景下读写共享可变状态，没有加锁或使用 atomic 操作
- lazy initialization 没有考虑并发，可能被多次初始化
- 回调或事件处理函数修改外部共享状态，没有同步保证

## 测试

- 测试只覆盖 happy path，没有覆盖异常、边界、空值场景
- 断言过于宽泛，无法证明核心行为正确（例如只断言返回了某个类型）
- 测试 setup 本身存在脆弱点（依赖外部状态、时序、全局变量）
- 关键业务逻辑变更后，没有对应新增或更新测试

## 排查思路

审查时依次问自己：

- 这里失败了，调用方能感知吗？错误会在哪里暴露？
- 输入为空、为零、为空集合、超出范围或重复提交时，会发生什么？
- 哪些逻辑在循环、重试或热路径中执行，是否引入了重复计算或额外 I/O？
- 即使抛异常，哪些资源仍然必须被释放？
- 如果某个疑点没有具体代码路径支撑，不作为正式问题输出。