Dashboard 后台

搭后台管理系统（admin dashboard / back-office）的口味：不 clone 样板再做减法，按「形状目录」组装 —— 每种页面形态（表格、看板、向导、图表页……）是一个带固定契约的「形状」，从目录里挑、按说明拼，而不是发明新结构。

本目录就是这份形状目录本身：36 个形状，一个形状一篇小文，配一个能直接玩的活 demo（纯客户端 React 单页，iframe 同域嵌入，AI 可直接 GET 源码 —— 机制见写作规范·嵌入交互单页）。要搭某个后台页面，从下表挑最接近的形状进去照做。¹

完整目录（36 形状）

36 形状全部成文（「批量操作」合到表格、「空态」合到反馈状态，故实际 35 篇文章），按分组归档在 reference/<分组>/ 下。

一篇形状文章怎么用

每篇都是同一个规格，从上往下四件东西，各有各的用法：

1. 开头一段 —— 这个形状解决什么问题、什么时候选它。选型阶段只读这段就够。
2. 活 demo +「试这几下」 —— 先玩两下，确认交互是不是你要的，别靠想象拍板。
3. 「规矩」 —— 这个形状的不变量，施工时逐条对照落实；demo 与真实版的替换点（数据层、URL 状态、服务端鉴权）也标在这一节。
4. 文末 —— 蓝本永链（钉 commit，想读原文去 GitHub）+ 可折叠的 demo 源码（自包含、未压缩）。

共享不变量（每个形状都服从）

形状能互相拼装，靠的是同一组契约，不是运气：

1. 列表参数一个形状：{ page, pageSize, search?, sortBy?, sortDir?, filters? } → { rows, total }
2. 数据只走服务端函数，鉴权在服务端（requireUser / requireRole），密钥不进客户端
3. 列表/选中状态放 URL（分享、刷新、后退都不丢）；例外：多选等瞬态 UI 状态放局部 state
4. 查询键约定：["<resource>", "list", params] / ["<resource>", "detail", id]，变更后失效 ["<resource>"]
5. 反馈：变更必 toast；破坏性操作先过确认弹窗
6. 每个数据视图显式处理 loading / empty / error
7. 资源住 features/<name>/，路由住 routes/_app/<name>

从单个形状到一整个后台

一页后台通常是几个形状的拼装，先后有讲究：

• 先数据，后 UI：屏幕要有自己的数据，先立一条 CRUD 纵切 —— 表格打底、表单进出数据、详情页看单条；只是给已有数据换个看法、加层交互（筛选面板、保存视图、看板……），直接往纵切上叠 UI 形状。
• 平台能力最后横切：权限门控、全局搜索、i18n、计费不属于哪一页，等页面成形后统一接入。

动工前值得通读的两份系统级契约（本目录唯二留档的蓝本原文 —— 它们跨所有形状，切不进任何单篇文章）：

• PATTERNS.md —— 36 形状总目录 + 共享不变量的完整表述，施工前扫一遍建全貌
• backends/CONTRACT.md —— 前后端线协议。本目录的 demo 全是内存态，把形状接上真后端时，这份契约是唯一依据