无法“防止”用户快进，但可通过移除原生 controls、监听 seeking 事件并重置 currentTime 来阻断刷时长；需禁用右键/键盘、防抖处理、结合 buffered 与 play 状态识别异常行为，并注意 iOS Safari 的兼容性修复。
直接说结论：无法“防止”用户快进，但可以通过禁用原生 controls、监听 seeking 事件 + 拦截跳转 + 重置时间点来阻断刷时长行为；关键不是封死 API，而是让快进操作失效并恢复到合法区间。
为什么 controls="true" 下无法阻止快进
浏览器原生控件（包括进度条、右键跳转、快捷键）完全绕过 JS 监听。一旦加了 controls 属性，用户拖动、双击、按 ←→ 方向键都会触发 seek，你连事件都收不到。
常见错误是只监听 timeupdate 或 click，结果发现拖动进度条时根本没触发——因为原生控件不派发这些事件给自定义逻辑。
- 必须移除
controls属性，自己画 UI、绑事件 - 禁用右键菜单：
oncontextmenu="return false" - 禁用键盘快进：
onkeydown="return false"（或选择性拦截方向键/空格）
监听 seeking 事件并强制重置 currentTime
seeking 是唯一能捕获“用户试图跳转”的时机。它在跳转开始时触发（还没真正跳），此时修改 currentTime 仍有效；而 seeked 触发时已跳完，再改就晚了。
立即学习“前端免费学习笔记（深入）”；
注意：该事件仅在用户主动 seek 时触发（如拖动、currentTime = x），播放自然进行不会触发。
- 绑定一次即可：
audio.addEventListener('seeking', handleSeek, { once: false }) - 在 handler 中立即设回允许范围，例如只允许在 [10, audio.duration - 10] 内播放：
audio.currentTime = Math.max(10, Math.min(audio.duration - 10, audio.currentTime)) - 加个防抖：连续快速 seek 可能触发多次，用
setTimeout延迟重置，避免视觉跳动
判断是否“刷时长”需要结合 buffered 和 play() 状态
单纯拦 seeking 不够。用户可能拖到开头反复播前 5 秒，或者暂停后狂拖——这些不算“刷”，但影响统计。真要防刷，得看行为模式：
- 检查
audio.buffered.length === 0：说明用户拖到了未缓冲区，大概率是乱跳 - 对比
audio.currentTime和上一次记录值：1 秒内跳变 >30 秒，且非首次播放，可视为异常 - 调用
audio.play()后立刻pause()：这是典型刷时长脚本特征，需在play事件里埋点检测 - 服务端验证更可靠：前端所有限制都可绕过，最终应以服务端下发的 validRange + 客户端上报的 playDuration 综合判定
最易被忽略的一点：iOS Safari 在 seeking 中设 currentTime 有时会失效，必须紧跟一个 audio.load()（慎用，会中断当前播放）或延迟一帧用 requestAnimationFrame 再设一次。
