uni.getWeRunData 仅限微信小程序使用，其他平台会报错；必须用 #ifdef MP-WEIXIN 包裹，App/H5 需用原生插件或传感器替代，且解密必须由服务端完成。
uni.getWeRunData 只能在微信小程序里用，其他平台直接报错
调用 uni.getWeRunData 前必须做平台判断，否则在 H5 或 App 环境下会抛出 "not supported" 错误，甚至导致整个逻辑中断。这不是兼容性问题，是微信原生能力的硬性限制。
常见错误现象：
- 没加条件编译，
uni.getWeRunData在 H5 页面里执行 → 控制台报uni.getWeRunData is not a function - App 端误以为能用 → 调用后
fail回调返回"not supported"，且无日志提示原因
正确做法只保留一条路径：
- 用
#ifdef MP-WEIXIN包裹全部相关逻辑（包括授权检查、调用、解密准备） - App 和 H5 环境下必须走替代方案（如原生插件或传感器估算），不能 fallback 到
uni.getWeRunData - 不要在
onLoad里无条件调用，先uni.getSetting检查scope.werun是否已授权
用户拒绝 scope.werun 授权后，openSetting 不一定生效
微信对 wx.openSetting 的调用有严格限制：必须由用户主动触发（比如按钮点击），且不能在异步回调里二次唤起。很多开发者在 getSetting 检查失败后直接 openSetting，结果静默失败。
关键细节：
-
uni.authorize({scope: 'scope.werun'})失败后，不能立刻再调openSetting；要等用户再次点击按钮才可触发 -
openSetting成功回调里，res.authSetting['scope.werun']仍是undefined或false—— 这是正常现象，需重新getSetting确认 - 真机测试时，iOS 微信可能跳转到「隐私设置」页而非直接弹出权限开关，用户容易忽略
建议交互流程：按钮文案明确写“开启微信运动权限”，拒绝后弹窗说明用途（如“用于生成健康周报”），不提供“取消”选项，只留“去开启”并绑定点击事件调用 openSetting。
encryptedData 解密失败，90% 是 session_key 过期或错配
前端拿到 encryptedData 和 iv 后，必须交由服务端用对应用户的 session_key 解密。前端自己解密是无效且不安全的 —— WXBizDataCrypt 类只是工具，核心依赖后端获取的 session_key 是否有效。
高频踩坑点：
- 前端用
wx.login拿到的code没及时传给后端，后端调sns/jscode2session时code已过期（5分钟有效期） - 后端缓存了旧的
session_key，但微信会定期刷新它，必须每次用新code换新session_key - 解密时用了 AppID 写错（比如用了公众号 AppID 而非小程序 AppID）
- 解密后
stepInfoList是空数组 → 用户未开启微信运动，或过去 31 天无数据，不是解密失败
验证方式：后端解密后应返回完整 JSON，含 stepInfoList 字段，每个对象含 step、timestamp（时间戳，注意是东八区秒级时间）。
App 和 H5 无法复用微信步数，得换技术栈
别试图把 uni.getWeRunData 的逻辑复制到 App 或 H5。微信运动数据是微信生态内封闭数据，离开小程序容器就不可见。
各平台真实可行路径：
- App（Android）：用
plus.android调用原生插件读取 Google Fit 或系统 Health Services，需在manifest.json配置android.permission.ACTIVITY_RECOGNITION - App（iOS）：集成 HealthKit 插件，Xcode 里打开 HealthKit 开关，并在
info.plist添加NSHealthShareUsageDescription描述 - H5：仅限微信内置浏览器，用
wx.onAccelerometerChange做粗略计步（误差 ±30%），其他浏览器基本不可行
最易被忽略的一点：App 端即使拿到原始传感器数据，也要自己实现步态识别算法（比如峰值检测+滤波），没有开箱即用的“步数”字段 —— 这和微信运动封装好的每日总步数，完全是两个量级的数据产出成本。
