点赞需先更新dom再异步请求，禁用按钮防重复，css心跳动画用animationend清理class，服务端返回count覆盖显示，fetch和动画做渐进增强降级。
点击后立即更新数字但不刷新页面
点赞数必须在用户点击瞬间变化，否则体验断裂。核心是用 JavaScript 拦截点击事件，修改 DOM 中的数字文本，同时发请求给后端记录——但别等响应回来再改数字，否则有延迟感。
常见错误是写成 await fetch(...) 后再更新 UI，结果手速快的用户连点两下，第二次点击时第一次请求还没返回，导致计数错乱。
- 先更新本地
textContent（比如从12改成13） - 再异步调用
fetch('/api/like', {method: 'POST'})，失败了就用console.error记录，或弹个轻提示，但不要回退数字 - 为防重复提交，点击后可临时禁用按钮（
button.disabled = true），并在finally里恢复
点赞按钮带“心跳”动画但不影响交互
动画只是视觉反馈，不能阻塞主线程或干扰点击逻辑。CSS 动画比 JS 定时器更可靠，也更容易控制节奏。
容易踩的坑是用 setTimeout 改 class 名触发动画，结果连续点击多次，多个定时器叠加，动画卡顿甚至失控。
- 给按钮加一个固定 class，比如
btn-like，默认无动画 - 点击时只执行一次
element.classList.add('liked')，CSS 里定义.liked { animation: heartbeat 0.6s ease-out; } - 动画结束后用
animationend事件移除 class，避免 class 堆积：element.addEventListener('animationend', () => element.classList.remove('liked'))
服务端返回真实计数防止前端伪造
前端自增只是临时体验优化，最终数字必须以服务端返回为准。否则用户刷新页面、多设备登录、或绕过 JS 直接调接口，数据就会不一致。
典型问题是把后端返回的 count 字段直接覆盖到 DOM，却没判断是否比当前显示的大——如果网络慢，后发的请求先返回，反而把刚点的 +1 给“覆盖”掉了。
- 每次成功响应后，取服务端返回的
data.count赋值给显示区域：counterEl.textContent = data.count - 如果后端支持，可返回操作后的最新值（如点完赞返回
{ count: 42, liked: true }），而不是只返回“ok” - 不依赖前端传来的旧值做计算，杜绝
current + 1这类逻辑
兼容低版本浏览器时动画和 fetch 的降级处理
IE11 不支持 fetch 和 CSS @keyframes，但强行要求兼容会拖累现代浏览器体验。稳妥做法是渐进增强：基础功能（数字更新）必须可用，动画和 fetch 是加分项。
别写一堆 if (typeof fetch === 'undefined') 把整个逻辑包起来，那样代码难读且易漏分支。
- 用
try/catch包裹fetch，失败时降级用XMLHttpRequest或直接忽略请求（至少 UI 已更新） - CSS 动画加个
@supports (animation-name: heartbeat)规则，里面写动画；不支持的浏览器自动跳过 - 确保按钮的
click事件监听器本身不依赖新 API，所有降级逻辑都在回调内部
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
