# 代码 Review 与逻辑验证

## 固定顺序

```text
代码实现完成
→ Code Review
→ 修复 Review 问题
→ 再次 Review
→ 执行 03 中的逻辑验证和本地接口冒烟
→ 输出结论
```

## Code Review

检查完整变更及必要的相邻上下文，不只看修改行。可以使用 `git status`、`git diff`、`git log` 等只读命令确定 Review 范围，但不得执行 `git add`、`git commit`、`git push`。

### 需求符合性

- 是否覆盖全部确认功能；
- 是否符合 01、02、03；
- 是否遗漏接口影响和回归；
- 是否擅自增加范围。

### 项目规范与质量

- 架构、分层、命名和代码风格；
- 复用、重复实现、异常、日志和错误码；
- 无关修改和大范围格式化；
- 依赖和测试风格。

### 核心架构变化

检查模块职责、分层边界、依赖方向、核心接口、数据事实源、Redis/ES/消息链路、权限、事务和状态流转。

分类为：

```text
方案内预期变化
实现细节调整且不影响架构
方案外架构变化，需要确认
疑似架构破坏，必须修复
```

### 严重缺陷

重点检查：

- 代码中不得有在循环中查询数据库的情况
- 越权、注入和敏感信息泄漏；
- 数据错误、丢失或覆盖；
- 空指针和未处理异常；
- 事务、并发、幂等和状态错误；
- 缓存/数据库/ES 不一致；
- 消息重复、丢失或无限重试；
- 死循环、资源泄漏和明显性能问题；
- 接口兼容破坏；
- 不可恢复的删除或迁移；
- 异常路径错误返回成功；
- 测试被弱化或跳过。

只能写“在本次检查范围内未发现严重问题”，不得承诺绝对无 Bug。

问题分级：

| 等级 | 含义 | 要求 |
|---|---|---|
| Critical | 安全、数据丢失、系统不可用 | 修复后才能继续 |
| High | 核心错误、架构破坏、明显兼容问题 | 修复后才能继续 |
| Medium | 局部逻辑、维护性或规范问题 | 原则上修复并记录 |
| Low | 优化或轻微风格问题 | 按范围处理 |

## `05.代码Review报告.md`

```markdown
# ST-XXX 代码 Review 报告

## 1. Review 信息和范围
## 2. 需求符合性
## 3. 项目规范符合性
## 4. 核心架构变化
## 5. Review 问题
| 编号 | 等级 | 工程及位置 | 问题 | 影响 | 处理状态 |
|---|---|---|---|---|---|
## 6. 修复及复查
## 7. 未确认风险
## 8. Review 结论
```

发现问题后返回实现阶段，修复并重新 Review。

## 逻辑验证

Review 的阻断问题处理后，执行：

- 最终差异检查；
- 格式化、Lint、静态分析和类型检查；
- 编译或构建；
- 单元与集成测试；
- 关键调用链、数据读写、权限、事务、幂等和状态流转检查；
- 技术方案中的关键影响回归；
- `03.冒烟与逻辑验证.md` 中确认的验证计划。

失败时记录、分析、修复、重跑失败项和受影响回归。不得只重跑成功用例。

## 本地接口测试

本地环境可启动时：

```text
确认依赖和数据安全
→ 启动相关工程
→ 准备专用测试数据
→ 执行核心主流程接口
→ 验证范围内全部功能
→ 回归关键受影响接口
→ 检查数据库、Redis、ES、消息和日志
→ 保存证据
```

检查状态码、响应结构、业务字段、落库、缓存/索引、状态流转、权限、关键异常和直接受影响旧接口。

开始写数据前确认不是生产或不可随意修改的共享环境。需要人工登录、凭据或外部依赖时，明确请求用户协助。测试数据、请求响应、日志和截图必须脱敏，不得将凭据或生产敏感数据写入验证文档。

实际结果统一写入 `03.冒烟与逻辑验证.md` 第 5–12 节，不再创建单独逻辑验证报告。只有实际执行并有证据的内容可以标记通过；环境受限的内容写“未验证”及原因。

完成后提交 03、04、05 及关键证据，进入 G3。