uni-app中setInterval倒计时在页面跳转、切后台或小程序非活跃时会失效，应改用服务端下发的过期时间戳（如expire_time），前端通过Date.now()实时计算剩余秒数，并在onShow等生命周期中重算以确保准确。
uni-app里用setInterval做倒计时会失效？
在页面跳转、切后台或小程序进入非活跃态时，setInterval大概率被系统暂停或直接清除，导致倒计时卡住、跳变甚至归零。这不是 bug，是平台限制——尤其在微信小程序和 App 端更明显。
真正可靠的方式是：用服务端下发的过期时间戳（如 expire_time: 1718234567），前端只做「本地时间对比」，不依赖定时器累减。
- 每次渲染前，用
Date.now()和expire_time * 1000算剩余秒数，再格式化显示 - 用
watch或onShow触发重算，避免切页后状态错乱 - 避免在
onLoad里启动setInterval后没清理，造成内存泄漏和多例叠加
验证码按钮点击后如何禁用并动态更新文案？
按钮禁用不能只靠 disabled 属性，还要配合状态变量控制样式和点击逻辑，否则用户可能连点多次触发重复请求。
推荐用一个响应式变量（如 isCounting）统一管理：
- 点击后立刻设
isCounting = true，按钮置灰 + 文案变成「60s」 - 用
setTimeout模拟倒计时（比setInterval更易控制、不易累积误差） - 每次递减后更新
countdown值，用v-if或三元表达式切换文案：{{ isCounting ? countdown + 's' : '获取验证码' }} - 倒计时结束必须手动设
isCounting = false，否则按钮永远无法再次点击
uni-app中发送验证码请求后怎么同步服务端时间？
很多开发者直接本地减 60 秒，但网络延迟、设备时间不准会导致倒计时与服务端实际有效期不一致，用户可能收不到码就过期了。
正确做法是：接口返回必须带精确过期时间，比如：
{
"code": 0,
"data": {
"expire_at": 1718235000
}
}然后前端存下来，在倒计时计算中始终以它为基准：
- 当前剩余秒数 =
Math.max(0, Math.floor((expire_at * 1000 - Date.now()) / 1000)) - 注意
expire_at是秒级时间戳，要乘 1000 转毫秒，再和Date.now()对齐 - 建议封装成计算属性或
computed，避免在data里反复写重复逻辑
App 和小程序里倒计时自动恢复的坑
用户按 home 键切后台再回来，或者小程序被系统回收后重新激活，setInterval 已丢失，但页面 data 还停留在旧值，看起来像“卡住”。这时候不能靠重启定时器硬拉，而要检测时间偏移。
- 记录倒计时开始时的
startTime = Date.now()和总时长（如 60） - 在
onShow里重算：elapsed = Math.floor((Date.now() - startTime) / 1000)，再取Math.max(0, 60 - elapsed) - 如果使用服务端时间戳方案，则只需在
onShow里强制触发一次剩余时间重算即可 - 别忘了在
onHide清掉setTimeoutID，防止切后台后还在后台执行
最麻烦的其实是安卓 App 的进程保活策略——某些厂商会杀掉 JS 线程，此时唯一健壮的做法就是：把倒计时逻辑完全交给服务端判断，前端只负责展示和防误触。
