一、业务记忆播放位置的开发场景
很多点播业务需要记忆用户上次观看的位置，用户再次打开视频，直接跳转到上次退出的时间点继续播放。hls.js 提供loadStartPosition配置项，用来设置加载完成之后的起始时间，不用等视频全部加载完成再调用 video.currentTime 去跳转。
很多新手看到这个参数，直接拿来用，期望打开就精准跳到指定秒数。实际开发会遇到各种问题：跳转位置不准、偶尔失效、部分环境直接从 0 秒从头播放。
很多人以为设置这个参数就万事大吉，忽略它的生效前提：必须已经下载对应位置附近的分片；GOP 关键帧位置会影响实际 seek 跳转的落点。loadStartPosition只是给播放器一个建议起始时间，不代表一定精准落到你填写的秒数。
很多开发遇到跳转不准，反复修改参数数值，却不去看 M3U8 分片的 GOP、EXTINF 分片时长。
调试点播记忆播放位置相关问题，我会使用 m3u8live.cn 网页调试工具，确认这份点播 M3U8 分片 GOP 情况，再到业务页面调试起始位置逻辑。
二、loadStartPosition 高频踩坑
坑 1：误以为参数可以精准定位任意秒数
现象：设置 loadStartPosition=120，实际视频从 118 秒或者 123 秒开始播放。 根因：HLS 分片只能跳到分片的 I 关键帧位置，播放器不会在分片中间做切割，只能落到分片起始点，时间会存在少量偏移，属于正常现象。
坑 2：视频还没解析完成，直接设置 video.currentTime
部分同学不使用 loadStartPosition，页面刚赋值 m3u8 立刻设置 video.currentTime=120。此时 M3U8 清单还没解析完毕，时间轴还没有初始化，seek 直接不生效，从 0 开始播放。
坑 3：短视频、小时长视频该参数偶尔失效
视频总时长小于填写的 startPosition，参数被直接忽略，从头播放。业务要做判断：记忆的时间不能大于视频总时长。
坑 4：多次切换视频源，旧的 loadStartPosition 配置没有重置
复用 hls 实例切换下一个点播视频，上一次的起始位置配置还保留，新视频错误跳到上一个视频的时间点，播放错乱。
坑 5：忽略 Safari 原生 HLS 环境
iOS Safari 不运行 hls.js，loadStartPosition 配置完全无效，需要在 video 标签加载完成之后再手动执行 currentTime 跳转。
三、记忆播放位置两种实现思路对比
- 使用 hls.js 的 loadStartPosition 配置：在 new Hls 的时候传入，清单解析之后优先加载对应时间附近分片。适合 hls.js 环境，存在分片关键帧带来的时间偏移。
- 监听 MANIFEST_PARSED 事件，清单解析完成之后调用 video.currentTime 跳转。兼容性更好，所有浏览器环境都可以使用，但是会先加载一小段开头分片再 seek。
注意：Safari 原生 HLS，hls.js 配置全部不生效，只能等待 loadedmetadata 事件再做 seek 跳转。
四、简单开发参考逻辑
- 拿到用户记忆播放的秒数，先和视频总时长做对比，如果记忆时间大于总时长，重置为 0，从头播放。
- Chrome/Edge/Firefox 使用 hls.js：可以传入 loadStartPosition，接受少量时间偏移；
- iOS‑Safari 原生 HLS：监听 loadedmetadata 事件，再执行 video.currentTime；
- 切换新视频源的时候，重置起始位置配置，不要复用上一次的记忆时间。
五、排查步骤
第一步，待测点播 M3U8 放到网页调试工具，观察分片 EXTINF 时长，确认分片 I 帧间隔。理解 seek 只能落到分片开头，时间会有少量偏移，不要追求毫秒级精准跳转。 第二步，业务页面打印事件日志，确认 MANIFEST_PARSED 或者 loadedmetadata 事件触发之后才执行跳转，不要页面一加载就设置 currentTime。
六、总结
hls.js 的 loadStartPosition 适合实现点播记忆续播，但它只是建议起始位置，受分片 GOP 关键帧限制，时间会有少量偏移，无法做到任意毫秒精准跳转。同时 Safari 原生 HLS 完全不识别该配置，需要分开做兼容。切换视频源记得重置配置，记忆时间要和视频总时长做边界判断。借助网页调试工具确认分片特性，不要盲目调参，理解 HLS 分片 seek 底层限制。