不能在 uni-app 中直接用 uni.getWeRunData 获取明文步数，必须通过用户点击 button 触发微信原生回调，再由后端解密 encryptedData；该 API 仅限微信小程序，且调用必须处于用户点击的同步上下文。

直接说结论：不能在 uni-app 里用 uni.getwerundata 直接拿到明文步数，必须走「用户点击 button → 微信原生回调 → 后端解密」闭环，否则必报 errcode: -1 或静默失败。

---

为什么 uni.getWeRunData 在 onLoad / mounted 里调用一定失败

微信平台强制要求：调用 wx.getWeRunData（uni.getWeRunData 底层就是它）必须发生在用户真实点击的同步上下文中，不能是生命周期钩子、setTimeout、Promise.then、甚至 uni.$nextTick。

• 常见错误现象：

  • 点击无反应，控制台没日志
  • 报错 getWeRunData:fail invalid operate
  • H5 或 App 端直接提示 not supported（因为该 API 仅限微信小程序）

• 正确姿势只有一种：

  • 模板中写：<button open-type="getWeRunData" @getwe-rundata="onGetWeRunData">获取步数</button>
  • 方法里只做透传，不加任何异步包装
  • onGetWeRunData 必须是 click 事件的直接响应函数（不能被 debounce/throttle 包裹）

---

button open-type="getWeRunData" 的硬性限制和配置项

这个 button 不是普通按钮，是微信小程序的“特权组件”，有明确平台和行为约束：

• 仅在 #ifdef MP-WEIXIN 下生效，H5/App 编译时自动剔除（不报错但不渲染）
• 必须配置 scope.werun 权限：
  • manifest.json → 微信小程序 → 权限列表 → ✅ 勾选「微信运动」
  • 小程序后台「用户隐私保护指引」中必须声明“收集微信运动步数”，否则审核拒过
• 用户首次点击会弹授权弹窗；拒绝后，再次点击需主动跳设置页，但注意：
  • uni.openSetting 只能在用户点击的同步回调里调用（不能放在 uni.getSetting 的 success 回调里）
  • 错误写法：uni.getSetting().then(() => uni.openSetting())
  • 正确写法：检测到未授权后，立即在点击 handler 内调用 uni.openSetting

---

encryptedData 解密失败的三个实际原因

前端拿到 e.detail.encryptedData 和 e.detail.iv 后，必须交由后端解密——微信不提供前端解密能力，也禁止 session_key 泄露。

• 高频失败点：
  • session_key 过期或复用：每个 code 只能换一次 session_key，有效期约 2 小时；登录态要绑定用户并及时刷新
  • appid 不匹配：解密时用的 appid 必须和调用方小程序完全一致（测试号/正式号不能混用）
  • 服务器时间偏差 > 5 分钟：微信校验时间戳，Linux 服务器需定期执行 ntpdate ntp1.aliyun.com
• 解密后数据结构：
  • 是 JSON 字符串，JSON.parse 后得对象
  • stepInfoList 是数组，按时间倒序：索引 0 是今天，30 是 30 天前
  • 当日步数取 stepInfoList[0].step（注意是 number，不是 string）

---

排行榜怎么做？别幻想前端聚合

uni.getWeRunData 只能读自己账号的 31 天数据，无法跨用户读取。所谓“排行榜”，本质是后端行为：

微信朋友圈爆款文案生成器

根据产品、场景和风格自动生成适合微信朋友圈的爆款文案，包含配图建议和互动引导。

下载

• 用户每次成功解密后，前端上报：{ openid, step: stepInfoList[0].step, timestamp }

• 后端存入数据库，按日期/周/月聚合统计

• 前端请求排行榜接口（如 /api/rank?date=2026-05-28），返回已计算好的 topN 列表

• 容易忽略的细节：

  • openid 必须和 session_key 来自同一 code，否则解密失败
  • 上报步数时，要校验时间戳是否在当日（避免篡改）
  • 若用户某天没走动，stepInfoList[0] 可能不存在，需 fallback 为 0

微信的限制不是 bug，是设计——所有环节都卡在“用户可控”和“服务端可信”两个锚点上。跳过 button、绕过后端解密、或想在 H5/App 里复用这套逻辑，都会卡死。