把视频位置设到第 6 秒，最后却又读到 0 秒。这看起来像是进度条又写了一遍。也可能怀疑自己把事件监听绑重了。但这次实验给了我一个更靠前的检查项：操作那一刻，播放器究竟允许跳到哪里。没有记录就难判断。直接改监听顺序可能只是在猜。
我在试用图映 ImgIng的视频压缩功能时实际导出了两段海浪素材，也另做了普通 MP4 的播放实验。下面这组"跳回去"发生在普通 MP4 对照中，不是工作台的操作结果。我把它记进笔记，是因为视频总时长、当前播放位置和可跳转范围这三个概念很容易被当成一回事。
总时长告诉我这段内容有多长。currentTime 是当前播放位置。seekable 表示此刻可寻址的时间范围。MDN 对 seekable 的定义特意限定在读取属性的那个时刻。它不是给整个文件贴上的永久标签。旧值不适合一直沿用。加载过程中的变化也要记录。
我测的 A 样本长 8 秒。索引放在文件头部。首帧显示后等 500 毫秒，暂停并将 currentTime 设到 6 秒。这里刻意选了较早的时机。播放器已经有画面，但后面的内容还未必能够直接寻址。每秒传输预算为 256 KiB，每条请求开始前另外等待 80 毫秒，方便观察尚在读取的状态。
在服务器忽略 Range 的组合里，Chromium 149 当时的 seekable 为 0,0。我要求去 6 秒。记录中的位置却钳回 0 秒。两次都是这样。6 秒没有超过总时长，却在当时读到的可寻址范围之外。只检查"目标小于总时长"，不足以解释这次跳转为什么没有到达。
Firefox 151 也没有到达目标。在同一 A 样本头部索引、忽略 Range 的两次测试中，实际落点分别为 1.16 秒和 0.36 秒。我没有把它们写成拖动成功，也没有由此反推自己传入了错误目标。设置的 6 秒和随后读回的实际位置需要一起留下，才能看见两者发生了偏离。
下图是支持 Range 的成功对照。同一 A 头部索引样本在 Chromium 中已经显示第 6 秒画面。图里的首次显示和跳转计时各有一栏，因此它不是"只看见开头"的截图。画面来自本地受控复现页。它可以展示成功状态，不能代替前面忽略 Range 组合的 seekable 和落点记录。
我现在会先分开看三件事：自己设置了什么目标、seeked 之后读到了什么位置、是否拿到了目标画面的帧回调。本轮最后一项要求 mediaTime 落在 6±0.15 秒。容差是本次测试的判定条件，不是精确截图的承诺。事件来了还不够。实际位置也可能被限制到了别处。
可寻址范围也不能直接当作已下载量。一个位置是否可寻址与服务端能否按范围提供数据有关，不一定要先把那个位置之前的所有内容读完。反过来，这次无 Range 的早期钳位，也不说明文件以后永远无法拖动。我没有把这一轮的失败扩成完整读取后的结论。晚一点操作需要另做对照。
不同内核给出不同范围的内部原因，我还没有全部弄清。这里保留的是观察结果。实验于 2026 年 9 月 30 日在 macOS 26.5.2 上完成，每种组合重复两次，没有测试更多设备。配图是 Alexander Grebenkov 的 Wikimedia Commons 冰岛海浪，按 CC BY 3.0 使用并截取、缩放、转码，素材并非我拍摄。
下次遇到进度条跳回去，我会先记下设置前的 seekable。设置目标和事件后的 currentTime 也要保留。等更多数据到达后再重新操作一次，同时读取新的范围。第一次的快照不适合继续沿用。如果目标落在当前范围内却仍然回跳，再检查页面是否有重复写入或监听覆盖。这样能先排除可寻址范围这一层，不用一看到回跳就改事件监听，更不会把早期失败误记成视频永久损坏。