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 标识：
<?php
session_start();
if (!isset($_SESSION['user_id'])) {
http_response_code(401);
echo json_encode(['error' => '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免费学习笔记（深入）”；
常见坑：缓存、跨域、精度与并发更新
几个真实项目中高频出问题的点：
- PHP 接口被 CDN 或代理缓存 —— 务必加
header('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 写几行，而在前端采集时机、后端幂等设计、存储字段精度这三处细节是否抠到位。
