说真的，蘑菇视频官网的播放进度我试了三种方案，最后选了这一种
做视频播放功能，用户最常抱怨的就是“看到一半，下次又从头开始”，体验的好坏直接影响留存。为蘑菇视频官网做播放进度恢复时，我先后试了三种方案：纯前端方案、纯后端方案和混合方案。下面把过程、利弊和我为什么最终选了混合方案讲清楚，方便你直接拿去用或改造。
一、方案一：纯前端（localStorage / Cookie） 做法概述
- 在视频播放过程中监听 timeupdate 事件，把当前时间点以视频ID为键存入 localStorage 或 cookie。
- 用户打开视频页面时读取并跳转到保存的时间点。
优点
- 实现最快，开发成本最低，不需要服务器支持。
- 对匿名用户友好，不用登录就能恢复进度。
缺点
- 只能在同一台设备、同一浏览器生效，跨设备、跨浏览器无效。
- localStorage 有容量/隐私限制，用户清理缓存后数据丢失。
- 对付大规模视频和大量键值时管理混乱。
实战感受 原型阶段用过，效果直观、回归率短期提升明显，但用户反馈“换手机就不行”后续投诉增多，说明单纯靠前端并不能覆盖主力需求。
二、方案二：纯后端（登录 + 服务端存库） 做法概述
- 要求用户登录，客户端周期性把当前播放时间通过 API 上传到服务器数据库（例如每隔10秒或在退出时）。
- 播放器加载时请求服务器的最新进度并恢复。
优点
- 跨设备、跨浏览器都能同步；数据可分析、可做统计。
- 相对稳定，适合用户粘性高、账号体系完善的产品。
缺点
- 开发和运维成本高（API、安全、并发、存储增长）。
- 需要处理匿名用户和频繁写入带来的性能问题。
- 用户隐私和数据合规需要考虑。
实战感受 在核心用户群体里体验最好，但基层用户和未登录访客占比大的场景，推行登录门槛会丢失流量，且服务器写入压力不可小觑。
三、方案三：混合（本地 + 后端同步）——我最终选择的方案 做法概述
- 匿名时：使用 localStorage 记录当前进度，保证免登录也能恢复。
- 登录后：播放器仍在本地保存进度，并在合适时机（如停播、切换视频、或定时）把进度同步到服务器。服务器保存的优先级高于本地。
- 登录期间跨设备访问时，先从服务器拉取进度并恢复；本地与服务器冲突按更新时间/播放时长合并策略处理。
为什么选这个
- 平衡成本与体验：保留匿名用户的无门槛体验，同时为注册/登录用户提供跨设备同步。
- 渐进式实施：可以先上线本地存储，后端同步模块逐步接入，降低一次性开发风险。
- 易于运营：服务器端数据用于统计用户观看行为，便于内容优化和个性化推荐。
关键实现要点（可直接落地） 1) 播放器事件监听
- 监听 timeupdate（节流到 1-5s）、pause、ended、beforeunload 等事件。
- 在 timeupdate 中只做短时缓存；在 pause/ended/beforeunload 时写入 localStorage 并触发后台同步（如果已登录）。
2) 后端同步策略
- 写入频率控制：定时同步（如每30s）+关键事件同步（暂停/退出/切换视频）可以降低接口调用。
- 冲突处理：用时间戳或观看时长决定优先级。若本地时间点比服务器晚则覆盖，反之则读取服务器进度。
3) 数据结构建议
- localStorage: { "progress:videoId": { time: 123.45, updatedAt: 1670000000 } }
- 后端表: userid, videoid, currenttime, updatedat（做好索引）
4) 隐私与性能
- 对匿名用户本地数据保留周期（例如30天），避免无限累积。
- 后端只存必要字段，非必要不要把播放习惯细分到每一帧，按分钟粒度即可减少写入量。
- 对于大流量站点，采用批量上报或队列（如 Kafka）平滑写入压力。
5) 在 Google 网站（Google Sites）部署的实用建议
- Google Sites 直接注入自定义 JavaScript 有限制。建议把播放器及逻辑放在一个独立的静态页面（比如子域名或 GitHub Pages），用 iframe 嵌入到 Google Sites 中。
- 另一种方法是使用第三方播放器服务（支持进度恢复的播放器），然后通过其 SDK 做 local + server 同步。
- iframe 的跨域通信可以用 postMessage 做本地与主站的交互。
体验细节（小细节决定用户感受）
- 恢复位置显示提示：当自动跳转到上次进度时，给用户一个小提示（“继续从 12:34 处播放？”），并提供“从头开始”选项，尊重用户选择。
- 缓存破损回退：若 localStorage 值异常或超时，优先回退到 0，不要把错误时间点当做合法进度。
- 支持章节跳转：对于长视频或长课，保存章节索引比精确秒数更友好。
结语 三个方案我都做过，纯前端可以快速验证需求，纯后端最为严谨，而我选的混合方案兼顾了体验、成本和可扩展性——既不丢掉匿名流量，也能为注册用户提供跨设备体验。落地时把同步节奏、冲突策略和用户可控性设计好，用户留存和满意度会显著提升。
如果你想要我把上面关键代码段（前端监听与同步示例）写成可复制的片段，或把这个方案改成适配你现有技术栈的实现方案，我可以直接写出来供你拿去部署。哪种语言/框架你们在用？
