倒计时按钮应使用 setInterval 配合时间戳校准实现，避免累计误差；禁用按钮需同时设 disabled 属性和 CSS 视觉态；定时器必须及时清除；验证码发送需前端防抖+频次限制（记录 lastSendTime 并比对间隔），后端必校验。
倒计时按钮怎么用 setInterval 实现不卡顿？
直接用 setTimeout 递归容易丢帧或跳秒，尤其在页面切到后台再切回来时；setInterval 更稳，但必须配合时间戳校准，否则累计误差会越来越大。
- 别用
count--纯变量减法，要基于当前时间算剩余秒数：Math.max(0, Math.floor((endTime - Date.now()) / 1000)) - 倒计时期间禁用按钮：给按钮加
disabled属性，同时用 CSS 控制视觉态（比如opacity: 0.6），别只靠 JS 绑定事件拦截 - 清除定时器必须做：点击后立即
clearInterval(timerId)，否则切换页面、重复点击可能触发多个定时器叠加 - 移动端注意：部分安卓 WebView 在页面不可见时会暂停
setInterval，所以一定要用时间戳计算，不能依赖“执行次数”
验证码发送按钮的防抖和频次限制怎么写？
单纯前端限制只是体验优化，后端必须校验；但前端做两层防护能减少无效请求——防快速连点 + 防短时间重复发。
- 按钮点击后立刻置为
disabled并更新文案（如“60s 后重发”），同时记录lastSendTime时间戳 - 下次点击前先判断：
if (Date.now() - lastSendTime ，60 秒是常见策略，可按需改 - 别用
localStorage存发送时间——用户清缓存就失效；要用sessionStorage或纯内存变量（页面不刷新前提下） - 如果用户手动修改系统时间，
Date.now()会不准，但这是小概率场景，后端二次校验兜底即可
disabled 状态下样式不生效？CSS 怎么写才可靠
很多同学写了 button:disabled { opacity: 0.5; }，但发现没反应——问题常出在选择器权重或伪类顺序上。
- 确保 CSS 里
button:disabled的声明在普通button规则之后，否则会被覆盖 - 避免用
!important，改用更具体的选择器，比如.send-btn:disabled - 移动端 Safari 对
:disabled支持没问题，但某些老版 UC 内核需要加pointer-events: none辅助禁用点击穿透 - 文字颜色建议用
color: #999而非opacity，否则屏幕阅读器可能读不出灰度文字
倒计时结束自动启用按钮，但用户可能提前刷新页面怎么办？
刷新后按钮又变可用，用户就能绕过限制——这不是 bug，是设计预期；真要防，得靠服务端 token 或短信唯一 ID 校验，前端只能尽力同步状态。
- 可在
beforeunload事件里把倒计时剩余时间存到sessionStorage，页面加载时读取并恢复倒计时（仅限同 tab 未关闭） - 恢复逻辑要加校验：
if (storedTime > 0 && storedTime ，防止伪造长时效 - 不要用
localStorage存倒计时——用户换设备或清数据后，这个状态就失效了，反而造成困惑 - 最稳妥的做法：每次点击都向后端请求发送资格（带手机号 hash 或设备指纹），前端只负责展示结果
实际业务里，倒计时和发送限制的边界很模糊——比如用户点了两次，第一次失败、第二次成功，这时倒计时该不该启动？这类细节得和后端约定清楚，前端照协议走就行。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
