点赞按钮应通过维护本地状态变量(如isLiked)控制UI与请求,点击立即禁用按钮并执行组合动画,前端拦截重复点击需检查data-processing属性,fetch需正确设置headers并处理各类HTTP及网络错误。
click 事件触发状态切换直接监听 click 是最基础也最容易出错的起点。很多人写成每次点击都发请求、不防抖、不改 UI 状态,结果用户狂点几次,后端收到重复请求,前端图标还卡在半动画状态。
核心是维护一个本地状态变量,而不是靠 DOM class 或文本内容去“猜”当前是否已点过:
data-liked="false" 初始属性,或直接用 JS 变量 isLiked 跟踪liked class、变色、加心形图标),再发请求button.disabled = true),请求完成再恢复,避免重复提交纯 transition 做颜色或缩放变化太弱,用户感知不到操作已被响应。真正有效的点赞动效关键在节奏和反馈粒度:
@keyframes 写一个 0.3s 的“放大 + 变色 + 微移”组合动画,比单纯 transform: scale(1.2) 更真实.liked 类上,且用 animation-fill-mode: forwards 保证结束帧保留transform: translateZ(0) 或 will-change: transform 防止闪屏button.liked { animation: likeAnim 0.3s cubic-bezier(0.22, 0.61, 0.36, 1);}@keyframes likeAnim { 0% { transform: scale(1) translateY(0); } 50% { transform: scale(1.3) translateY(-2px); } 100% { transform: scale(1) translateY(0); }}
后端鉴权和幂等性是根本,但前端必须做第一道拦截,否则体验崩坏。这里不是靠 localStorage 存“所有点过的 ID”,而是聚焦单个按钮的即时防护:
立即学习“前端免费学习笔记(深入)”;
button 的 data-processing="true" 设为 true,并检查该值再决定是否响应下一次 clickfetch 发点赞请求时容易漏掉的三个 header 和错误处理点看似简单的 POST 请求,实际在跨域、缓存、错误分类上埋了不少坑:
Content-Type: application/json,否则后端可能解析不到 body
Credentials: 'include'(如果走 cookie 登录),否则请求不带 sessionresponse.status === 0(如 CORS 失败、网络中断),此时 response.json() 会直接 reject,不能只 catch fetch() 异常response.ok 判断成功——它只看 status 是否在 200–299,而业务错误(如 403 禁止点赞)也需要被识别并提示用户复杂点在于:点赞是高频低权重操作,但用户对“点了没反应”极度敏感。动画、状态、网络三者只要有一环没对齐,就会让人觉得“按钮坏了”。所以宁可多几行状态管理代码,也不要省略中间态控制。