PHP无法直接控制视频进度，需JavaScript监听timeupdate等事件节流上报进度至PHP接口，PHP校验参数、绑定用户身份后存入数据库，并在加载时返回进度供前端恢复播放。
PHP 本身不能直接读取或控制浏览器端的视频播放器进度，所谓“PHP 缓存视频播放进度”，实际是前端 JavaScript 记录进度 + PHP 提供后端存储接口，二者协作完成。核心在于：进度状态必须由前端采集、通过 HTTP 请求提交给 PHP 脚本保存，再在下次加载时由 PHP 返回历史进度。
前端如何获取并发送播放进度
浏览器中只有 HTMLMediaElement（如 <video></video>）能实时提供 currentTime，PHP 完全无感知。必须用 JavaScript 监听播放事件并主动上报：
-
timeupdate事件频率高（每 200–250ms 一次），不宜每次都发请求，建议节流（如每 5 秒或播放结束时提交） - 需携带唯一标识，比如视频的
video_id或资源 URL 的哈希值，否则 PHP 不知道该存哪条记录 - 推荐用
fetch()发POST请求到 PHP 接口，附带video_id和progress（单位：秒，保留 1 位小数即可） - 注意跨域：若前端域名与 PHP 接口不同，PHP 需返回
Access-Control-Allow-Origin头
PHP 怎样安全接收并存储进度
PHP 脚本不处理视频文件本身，只做「校验 → 存储 → 返回」三件事。关键点在防伪造和数据一致性：
- 必须校验
$_POST['video_id']和$_POST['progress']是否存在且格式合法（例如video_id限制为字母数字下划线，progress是非负浮点数） - 用户身份必须绑定：不能只靠前端传
user_id，要从 session 或 JWT 中提取真实登录态，防止恶意覆盖他人进度 - 存储建议用数据库（如 MySQL 的
user_video_progress表），字段至少含：user_id、video_id、progress、updated_at；避免用文件存储，易并发冲突 - 用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO确保单条记录唯一（联合主键(user_id, video_id)）
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
http_response_code(405);
exit;
}
session_start();
if (!isset($_SESSION['user_id'])) {
http_response_code(401);
exit;
}
$video_id = filter_var($_POST['video_id'] ?? '', FILTER_SANITIZE_STRING);
$progress = filter_var($_POST['progress'] ?? '', FILTER_SANITIZE_NUMBER_FLOAT, FILTER_FLAG_ALLOW_FRACTION);
if (!$video_id || !is_numeric($progress) || $progress < 0) {
http_response_code(400);
exit;
}
// 假设 $pdo 已初始化
$stmt = $pdo->prepare("INSERT INTO user_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, round($progress, 1)]);
如何在页面加载时恢复播放进度
不是自动跳转，而是把上次进度交给前端 JS，由它决定是否调用 video.currentTime = xxx。PHP 只负责查库并输出 JSON：
立即学习“PHP免费学习笔记（深入）”；
- 接口路径如
/api/get-progress.php?video_id=abc123，PHP 根据当前登录用户和video_id查库 - 务必加缓存控制：对这个接口设置
Cache-Control: no-store，避免 CDN 或代理缓存旧进度 - 返回格式统一为 JSON：
{"progress": 127.5}或{"progress": null}，前端按需处理 - 如果视频有分集/多章节，
video_id应包含集数信息（如video_101_ep2），否则无法区分
容易被忽略的边界问题
真正上线后出问题的，往往不是主流程，而是这些细节：
- 用户拖拽进度条后立即暂停，
timeupdate可能来不及触发 —— 要监听seeked和pause事件补发 - 移动端 Safari 对
localStorage的写入有延迟，别依赖它中转进度，直接 fetch 更可靠 - 视频地址带临时签名（如
?Expires=171...&Signature=xxx），video_id必须剥离签名参数，否则同一视频多次加载会存成多条记录 - PHP 接口没做 CSRF 防护？攻击者可伪造请求清空他人进度 —— 至少校验
SameSite=Strict的 Cookie 或加简单 token
