短信发送必须由后端发起，uni-app前端只能调用自有接口；倒计时需绑定页面生命周期、清除定时器并统一管理状态。
uni-app里调用短信验证码接口，别直接写uni.request
绝大多数人卡在这一步：以为只要发个 HTTP 请求就能触发短信，结果收不到码、没报错、控制台静悄悄。根本原因是——短信发送必须由后端发起，前端（包括 uni-app）只能调用你自己的服务端接口，不能直连短信平台的 API（鉴权密钥暴露风险极大，且各大平台明确禁止）。
实操建议：
- 在你的 Node.js / PHP / Java 后端写一个
/api/send-sms接口，接收手机号、场景标识（如register或reset-pwd），校验频率、有效期、图形验证码（如有）后，再调用短信平台 SDK 发送 - uni-app 中只调用这个自有接口：
uni.request({ url: 'https://your-api.com/api/send-sms', method: 'POST', data: { phone: '138xxxx1234' } }) - 务必在后端做手机号格式校验、60秒防刷限制（用 Redis 存
sms:138xxxx1234+ 过期时间）、错误日志记录——前端无法替代这些逻辑
uni-app倒计时按钮状态管理，别用setInterval裸写
常见错误现象：点击“获取验证码”后倒计时开始，但切到后台再切回来，倒计时卡住/跳变/重复执行；或者多个页面共用同一倒计时变量导致混乱。
原因在于 setInterval 没有和页面生命周期绑定，也没做清除兜底。
实操建议：
- 把倒计时逻辑封装成可复用的 Composition 函数（Vue 3）或 mixin（Vue 2），用
onUnload或onHide钩子主动clearInterval - 使用
ref存储剩余秒数，配合watch或计算属性更新按钮文案，避免手动操作 DOM - 按钮禁用状态必须同时控制：UI 禁用 +
disabled属性 + 点击事件内提前 return，三者缺一不可 - 示例关键片段：
let timer = null; const countDown = ref(60); const startCount = () => { if (timer) return; timer = setInterval(() => { countDown.value--; if (countDown.value
真机调试收不到短信？重点查这三处配置
开发时用 HBuilderX 运行到手机，接口返回成功，但就是没收到短信——90% 是环境或配置问题，不是代码 bug。
实操建议：
- 确认后端调用的是**正式环境短信模板 ID**，不是测试模板（很多平台测试模板不下发，只返回 success）
- 检查 uni-app 的
manifest.json里是否开启了「HTTPS」支持（iOS 强制要求），且后端域名已加白名单；Android 若用自签名证书，需额外配置sslVerify - 真机上打开系统设置 → 应用权限 → 找到你的 App → 确认「后台活动」「通知」未被系统限制（尤其华为、小米对后台网络限制极严）
- 最简单验证方式：用 Postman 直接请求你的
/api/send-sms接口，看短信平台控制台是否有发送记录和失败原因（比如签名未审核、余额不足、模板变量格式错误）
uni-app里处理短信回填，别依赖onShow监听
用户收到短信后切回 App，想自动读取并填充验证码——这是个伪需求。iOS 14+ 和 Android 8+ 虽支持短信自动填充（input 加 type="sms-otp"），但 uni-app 的 input 组件目前不透出该能力，onShow 也捕获不到短信内容。
实操建议：
- 放弃自动读取，改用「粘贴」引导：在输入框右侧放一个
paste图标按钮，点击后调用uni.getClipboardData()尝试读取剪贴板（需用户先手动复制） - 若坚持要自动识别，只能用原生插件（如 iOS 的
UITextField关联textContentType="oneTimeCode"），但跨端成本高、审核风险大，不推荐 - 更务实的做法：优化体验——倒计时结束前允许用户手动输入，提交时后端再校验时效性（比如只接受 5 分钟内的验证码），别把“自动”当核心功能
短信不是前端能独立闭环的事。后端鉴权、模板审核、运营商通道质量、手机系统限制……每一层都可能悄无声息地吞掉你的请求。最常被忽略的，是把「发送成功」等同于「用户收到」——而实际上，你唯一能确定的，只是后端调用了短信平台的接口。
