是，setinterval倒计时易卡顿不准；因依赖主线程且跨端节流，应改用date.now()时间戳差值法计算剩余时间，仅用定时器触发ui刷新，并在onhide/onunload中清理、onshow中重算，配合iscounting状态锁控按钮防重复。
uni-app里用setInterval做倒计时容易卡顿或不准？
直接在 onLoad 或点击回调里裸写 setInterval，在部分安卓机（尤其低端机型）或微信小程序真机上会出现倒计时跳秒、延迟甚至卡死。根本原因是 setInterval 依赖 JS 主线程，而 uni-app 的跨端渲染、setData 调用、页面生命周期钩子可能造成任务堆积。
更稳妥的做法是用时间戳差值计算剩余秒数，只启动一次定时器做 UI 刷新：
- 记录开始倒计时的系统时间
this.startTime = Date.now() - 倒计时总时长设为
this.countdown = 60 - 用
setInterval每 500ms 刷新一次 UI，但每次显示的秒数由Math.ceil((this.startTime + this.countdown * 1000 - Date.now()) / 1000)动态算出 - 当计算结果 ≤ 0 时，清除定时器并重置状态
发送验证码按钮如何真正禁用？disabled属性在小程序里不生效？
uni-app 的 <button></button> 在微信/支付宝小程序中，仅靠 :disabled="isSending" 并不能完全阻止多次点击 —— 尤其用户快速连点时，click 事件仍可能被触发多次，因为 DOM 状态更新和事件响应存在微小延迟。
必须配合「状态锁 + 事件拦截」双保险：
- 声明响应式变量
isSending: false，点击后立即设为true - 在发送逻辑开头加守卫：
if (this.isSending) return - 按钮绑定
@click="sendCode"，不依赖disabled视觉禁用作为唯一防线 - 视觉禁用仍要保留（提升体验），但不能信任它防逻辑重复
示例片段：
sendCode() {
if (this.isSending) return;
this.isSending = true;
// 调用接口...
uni.request({
url: '/api/send-code',
success: () => {
this.startCountdown();
},
fail: () => {
this.isSending = false; // 失败也要释放锁
}
});
}
倒计时结束后没恢复按钮，或者恢复了但还能点？
常见原因是清除定时器后忘记重置 isSending 和按钮文案，或者在页面卸载时没清理定时器导致内存泄漏、状态错乱。
关键处理点：
- 倒计时结束回调里必须同步执行：
this.isSending = false和this.countText = '获取验证码' - 在
onUnload或onHide钩子中调用clearInterval(this.timer)（需提前把 timer ID 存到 data 里） - 避免在倒计时运行中跳转页面又返回，导致多个定时器叠加 —— 可在
onShow中检查并清理残留定时器
uni-app跨端时，setTimeout/setInterval 在 H5 和小程序表现不一致？
是的。H5 中定时器精度接近毫秒级；小程序（尤其微信）对定时器有节流策略，setInterval(fn, 100) 实际可能 200~300ms 才触发一次，且页面切后台时会暂停。这会导致基于固定间隔的倒计时误差累积。
所以不要依赖「每秒触发一次」，而应坚持「时间戳差值法」：
- 启动倒计时时记录
Date.now() - UI 更新用
setInterval(..., 500)即可，频率低反而更稳 - 每次 render 都重新计算剩余秒数，不累加、不递减变量
- 这样即使某次刷新延迟了，下一次也能自动校准
这个逻辑在 H5、微信、支付宝、App（vue2/v3）全平台都可靠。
最易被忽略的是：没在页面离开前清理定时器，导致倒计时在后台继续跑，回来时状态错乱；还有就是把「视觉禁用」当成「逻辑防护」，结果接口被连发三次才意识到问题。
