App端可用，H5和小程序端基本不可用；必须用uni.onAccelerometerChange配合uni.startAccelerometer启动传感器，iOS需在manifest.json勾选“运动与健身”权限，Android建议用户触发后启动；判断摇一摇需计算加速度模长变化率（jerk），双阈值（模长>18且差值平方和连续2帧>20）防误触；须加isShaking标志与1500ms锁定期防抖，并在onHide/onUnload中调用uni.offAccelerometerChange注销监听。
App 端能用，H5 和小程序端基本不可用——这不是代码问题，是平台能力限制。摇一摇抽奖必须走原生加速度计路径，uni-app 里只靠 uni.onAccelerometerChange + 合理滤波才能稳定触发，其他 API（如 uni.onDeviceMotionChange 或 uni.onGyroscopeChange）在真实摇动场景下漏判率高、响应滞后。
为什么 uni.onAccelerometerChange 必须配 uni.startAccelerometer
很多人注册了监听却收不到回调，根本原因是传感器没真正启动。uni.onAccelerometerChange 只是“告诉系统：等有数据就调我”，但系统默认不发数据。必须显式调用 uni.startAccelerometer() 才会激活硬件采集。
- iOS 需提前在
manifest.json→ App SDK 配置 → iOS 模块权限中勾选「运动与健身」，否则静默失败，无任何报错 - Android 不需要额外权限，但部分厂商（华为/小米）省电模式下会拦截，建议在用户点击按钮后才启动，避免冷启被拒
-
uni.getAccelerometerFrequency是异步设置采样频率的，设完不等于生效，要等success回调确认；实际推荐interval: 'ui'，'game'在 iOS 上常被降频
怎么判断“真摇”而不是走路/放手机
单看 res.x、res.y、res.z 的瞬时值极易误触——呼吸、按屏幕、甚至地铁晃动都可能让某轴超阈值。关键得算 jerk（加速度变化率），也就是“动得有多快+方向突变多剧烈”。
- 每帧先算合加速度：
const acc = Math.sqrt(res.x**2 + res.y**2 + res.z**2) - 缓存最近 4 帧（
accHistory.push(acc); accHistory = accHistory.slice(-4)） - 对连续 3 帧计算差值平方和：
dx*dx + dy*dy + dz*dz（避免开方，省性能） - 仅当该值连续 ≥2 帧 > 20，且当前
acc > 18（≈1.8g），才记为一次有效抖动
防抖、锁定期与内存泄漏怎么处理
一次真实摇动常触发 5–8 个峰值，不控就会弹出三四次抽奖弹窗。同时，页面跳走后监听器若没注销，会持续执行并报 Cannot read property 'xxx' of null。
- 用布尔标志 + 定时器锁死：检测到有效抖动后立即设
isShaking = true，1500ms 后重置；期间所有新触发直接 return - 必须在
onHide或onUnload中配对调用：uni.offAccelerometerChange(handle)，且传入的函数引用要和注册时完全一致 - 别用
clearTimeout动态取消旧定时器——摇动持续时间不可控，固定窗口比动态管理更稳
最易被忽略的是：App 后台时传感器自动停止，iOS 退到后台瞬间就断，Android 通常撑不过 30 秒。所谓“锁屏摇一摇”在纯 uni-app 里无法实现，强行保活会触发系统杀进程，真要支持得换 NFC 或蓝牙外设方案。
