PHP无法直接实现断点续播，需前后端协同：前端JavaScript监听播放状态并上报进度，PHP接口负责存取user_id、book_id和current_time至Redis或MySQL。
PHP 本身不直接控制音频播放，断点续播需前后端协同
PHP 是服务端语言，无法直接读取浏览器中 的当前播放时间或监听暂停/中断事件。所谓“PHP 调用听书插件实现断点续播”，本质是 PHP 提供接口存取播放进度，由前端 JavaScript 主动上报和恢复。如果跳过前端、只写 PHP 逻辑，断点续播一定失败。
关键数据存储：用 PHP 接口保存和读取用户播放位置
用户每次暂停或离开页面前，前端应通过 AJAX 向 PHP 接口提交当前 currentTime（单位：秒），PHP 将其与 user_id 和 book_id 一起存入数据库（如 MySQL）或缓存（如 Redis）。下次加载同一本书时，前端再调用 PHP 接口拉取该记录。
- 推荐使用
Redis存储，键名建议为play_progress:{user_id}:{book_id}，过期时间设为 7 天 - MySQL 表结构至少包含：
user_id（INT）、book_id（INT）、current_time（FLOAT）、updated_at（DATETIME） - PHP 接口示例（接收 POST）：
if ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_POST['book_id'], $_POST['time'])) { $book_id = (int)$_POST['book_id']; $time = (float)$_POST['time']; $user_id = get_current_user_id(); // 你自己的登录态识别逻辑 // 写入 Redis 或 DB $redis->setex("play_progress:{$user_id}:{$book_id}", 60 * 60 * 24 * 7, $time); echo json_encode(['ok' => true]); }
前端 JS 必须主动管理播放状态与时间同步
仅靠 PHP 存数据远远不够。前端要处理：beforeunload 捕获页面关闭、visibilitychange 监听标签页切换、pause/ended 事件触发保存，并在 loadedmetadata 后设置 currentTime。
- 不要依赖
timeupdate频繁上报——太耗资源，应在暂停/切页/播放结束时才调用保存接口 - 恢复播放前务必检查音频是否已加载元数据（
audio.readyState >= 1），否则设置currentTime会无效 - 若音频是流式（如 HLS），
currentTime可能不精确，需配合服务端做分段对齐（如按章节/时间戳锚点）
常见失效原因：跨设备、无登录态、缓存未清理
很多“续播失效”问题其实和 PHP 逻辑无关，而是业务链路断了：
立即学习“PHP免费学习笔记（深入）”；
- 用户未登录，
user_id为空或用 session_id 临时标识 → 换浏览器即丢失进度 - 前端请求 PHP 接口时没带 cookie 或 token，导致服务端无法识别用户
- CDN 或代理缓存了 PHP 返回的进度接口响应（尤其是 GET 请求），造成旧时间被反复返回
- 音频文件 URL 带有动态参数（如签名、时间戳），导致两次加载的
实际不是同一个资源，浏览器无法复用已缓冲数据
断点续播真正难的不是存时间，而是确保「谁、在哪个设备、播哪本书、播到哪一秒」这四个维度始终可追溯且一致。PHP 只管稳稳接住和吐出那个数字，别让它跑偏就行。
