PHP后端需通过约定接口接收前端插件主动上报的播放事件数据，经校验、限频、异步写入等安全处理后存入数据库，并结合progress、volume等字段判定有效播放，避免依赖不可信的前端存储。
PHP 后端如何接收听书插件的播放上报
听书类插件（如基于 Web Audio、H5 <audio> 或小程序 SDK）通常不会自动把播放行为同步到你的 PHP 后端，必须由前端主动发起请求。关键不是“调用插件”，而是「约定好上报接口」。
常见做法是：插件在 play、pause、ended、timeupdate 等事件触发时，用 fetch 或 XMLHttpRequest 向你的 PHP 接口提交数据，比如：
POST /api/log_play.php
Content-Type: application/json
{
"book_id": "123",
"chapter_id": "456",
"event": "play",
"timestamp": 1717023456,
"duration": 182.4,
"progress": 0.12
}
PHP 端只需接收并存入数据库，不涉及调用插件本身。
PHP 接口怎么安全接收并写入播放日志
直接裸收前端 POST 数据风险高：重放、刷量、伪造参数。至少做三件事：
立即学习“PHP免费学习笔记（深入）”；
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 校验
Referer或加签（如前端用固定密钥 + 时间戳 + 参数生成sign，PHP 侧复算比对） - 限制接口频率（例如单个
book_id+ip每分钟最多 5 条play日志） - 用
INSERT DELAYED或写入消息队列（如 Redis List），避免高并发时 MySQL 写入阻塞
示例核心逻辑片段（不带鉴权，仅示意结构）：
<?php
$data = json_decode(file_get_contents('php://input'), true);
if (!$data || !isset($data['book_id'], $data['event'])) {
http_response_code(400);
exit;
}
// 过滤危险字符，强制转为整型/浮点
$book_id = (int)$data['book_id'];
$event = preg_replace('/[^a-z_]/', '', $data['event']);
$progress = isset($data['progress']) ? (float)$data['progress'] : 0.0;
// 写入 MySQL（建议用 PDO 预处理）
$stmt = $pdo->prepare("INSERT INTO play_log (book_id, chapter_id, event, progress, created_at) VALUES (?, ?, ?, ?, NOW())");
$stmt->execute([$book_id, (int)($data['chapter_id'] ?? 0), $event, $progress]);
?>
怎么区分「有效播放」和「误触/静音播放」
单纯记录 play 事件意义不大。真实统计需结合行为阈值：
-
event = "play"且progress >= 0.05（即播放超 5% 才算启动） - 同一
book_id+ip在 10 分钟内重复play忽略（防刷新） - 若插件支持，上报
volume和muted字段，volume == 0 && muted == true的可标记为「静音无效播放」 - 服务端可补计算「完成率」：查该用户对某章节的最高
progress，大于 0.95 记为「听完」
为什么不能只靠前端 localStorage 或 Cookie 统计
因为不可信、不可聚合、易丢失：
-
localStorage数据只存在单设备，换手机/清缓存就丢 - 无法跨用户去重（比如多人共用一台设备）
- 无法做实时监控（比如发现某章节失败率突增，得靠服务端聚合报警）
- 埋点逻辑一旦写死在前端，后续调整统计口径（如改「播放 30 秒才算」）必须发版，而服务端规则可热更新
真正要做的，是让插件成为「数据采集器」，PHP 成为「可信汇聚点」——这个分层意识比具体代码更重要。
