定位：决策表，不是审美

后台系统的交互形态高度收敛——同一类场景应该用同一种控件。 本文给判据和数字，照选。不要每个页面重新设计。

一、弹窗 / 抽屉 / 新页面（最高频的模糊点）

1.1 决策树（按顺序问）

① 是"确认类"操作吗（删除、提交、审批）？
   → 是：Modal（小，宽 420-480）  结束

② 内容是只读查看吗？
   → 是：Drawer（不离开列表，保留上下文）
   → 否：继续

③ 表单字段数？
   ├─ ≤ 7 个        → Modal（宽 600）
   ├─ 8–20 个       → Drawer（宽 640-720）
   └─ > 20 个或分步  → 新页面（路由 + URL）

④ 操作完还要回头看列表吗？
   → 要：Drawer（列表在旁边，关掉就回来）
   → 不要：Modal 或新页面都行

1.2 三种形态的对照

1.3 尺寸规范（直接用，别自己定）

移动端例外：< 768px 时，Drawer 一律变全屏，Modal 变底部弹出（placement="bottom"）。

1.4 一条决定性判据

用户操作完，需要立刻对照列表看结果吗？ 需要 → Drawer（列表还在） 不需要 → Modal

例：批量改状态 → Modal（改完看列表，但操作本身不需要对照） 例：编辑订单备注 → Drawer（一边看订单信息一边改）

二、提示形态：六种，用错就烦人

判断口诀

一次性结果反馈   → message
需要用户读一段   → notification
状态一直存在     → Alert
解释某个元素     → Tooltip（短）/ Popover（长）
解释一个字段     → Hint
需要用户做决定   → 不是提示，是 Modal

agent 常犯的三个错

提示文案规范

• 成功：动词 + 结果：「保存成功」「已删除 3 条」
• 失败：原因 + 下一步：「余额不足，请先充值」（不要只说"操作失败"）
• 不要用感叹号，不要用"亲"
• 不要在文案里暴露技术细节（SQL、堆栈）

三、列表页：搜索与分页要不要

3.1 要不要条件搜索

判据：用户会不会"按某个条件精确找一条记录"？ 会 → 必须加。

3.2 要不要分页

后台系统一律用分页，不用无限滚动。 理由：要跳到第 N 页、要知道总数、要能分享 URL。

3.3 分页组件规范

• 位置：表格右下角
• 显示：共 128 条 + 页码 + 20 条/页 切换
• pageSize 选项：10 / 20 / 50 / 100
• 总数为 0 时不显示分页（显示空态）
• 换 pageSize 时 page 重置为 1
• 筛选变更时 page 重置为 1

3.4 排序

• 默认按 created_at DESC（新的在前）
• 可排序列在表头加排序图标
• 服务端排序，不要前端排

四、表格 vs 卡片

后台管理 95% 用表格。 不要为了"好看"把表格改成卡片。

表格列规范

• 前 1–2 列固定（ID / 名称）
• 操作列 固定在右侧，宽 120–180
• 长文本列设 ellipsis + Tooltip，不要撑宽
• 状态列用 StatusTag（颜色来自 constants/options）
• 金额列右对齐、等宽字体、两位小数
• 时间列统一格式 YYYY-MM-DD HH:mm
• 行高默认（不要自定义）
• 斑马纹可选，行 hover 高亮必须有

五、操作按钮放哪

5.1 行内操作

顺序：查看 → 编辑 → 其他 → 删除（删除永远在最后，且红色）

5.2 页面级操作

PageContainer 右上角：
[次要操作] [主要操作]
例：[导出] [新建订单]

• 主操作只用一个（主色按钮）
• 其余用默认按钮
• 危险操作（批量删除）放在工具栏，且需要先勾选

5.3 批量操作

• 勾选后才出现工具栏：「已选 3 项」+ [批量删除] [批量导出] [取消选择]
• 批量操作必须有数量提示
• 危险批量操作二次确认要显示数量

六、三态：空、加载、错误

6.1 空态分三种，文案不同

不要三种都用「暂无数据」。

6.2 加载态

不要用全屏 loading 遮罩——挡住用户所有操作。

6.3 错误态

七、表单布局

表单细则

• label 必须有，不用 placeholder 代替
• 必填标红星在 label 前
• 字段顺序：重要/常用在前，选填在后
• 长文本用 TextArea（rows=3），不要单行 Input
• 日期用 DatePicker，不要手输
• 金额用 InputNumber，precision=2，右侧加单位
• 提交按钮固定在表单底部或 Drawer footer
• 提交中必须禁用按钮（防重复提交）
• 取消时若有改动，二次确认

八、危险操作确认分级

三、四级必须说明后果：「删除后该分类下的 12 个商品将一并删除，此操作不可恢复。」

九、标准页面骨架（每个页面照这个搭）

<PageContainer title="订单管理" extra={[导出, 新建]}>
  ┌─ 页头：标题 + 面包屑 + 操作按钮（右）
  ├─ SearchForm：关键词 | 状态▾ | 日期范围 | [查询] [重置] [展开▾]
  ├─ 工具栏：[已选 N 项] [批量删除] ... [列设置] [刷新]
  ├─ ProTable：三态 + 状态标签 + 操作列固定右
  └─ 分页：右下角，共 N 条 | 页码 | 20 条/页
</PageContainer>

新建页面时，先套这个骨架，再填内容。不要重新设计页面结构。

十、决策速查表（agent 直接查）

十一、反面清单

1. ❌ 20 个字段的表单塞进 Modal（滚动条里填表）
2. ❌ 一个确认弹窗宽 800（内容只有一行字）
3. ❌ 用 message 展示需要读的详细信息
4. ❌ 用 alert() / window.confirm()
5. ❌ 三种空态都用「暂无数据」
6. ❌ 数据 20 条也上分页
7. ❌ 后台列表用无限滚动
8. ❌ 把表格改成卡片"为了好看"
9. ❌ 全屏 loading 遮罩
10. ❌ 危险操作没有二次确认
11. ❌ 删除按钮放在操作列第一个
12. ❌ 每个页面自己设计一套结构（不套骨架）