---
name: sie-front-code-review
description: 基于前端编码规范执行 React + TypeScript + Ant Design 项目的代码评审，输出按严重级别排序的问题清单与修复建议
agent_created: true
---

# Sie Front Code Review

## 目标

基于 `docs/40-project_conventions/frontend-integration/05-前端编码规范.md` 对前端改动进行结构化评审，优先识别：

- 功能回归风险
- 规范违规
- 类型与可维护性问题
- 缺失测试与验证

评审结论必须可落地，禁止泛泛而谈。

## 适用范围

- React 19 + TypeScript 6 + Ant Design 6 + ProComponents
- 路由、页面、组件、hooks、stores、api、mocks、i18n 相关变更

## 评审输入

至少收集以下信息：

1. 改动文件列表与 diff
2. 相关需求或任务说明
3. 影响模块（页面路径、API 域、字典、权限）
4. 可用验证结果（build/eslint/test）

## 评审输出格式（必须遵守）

1. Findings（按严重级别排序）
2. Open Questions / Assumptions
3. Change Summary（可选，简短）

每条 Finding 必须包含：

- 严重级别：Critical / Important / Minor
- 位置：文件路径 + 行号
- 现象：当前行为
- 风险：可能导致的问题
- 修复建议：明确可执行

如果无问题，明确写：`No findings`，并补充残余风险和验证缺口。

## 严重级别判定

- Critical：会导致功能错误、数据错误、安全/权限问题、路由不可达、构建失败
- Important：不符合核心规范、较高维护风险、明显类型/状态管理问题
- Minor：风格一致性、可读性优化、非阻断改进

## 必查清单

### A. 路由与页面路径

1. 页面文件路径是否与后端菜单 `component` 完全对齐
2. 动态路由场景是否可能触发 `Component not found`
3. 外链路由是否被错误注入

### B. 列表页与表单模式

1. 列表页是否优先使用 `ProTable`（非树形场景）
2. `search: false`、`valueType`、`search.transform` 用法是否规范
3. 日期区间列是否使用 `render`（不是 `renderText`）
4. Modal/Drawer 是否遵循约定 props（`open/id/onSuccess/onCancel|onClose`）
5. 编辑提交是否合并 `originData`

### C. Modal / Drawer 使用规范（重点审查）

1. Modal 是否使用 `onCancel`，Drawer 是否使用 `onClose`，避免混用回调语义
2. 是否使用约定四件套 props：`open`、`id`、`onSuccess`、`onCancel|onClose`，避免 `ref.open()` / `defineExpose` 模式
3. 关闭清理策略是否正确：Modal 用 `destroyOnHidden`，Drawer 用 `destroyOnClose`
4. 编辑模式是否通过 `originData` + `values` 合并提交，防止未挂载字段丢失
5. 编辑态隐藏字段是否使用 `hidden={!!id}`，避免条件渲染导致 `validateFields` 漏字段
6. Drawer 宽度是否与字段规模匹配（4~10: 256；10~20: 600；21~30: 750；>30: 1024）
7. 表单布局是否与字段规模匹配（一栏/两栏/三栏/四栏），输入控件宽度是否统一 `width: 100%`
8. Modal/Drawer 标题是否遵循“新增/编辑”切换规则，避免与业务状态不一致
9. 是否存在手动 `resetFields` 与销毁策略冲突、重复清理导致状态闪烁
10. Drawer footer 操作是否明确（取消/确定），并正确处理提交 loading 与异常兜底

### D. 类型与代码质量

1. 是否出现 `any` / `as any` 滥用
2. API 入参出参、store、hook 暴露类型是否显式
3. hooks 依赖是否完整，是否违反 `react-hooks` 规则
4. 单文件/函数复杂度是否明显超标且未拆分

### E. 业务规范一致性

1. 时间字段是否统一使用 `dateFormatter`
2. 字典字段是否使用 `DictTag` + `valueEnum/getDictOptions`
3. 按钮是否通过 `<Access code="...">` 做权限包裹
4. i18n 文案是否硬编码，命名空间与 key 结构是否一致

### F. API / Mock / 上传

1. API 是否复用统一 `request` 与 `ApiResponse/PageResult` 类型
2. Mock handler 路径是否含 `/admin-api/` 前缀
3. 上传组件是否规避 Upload 的 `value` 误用
4. token / tenant-id 头是否保持一致

### G. 可验证性

1. 是否有 `npm run build` 通过证据
2. 是否有 `eslint` 检查证据（至少改动文件范围）
3. 若缺少验证，必须在输出中明确标注 Testing Gap

## 评审执行流程

1. 先读规范与需求，再看 diff，禁止脱离上下文评审
2. 优先找 Critical/Important，再补 Minor
3. 同类问题合并描述，避免重复噪音
4. 建议给出最小改动方案，避免不必要重构
5. 结论必须可被开发者直接执行

## 禁止项

- 只给“代码不错/建议优化”但无定位与风险
- 未验证事实就下结论
- 忽略构建、lint、权限、路径对齐等硬约束
- 仅从风格角度评审，遗漏行为正确性

## 快速评审模板

```markdown
## Findings

1. [Critical] path/to/file.tsx:88
   - 现象：...
   - 风险：...
   - 建议：...

2. [Important] path/to/file.ts:34
   - 现象：...
   - 风险：...
   - 建议：...

## Open Questions / Assumptions

1. ...

## Change Summary

- ...
```

## 参考依据

- `docs/40-project_conventions/frontend-integration/05-前端编码规范.md`