周末把阳台改成了小菜园，第一批小番茄红了。
点击 → 看到变化还没点
界面：未赞 128服务器：未赞 128一致
界面：未收藏服务器：未收藏一致
网络日志已发出 0 个请求
还没有请求
动效 · 节奏与反馈
微交互Micro-interaction
把一次小操作的反馈拆成触发、立即变化、结果确认、失败回滚四步来要求和验收，并在请求中防止重复提交。
先在帖子上拼一次点赞反馈
默认是“什么反馈都没加”的点赞。先照任务点两次，再一项项勾上，看每一步缺了会出什么事。
点赞反馈拼装台
先勾选这次点赞要带哪些反馈、选一个网络状况，再到帖子上点 ♡ 或「收藏」。看按钮自己、帖子底部的网络日志和“界面 vs 服务器”对照怎么变。
任务：现在五个反馈全关、网络是「慢」。点一次 ♡，1.5 秒内再点一次——看按钮有没有反应，再看帖子底部的网络日志。
从刚才的操作里提炼
- 100ms 内必须有变化。全关时点下去要等 1.5 秒才变，用户以为没点上，再点就成了第二个请求——帖子里“点击 → 看到变化”那一格会告诉你差多少。
- 乐观更新：先改界面，再等服务器。「立即变色」「计数变化」让按钮在 0ms 变红 +1，请求在后台确认；正常网络下你几乎感觉不到等待。
- 失败要回滚，并说明。只做乐观更新、不做回滚时，失败后对照表显示“界面：已赞 / 服务器：未赞”，刷新就变回去；回滚 + 提示 + 重试才诚实。
- 请求中防重复提交。不拦的话连点会发出多个请求，接口不防重时服务器多算一次；拦下（或合并成最后一次意图）才稳。
- 弹跳只是装饰。它让反馈更有手感，但去掉不影响任何结果——所以减少动效时第一个去掉的就是它。
什么时候用
凡是“点一下、马上要知道成没成”的小操作都适用。
- 点赞、收藏、关注、加入购物车、开关设置。
- 结果可预期、失败率低、撤销代价小的操作——适合乐观更新。
- 付款、下单、删除账号：等服务器确认后再显示成功，期间显示“处理中”。
- 结果由服务器决定的操作（抢券、排队）：先告诉用户“已提交”，别假装已成功。
怎么用：按四步跟 AI 说，按四步验收
别只说“加个好看的动画”，把触发、立即变化、确认、失败回滚都写进需求。
- 跟 AI 说：“点赞点击后 100ms 内图标变红、计数 +1（乐观更新）；请求失败回滚并轻提示‘点赞失败，请重试’；请求中重复点击不重复提交；按钮有 aria-pressed，读屏读出‘已点赞’；减少动效时去掉弹跳。”
- 看报告：认得出
optimistic update、rollback、aria-pressed、disabled / pending这些词；没出现“失败怎么办”就追问。 - 上手验收：DevTools 把网络调慢或离线，点一次看是否立即变化、失败是否回滚并提示；快速连点三次，看 Network 面板是不是只有一个请求；用 Tab + 空格也能点赞。
正反例：同一个点赞，只差回滚这一步
断网时点赞仍然变红 +1，用户以为成功；刷新页面后心又变空，他觉得产品“吞了我的赞”。
同样断网，按钮先变红，失败后 1.5 秒内恢复成未赞，并提示“点赞失败，请重试”——界面始终说真话。
快速自测
用户点“关注”后，按钮要等 2 秒接口返回才变成“已关注”，期间用户又点了一次，结果变成了取消关注。最该先补哪一步？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。