必须用 canvas 实现App端手势解锁，因v-for+DOM方案在iOS/Android WebView中存在触摸丢点、坐标漂移、offsetX/Y为0、clientX偏差大、无法识别滑动轨迹等问题，实测识别率低于30%。
App端手势解锁必须用 canvas 实现，v-for 渲染九宫格点 + 点击模拟会直接失效——iOS/Android 上触摸丢点率高、坐标漂移严重、无法识别滑动轨迹，用户划对了也判错。
为什么不能用 view + v-for 模拟九宫格
纯 DOM 方式依赖点击事件触发，但 App 端（尤其 iOS WKWebView）对连续触摸的采样不连贯，@touchstart 和 @touchend 之间可能只捕获到 1–2 个 @touchmove，根本不足以还原路径；更致命的是，offsetX/offsetY 在多数 App 内置 WebView 中返回 0，导致所有点位计算全偏。实测在 iPhone 15 Pro 上，v-for 方案识别成功率低于 30%。
无序列表呈现关键缺陷：
-
event.touches[0].clientX在 iOS 下受状态栏/导航栏影响，未校准前偏差可达 40px+ - 没有滑动方向、速度、加速度等中间态，无法过滤误触或抖动
- 无法判断“经过但未停留”和“明确选中”的区别，导致序列错乱（如划过点 1 却记为已选）
- 不同屏幕宽高比下硬编码格子尺寸，点位完全错位
canvas 坐标初始化必须动态适配屏幕
不能写死 canvasWidth = 300 或 cellSize = 100。真机上点位偏移的根源，90% 出在没做设备基准校准。
正确做法是：
- 在
onMounted中调用uni.getSystemInfoSync()，取screenWidth和screenHeight -
canvasWidth = canvasHeight = Math.min(screenWidth, screenHeight) * 0.8（留出状态栏+底部安全区） -
cellSize = canvasWidth / 3，每个格子中心点按(col + 0.5) * cellSize计算，避免整数截断 - 用
canvas.getBoundingClientRect()+touches[0].clientX转换为 canvas 坐标系，不用pageX（H5 可用，App 端不准）
@touchmove 必须节流 + 差值累积
App 端 @touchmove 触发频率极高，快速滑动时每秒超 120 次。直接在里面更新路径或重绘 canvas，会导致 CPU 暴涨、轨迹卡顿、点位跳变。
实操要点：
- 用
requestAnimationFrame包裹移动逻辑，确保每帧最多更新一次 - 不直接用
clientX，而是记录上一帧位置，算dx = currentX - lastX，再累加到总位移 - 仅当
isTracking === true（@touchstart后置为 true）才响应@touchmove，避免滚动穿透干扰 - 在
@touchend或@touchcancel中统一判断是否构成有效手势（如路径点 ≥ 4、相邻点欧氏距离 > 30px）
密码序列校验不能只比对索引数组
存 [0,1,2,5,8] 这种索引数组看似简单，但实际漏判严重：用户从点 0 划向点 2，中途擦过点 1，系统可能错误计入；或两点太近被过滤，导致序列变成 [0,2,5,8]，与注册时不符。
可靠方案是：
- 保存完整点序列：
points: [{x, y, time}]，剔除密集冗余点（距离 - 对每段移动，用「最近格点 + 时间邻近性」双重匹配：先找欧氏距离最小的格点，再确认该点未在 300ms 内被重复命中
- 最终生成的密码对象含
index、x、y，验证时用JSON.stringify(pwd1) === JSON.stringify(pwd2)深比较 - 存储用
uni.setStorageSync，别存明文数组——至少转成 base64 或加盐哈希
最易被忽略的是 iOS 下 toDataURL 可能被禁用，以及 Android 9+ 对 USE_FINGERPRINT 权限的兼容性陷阱——手势解锁本身不涉及生物认证，但若你后续要集成指纹 fallback，这两处权限和配置漏掉一个，整个安全链路就断了。
