倒计时不准或跳秒应避免用 setInterval 累减，改用服务端返回过期时间戳实时计算；按钮防连点需逻辑层状态锁+早期返回；页面切后台后需在 onShow 中重算剩余时间。
倒计时不准或跳秒？别用 setInterval 累减
直接在 sendCode 里写 setInterval(() => { this.countdown-- }, 1000)，在安卓低端机、微信小程序真机或切后台后大概率跳秒、卡死甚至归零。根本原因是 setInterval 依赖 JS 主线程，而 uni-app 跨端渲染、setData、生命周期钩子可能造成任务堆积或被系统暂停。
正确做法是：只用定时器触发 UI 刷新，剩余秒数由时间戳实时计算：
- 服务端返回精确过期时间戳，例如
expire_at: 1718235000（单位：秒） - 前端存为
this.expireTime = res.data.expire_at * 1000（转成毫秒） - 启动一个轻量定时器（如每 500ms 执行一次），显示值始终用
Math.max(0, Math.floor((this.expireTime - Date.now()) / 1000))动态算出 - 不维护“当前还剩几秒”的变量，避免误差累积
按钮点了还能再点？状态锁必须加在逻辑层
仅靠 :disabled="isCounting" 在微信/支付宝小程序中不可靠——用户快速连点时，@click 事件仍可能多次触发，因为 DOM 状态更新和事件响应存在微小延迟。
必须配合「状态变量 + 早期返回」双保险：
- 声明响应式数据：
isCounting: false - 点击回调开头立即加守卫：
if (this.isCounting) return - 确认接口请求发起后，才设
this.isCounting = true - 接口
fail或catch中也要重置：this.isCounting = false，否则失败后按钮永远点不了
页面切后台再回来，倒计时卡住不动？onShow 必须重算
微信小程序和 App 环境下，页面切后台时 setInterval 会被系统暂停或清除，但 data 里的 countdown 值还停留在旧数字，看起来像“卡住”。不能靠重启定时器硬拉，得检测真实时间偏移。
关键动作在 onShow 生命周期里：
- 先判断是否还在倒计时：
if (!this.isCounting || !this.expireTime) return - 重新计算剩余秒数：
const remain = Math.max(0, Math.floor((this.expireTime - Date.now()) / 1000)) - 如果
remain ，立刻执行结束逻辑：<code>this.isCounting = false、恢复按钮文案、清定时器 - 否则继续运行已有定时器（无需新建）
倒计时结束没恢复按钮？状态和 UI 必须同步重置
常见错误是只清了定时器，却忘了还原 isCounting 和按钮显示文案，导致 UI 卡在「1s」或一直灰着。
倒计时归零的处理必须原子化，三件事缺一不可：
- 调用
clearInterval(this.timer)并设this.timer = null - 设
this.isCounting = false - 设按钮显示文案为原始值，例如
this.countText = '获取验证码'
更稳妥的做法是把这三步封装成 resetCountDown() 方法，在定时器循环体、onUnload、onHide、onShow 多处统一调用——跨端一致性最脆弱的地方，往往就藏在这些“顺手补一句”的遗漏里。
