17370845950

PHP不直接保存播放进度，需前后端协同：前端JS采集并防抖上报进度，PHP接口校验身份后存入数据库，关键在采集时机、幂等设计和存储精度。

PHP 本身不直接保存播放进度，关键在前后端协同

PHP 是服务端语言，无法直接读取浏览器中 video 元素的当前播放时间（currentTime），也不能监听 timeupdate 事件。所谓“PHP 实现进度保存”，实际是 PHP 提供接口接收前端传来的进度值，并存入数据库或文件；前端 JS 负责采集、上报、恢复。混淆这一点，容易在服务端写一堆无用逻辑。

前端如何采集并定时上报进度（含防抖与完成标记）

用户拖拽、暂停、关闭页面都可能影响进度准确性。单纯每秒发一次请求既浪费又不可靠。推荐策略：

• 使用 timeupdate 事件监听，但用 setTimeout 防抖，例如 10 秒内只上报最后一次值
• 监听 ended 事件，上报 progress=100 或特殊标记（如 is_finished=1）
• 监听 beforeunload，同步触发一次最终上报（注意：此操作需是同步 AJAX 或 fetch(..., { keepalive: true })）
• 恢复播放时，先发 GET 请求到 PHP 接口（如 /api/get-progress.php?video_id=123），再设置 video.currentTime = response.progress

PHP 后端接口示例：接收 & 存储进度（需登录态校验）

必须校验用户身份，否则任何人都能伪造进度覆盖他人记录。假设使用 session 登录，且视频用 video_id 标识：

 'not_logged_in']);
    exit;
}

$video_id = (int)$_POST['video_id'] ?? 0;
$progress = (float)$_POST['progress'] ?? 0.0;

if ($video_id <= 0 || $progress < 0 || $progress > 100) {
    http_response_code(400);
    echo json_encode(['error' => 'invalid_params']);
    exit;
}

// 假设用 PDO 操作 MySQL，表结构：user_id, video_id, progress, updated_at
$stmt = $pdo->prepare("INSERT INTO video_progress (user_id, video_id, progress, updated_at) 
                       VALUES (?, ?, ?, NOW()) 
                       ON DUPLICATE KEY UPDATE progress = VALUES(progress), updated_at = NOW()");
$stmt->execute([$_SESSION['user_id'], $video_id, $progress]);

echo json_encode(['success' => true]);
?>

注意：video_progress 表必须有联合唯一索引 (user_id, video_id)，否则 ON DUPLICATE KEY 不生效。

常见坑：缓存、跨域、精度与并发更新

几个真实项目中高频出问题的点：

• PHP 接口被 CDN 或代理缓存 —— 务必加 h

  

  eader('Cache-Control: no-store');
• 前端 fetch 到 PHP 接口跨域失败 —— 确保 PHP 响应头包含 Access-Control-Allow-Origin 和 Access-Control-Allow-Credentials: true
• 进度值用 float 存 MySQL 的 FLOAT 类型，小数精度丢失（如 99.9999999 变成 100）—— 改用 DECIMAL(5,2) 存百分比，或直接存毫秒级整数（INT）
• 用户多端同时看同一视频，最后上报者覆盖之前所有进度 —— 若需强一致性，可加乐观锁（如带 updated_at 时间戳比对）或改用 Redis + SETNX 控制写入频次

进度保存看着简单，真正稳定跑一年不出错，关键不在 PHP 写几行，而在前端采集时机、后端幂等设计、存储字段精度这三处细节是否抠到位。