操作必有反馈
用户点了一下，屏幕上必须有东西变化。没有变化，他的默认假设是没点上。
你会遇到的现象
- 用户连点三次提交，后台收到三条重复数据
- 点了之后过两秒才有反应，中间那两秒他以为坏了
- 操作成功了，但页面上看不出哪里变了
三层反馈
| 层 | 什么时候出现 | 它回答的问题 |
|---|---|---|
| 即时反馈 | 手指抬起的瞬间 | 我点上了吗。按钮变色、变成加载态、涟漪效果 |
| 结果反馈 | 操作完成时 | 成功了还是失败了。轻提示、状态标签、错误信息 |
| 状态反馈 | 操作完成之后一直存在 | 现在是什么状态。列表里的数据真的变了、标记变了 |
按耗时选形式
乐观更新
有一类操作可以不等服务器：点赞、收藏、勾选待办。界面先按成功处理，请求失败了再退回来并提示。
- 适合用的：轻量、高频、失败了退回来代价很小的操作。点赞点错了退回去，用户不会有损失。
- 不适合用的：涉及钱、不可逆、或者结果需要服务端计算的操作。下单、支付、删除，都要等真实结果。
- 失败时必须退回并说明。悄悄退回去比不做乐观更新更糟——用户以为成功了，过一会儿发现没有。
给 AI 的话
CLAUDE.md · 反馈规则
## 操作反馈 任何会触发请求的操作，都要实现三层反馈： 1. 即时：点击瞬间按钮进入 loading 态并禁用，防止重复提交。 2. 结果：成功或失败都要有明确提示。失败的提示要包含 原因和下一步（见提示语规范）。 3. 状态：操作完成后，页面上相关的数据必须同步更新， 不能只弹提示不刷新列表。 按耗时选形式： - < 0.1s 不显示加载态 - 0.1~1s 局部加载态（按钮内），不要遮罩整页 - > 1s 骨架屏或进度条 - > 10s 允许后台运行，给出可离开的入口 乐观更新只用于点赞、收藏、勾选这类轻操作， 且失败时必须回滚并提示。涉及金额、删除、 不可逆的操作一律等待服务端结果。