不能用<input type="range">直接当滑动解锁控件——它不校验拖拽行为、可被点击跳转、键盘操控形同虚设，安全水位为零；真实可用的滑动解锁必须用JavaScript手动监听touchstart/mousedown双事件、追踪位移、判定方向与距离，并配合服务端轻量验证。
不能用 <input type="range"> 直接当滑动解锁控件——它不校验拖拽行为、可被点击跳转、键盘操控形同虚设，安全水位为零。真实可用的滑动解锁必须用 JavaScript 手动监听拖拽起点、追踪位移、判定方向与距离，并配合服务端轻量验证。
必须监听 touchstart + mousedown 双路径
用户可能用手指、触控笔或鼠标操作，只绑一种事件必然漏判。关键不是“选哪个”，而是统一处理逻辑：
- 在容器上同时绑定
touchstart和mousedown，第一行就调用e.preventDefault()（尤其 iOS 必须在touchstart阶段阻止，否则滚动会抢走事件） - 起始坐标统一取
e.touches?.[0].clientX || e.clientX，避免touches为空时报错 - 记录
startX和startTime = Date.now()，后者用于后续防抖 - 给容器加 CSS：
touch-action: none，禁用浏览器默认手势（缩放、滚动），否则touchmove会被截断
拖拽过程必须委托到 document 上
如果只在按钮/滑块区域监听 mousemove 或 touchmove，用户手指一滑出边界，事件立刻中断，滑块卡在半路，验证失败。
- 在
touchstart/mousedown触发后，立即在document上绑定touchmove和mousemove - 移动时只更新滑块位置：
element.style.transform = `translateX(${deltaX}px)`（别改left，避免重排） - 持续判断横向位移是否主导：要求
Math.abs(deltaX) > Math.abs(deltaY) * 1.5，过滤上下误滑 - 务必在
touchmove中也调用e.preventDefault()，防止页面滚动或文本选中
touchend/mouseup 判定要带容差、时间阈值和状态清理
仅判断 “最终位置 ≥ 轨道宽度 − 滑块宽度” 是典型误判——手指抬离有抖动、设备触摸精度误差、快速拖拽惯性都会导致失败。
立即学习“前端免费学习笔记（深入）”；
- 计算真实位移：
const deltaX = currentX - startX，不是读 DOM 的offsetLeft（可能滞后） - 要求
deltaX >= trackWidth - thumbWidth - 12（留 12px 容差，适配不同设备） - 检查最小拖拽时间：
Date.now() - startTime > 100，过滤点击误触 - 成功后立即调用
removeEventListener清理document上的mousemove/mouseup，否则多次触发导致重复解锁 - 失败反馈用
transform: scale(0.95)+ 文字提示，比弹窗更轻量，不打断流程
解锁成功 ≠ 业务完成，必须走服务端轻量校验
前端视觉上滑块到位，不代表用户真的完成了可信操作。攻击者可绕过 UI 直接调用 unlock()，或用 DevTools 修改 DOM 强行触发。
- 解锁判定逻辑必须封装在独立函数（如
validateSwipe()），内部检查：是否已开始拖拽、位移是否达标、是否单次连续拖拽（非多次短拖拼凑） - 成功回调里不要直接开放敏感操作，而应发起一次 POST 请求（如
/verify-unlock），传duration、distance和简单时间戳签名 - 服务端验证这些参数是否在合理区间（例如：duration ∈ [100, 3000]ms，distance ≥ 200px），不信任任何前端 localStorage 标记
- 前端本地存储（如
localStorage.setItem('unlocked', 'true')）必须设 5 分钟过期，且服务端绝不读取该字段
Canvas 动态绘制轨迹不是锦上添花，是防录屏的关键——静态 HTML/CSS 元素再怎么隐藏，录屏都能捕获；而实时生成的 canvas 背景+拖拽路径，无法被静态分析还原。这点常被忽略，但恰恰是安全水位的分水岭。
