PHP无法直接获取前端听书插件播放状态，必须由前端JavaScript监听事件后主动上报；后端需处理跨域、防刷、时效性及校验，并支持小程序/WebView桥接上报。
PHP 无法直接获取前端听书插件的播放状态
PHP 是服务端语言，运行在服务器上；而听书插件（如基于 HTML5 <audio>、Howler.js、或微信/钉钉小程序内嵌播放器）运行在用户浏览器或客户端中。两者不共享内存、不直连 DOM，PHP 没有办法「主动读取」插件当前是否在播放、进度多少、暂停还是错误。
必须通过客户端主动上报状态到 PHP 后端
可行路径只有一条：让前端 JavaScript 监听播放器事件（如 play、pause、timeupdate、ended），再用 fetch 或 XMLHttpRequest 把状态发给 PHP 接口。
常见上报字段示例：
-
status：值为"playing"/"paused"/"ended"/"error" -
current_time：当前播放秒数（audio.currentTime） -
duration：总时长（可选，用于校验） -
track_id：音频唯一标识，便于关联用户行为
PHP 接口只需接收并存入数据库或 Redis，例如：
立即学习“PHP免费学习笔记（深入）”；
$_POST['status'] = $_POST['status'] ?? '';
$_POST['current_time'] = (float)($_POST['current_time'] ?? 0);
$_POST['track_id'] = $_POST['track_id'] ?? '';
// 示例：写入 Redis（推荐高频更新场景）
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->setex("play_status:{$user_id}:{$track_id}", 300, json_encode($_POST));
注意跨域、防刷和状态时效性
前端调用 PHP 接口时容易遇到实际问题：
- 前端页面与 PHP 接口域名不同 → 必须在 PHP 响应头加
Access-Control-Allow-Origin，且不能设为*如果带 Cookie - 用户手动刷新页面或切后台 → 播放器可能继续运行但不再上报 → 建议前端加心跳（如每 15 秒
fetch一次status=playing），PHP 端记录最后上报时间，超时（如 30 秒）即视为已停止 - 恶意请求伪造播放状态 → 关键操作（如解锁下一章）不应仅依赖前端上报，PHP 需结合用户权限、播放历史、IP/设备指纹做二次校验
微信小程序或 App 内嵌 WebView 的特殊处理
如果听书插件运行在微信小程序、uni-app 或原生 App 的 WebView 中，可用桥接方式替代 HTTP 上报：
- 微信小程序：用
wx.miniProgram.postMessage发送给小程序容器，再由小程序调用wx.request上报 PHP - Android/iOS WebView：注入 JS 接口（如
Android.playStatus(...)），在 Native 层拼好参数后发起网络请求 - uni-app：统一用
uni.$emit+uni.request，避免直接操作 DOM
这类环境仍需 PHP 提供标准接收接口，逻辑不变，只是上报通道更稳定、不易被浏览器拦截。
真正难的不是“怎么传”，而是“什么时候传”和“传了怎么信”——播放状态是瞬态数据，前端不可靠，后端必须设计超时淘汰、幂等写入和异常兜底。
