点击后立即更新计数但不刷新页面，核心是用fetch异步请求配合DOM局部更新；需禁用按钮防重复、服务端幂等处理、前端同步维护本地状态，并用AbortController和版本号确保响应有序。
点击后立即更新计数但不刷新页面
核心是用 fetch 发送异步请求，配合 DOM 操作局部更新。不能靠 location.reload() 或整页提交表单——用户会感知卡顿，且无法保留滚动位置。
常见错误：把点赞按钮写成 <form> 提交，后端返回整个 HTML 片段再 innerHTML 替换——这容易覆盖掉已绑定的事件监听器，导致点第二次失效。
- 前端只传
postId或userId，后端返回纯 JSON，例如{ "count": 12, "liked": true } - 用
button元素而非a，避免默认跳转；加上type="button"防止意外触发表单提交 - 点击后立刻禁用按钮（
button.disabled = true），防止重复点击；请求失败再恢复
如何避免重复点赞或取消时状态错乱
关键在服务端做幂等处理，但前端也要同步维护本地状态。很多人只改数字不改按钮样式，结果用户看到“已赞”按钮还能再点一次。
典型现象：双击点赞按钮，后端收到两条请求，数据库里多加了一次，但前端计数只+1，最终数据对不上。
立即学习“前端免费学习笔记（深入）”；
- 每次请求前检查
data-liked属性：if (btn.dataset.liked === "true")就走取消逻辑 - 成功后立刻更新两个东西：
btn.textContent（如从“赞”变“已赞”）和btn.dataset.liked值 - 服务端接口必须接受
method: "PUT"或"PATCH"，路径带资源 ID，比如/api/likes/123，而不是用POST /api/like硬塞 ID 在 body 里
列表滚动时点赞状态加载不一致
懒加载列表或分页场景下，用户快速滚动，IntersectionObserver 触发时机和接口返回顺序不一致，导致某条目显示“未赞”，点完却变成“已赞”，但实际数据库没变——其实是旧响应覆盖了新响应。
本质是请求并发 + 回调无序执行。别用全局变量存 pending 请求，每个按钮要独立管理自己的请求生命周期。
- 给每个按钮加唯一
data-request-id，请求发起时记录；回调进来先比对 ID，不匹配就直接 return - 用
AbortController在按钮离开视口或被销毁前中止请求：controller.abort() - 服务端响应里带上时间戳或版本号（如
"version": 1698765432），前端只采纳最新版本的响应
后端返回 401 或 403 时前端怎么兜底
用户登录态过期、token 失效、权限不足，这些不是前端能解决的问题，但体验不能断。弹个“请重新登录”就完了？不行——得让点赞动作可重试，且不丢失原始意图。
错误做法：捕获 401 后直接 window.location.href = "/login"，用户刚点的那条内容完全丢失上下文。
- 把点赞操作封装成可序列化的动作对象：
{ type: "toggleLike", targetId: "post_456" }，失败时存到sessionStorage - 登录成功后自动重放队列里的动作（注意去重）
- 按钮上加
data-pending="true"样式类，用 CSS 显示 loading 动画，比文字提示更直观
