uni-app导航栏无法响应式更新倒计时，须用uni.setnavigationbartitle主动设置，每300–500ms校准并仅秒数变化时调用，onhide清除定时器，onshow立即重算刷新。
导航栏里不能直接用 setInterval 更新倒计时
uni-app 的导航栏（navigationBar）是原生渲染的，不支持动态绑定响应式数据。你写 {{countdown}} 或在 title 里插值，它根本不会更新——哪怕你在 data 里改了值，导航栏也不会重绘。
- 真机上常见现象：导航栏初始显示 “60s”，之后一直卡住不动，哪怕页面内倒计时 UI 正常跑
- 小程序端更明显，
uni.setNavigationBarTitle调用频繁会触发节流，且 iOS 真机有明显延迟 - H5 和 App 端虽然可用 CSS 自定义导航栏（即禁用原生、用 view 模拟），但跨端一致性差，维护成本高
正确做法：用 uni.setNavigationBarTitle 主动刷新
必须放弃“绑定更新”幻想，改用主动设置。每次倒计时变化时，显式调用 API 修改标题文字。关键不是“怎么设”，而是“什么时候设、设多少、怎么防抖”。
- 倒计时逻辑仍用服务端时间戳锚定：
endTime是毫秒级时间戳（如1743165680000），每次计算都走Math.max(0, Math.floor((endTime - Date.now()) / 1000)) - 不要每 1000ms 都调一次
uni.setNavigationBarTitle——原生 API 有频率限制，频繁调用会被忽略或报错 - 推荐每 300–500ms 校准一次剩余秒数，仅当秒数实际变化时才调用设置（比如从
59→58才触发） - 在
onHide中必须清除定时器，在onShow中立刻重算并调用一次uni.setNavigationBarTitle，否则切后台回来标题就过期
按钮点击后启动倒计时并同步导航栏的典型流程
以发送验证码为例，导航栏显示 “重新获取（60s）”，用户点击后开始倒计时并实时更新标题。
- 点击事件开头加守卫：
if (this.isCounting) return，防止重复触发 - 成功拿到响应后，立即设
this.isCounting = true，并初始化this.countdown = 60 - 启动
setTimeout递归（不用setInterval），每次回调先重算remain = Math.max(0, (endTime - Date.now()) / 1000) - 若
remain > 0且Math.floor(remain) !== this.countdown，才调用uni.setNavigationBarTitle({ title: `重新获取（${Math.floor(remain)}s）` })并更新this.countdown remain 时，调用 <code>uni.setNavigationBarTitle({ title: '重新获取' })，并执行this.resetCountdown()（清定时器 +isCounting = false）
容易被忽略的跨端坑点
导航栏倒计时最脆弱的环节不在逻辑，而在生命周期与平台行为差异。
- App 端（尤其 iOS）切后台后，JS 线程可能被系统挂起，
Date.now()在恢复瞬间会跳变，导致倒计时直接从 20s 跳到 0s——所以onShow里必须无条件重算，不能依赖上次定时器状态 - 微信小程序中，
uni.setNavigationBarTitle在页面未完全加载完成时调用会静默失败，建议包一层uni.$nextTick或延后 1 帧（setTimeout(() => {}, 0)） - 如果用了自定义导航栏（
custom: true），那倒计时就变成普通 view 渲染，可直接绑定，但此时必须手动处理返回按钮、状态栏高度等兼容问题，得不偿失 - 别在
onUnload里清理导航栏相关定时器——App 切后台不触发onUnload，只走onHide，漏掉就内存泄漏
