uni-app倒计时易跳秒因后台降频，应以服务端时间戳实时计算；手机号校验需用工信部号段正则并清洗格式；按钮禁用须结合变量、防抖与后端幂等；跨端需条件编译区分微信小程序与App实现。
uni-app 里用 setInterval 做倒计时容易卡顿或跳秒？
不是 setInterval 本身有问题，而是 uni-app 在部分安卓 WebView 或小程序环境下，页面进入后台/切页后定时器会被系统降频甚至暂停，导致恢复时直接“跳秒”。更稳妥的做法是用服务端返回的过期时间戳做「实时差值计算」，而非纯客户端累减。
实操建议：
- 发送短信成功后，后端必须返回一个精确的
expire_timestamp（如1717023600），单位为秒，不要只给「60秒」这种相对值 - 前端用
const remain = Math.max(0, Math.floor((expire_timestamp * 1000 - Date.now()) / 1000))实时算剩余秒数 - 用
watch或onMounted+setInterval(() => {}, 300)每 300ms 更新一次 UI（比 1000ms 更稳，能缓解跳秒感） - 务必在组件卸载时清除定时器：
clearInterval(this.timer)（Vue 2）或onUnmounted(() => clearInterval(timerRef.value))（Vue 3 Composition API）
uni-app 发送短信前必须校验手机号格式，但正则写错会放行非法号码
国内手机号常见误判：用 ^1[3-9]\d{9}$ 看似合理，但会匹配到 140、141、144 等已注销号段，且不兼容携号转网后的新号段（如 192、199）。微信小程序审核也明确要求校验逻辑与运营商一致。
实操建议：
- 采用工信部最新号段库简化版正则：
^1(3[0-9]|4[01456879]|5[0-9]|6[2567]|7[0-9]|8[0-9]|9[0-9])\d{8}$ - 在
onBlur和提交前双重校验，避免用户粘贴带空格/括号的号码（先value.replace(/\s|\(|\)|\-/g, '')清洗） - 若项目接入了短信平台（如阿里云、腾讯云），它们 SDK 通常自带
isMobileValid工具函数，优先调用，比正则更准
点击「获取验证码」按钮后禁用逻辑失效，用户连点多次触发重复请求
单纯靠 disabled="true" 不够——uni-app 的 在某些 Android 机型上仍可被快速连点穿透；而且如果请求失败没重置状态，按钮就永远卡死。
实操建议：
- 禁用状态必须绑定 data 中的变量（如
sendDisabled），不能只靠内联表达式 - 发送前立即设
this.sendDisabled = true，并在finally中重置：this.sendDisabled = false - 加防抖层：定义
isSending = false，请求前判断if (this.isSending) return，开头设this.isSending = true，finally设false - 后端接口需幂等：同一手机号 60 秒内重复请求，直接返回
{ code: 208, msg: "请求过于频繁" }，前端捕获后不重置按钮，仅提示
uni-app 条件编译下，微信小程序和 App 端的短信发送方式完全不同
微信小程序不能直接调用短信 API（无权限），必须走「手机号快速验证组件」或「wx.login + 后端发码」；而 App 端（Android/iOS）可用 uni.showToast 提示后直接调后端接口。混淆这两者会导致某端功能完全不可用。
实操建议：
- 用条件编译区分入口：
#ifdef MP-WEIXIN // 调用微信手机号组件或 wx.request 发送 # endif #ifdef APP-PLUS // 直接调自有短信接口 # endif
- 微信小程序推荐用
获取加密手机号，由后端解密后发码（更安全，且规避短信频控） - App 端若需调用原生短信能力（如跳转系统短信界面），要用
uni.openLocalFile或原生插件，不能依赖 H5 的SMSAPI（不存在）
倒计时和短信逻辑看着简单，真正上线后最常出问题的是「时间戳不同步」「连点没兜底」「跨端路径没拆开」——这三处不手敲一遍真实设备测试，光看模拟器很容易漏。
