php后端须在音频播放接口处校验用户对每本音频的播放次数，通过数据库行锁（select ... for update）或redis原子操作实现并发安全，返回带签名与时效的临时url防止绕过。
PHP 后端如何限制用户对听书插件的播放次数
不能靠前端 JS 或 HTML 控制，必须在 PHP 后端做校验。听书插件（如基于 audio 标签 + 接口鉴权的方案）的播放请求，最终会调用一个 PHP 接口获取音频 URL 或直传流地址，这个接口就是唯一可控入口。
用数据库记录并校验单用户播放次数
每次播放请求到达 PHP 接口时，先查库、再判断、最后更新。关键字段：用户 ID（$user_id）、音频 ID（$book_id）、已播放次数（play_count）、总允许次数（max_play）。
常见错误现象：没加事务或没锁行，导致并发请求绕过限制；或只按用户不按音频粒度统计，造成“听一本不限次，换一本又重置”这种误判。
- 使用
SELECT ... FOR UPDATE或PDO::beginTransaction()保证原子性 -
$max_play建议存在音频配置表里，而非硬编码在 PHP 中，方便运营调整 - 若需支持“7 天内限 3 次”，则额外加
last_play_time字段并做时间窗口判断
$pdo->beginTransaction();
$stmt = $pdo->prepare("SELECT play_count, max_play FROM user_book_play WHERE user_id = ? AND book_id = ? FOR UPDATE");
$stmt->execute([$user_id, $book_id]);
$row = $stmt->fetch(PDO::FETCH_ASSOC);
if (!$row || $row['play_count'] >= $row['max_play']) {
throw new Exception('播放次数已用完');
}
$stmt = $pdo->prepare("UPDATE user_book_play SET play_count = play_count + 1, last_play_time = NOW() WHERE user_id = ? AND book_id = ?");
$stmt->execute([$user_id, $book_id]);
$pdo->commit();
结合 Redis 实现高性能频次控制
当并发高、或需支持滑动窗口（如“每小时最多 2 次”），数据库写压力大，改用 Redis 的 INCR + EXPIRE 更合适。键名建议用 play:uid:{$user_id}:bid:{$book_id}。
立即学习“PHP免费学习笔记（深入）”；
注意点：Redis 不是强一致性存储，极端情况下可能漏计一次，但对听书这类非金融场景可接受；务必设置合理过期时间，避免键无限堆积。
- 用
INCR增加计数，再用EXISTS判断是否首次写入，决定是否设过期 - 不要用
SETNX + EXPIRE两步，有竞态风险；应改用 Lua 脚本或 Redis 2.6+ 的SET key value EX seconds NX - 如果音频资源本身是 CDN 直链，PHP 接口只需返回 302 跳转，那频控逻辑必须放在这跳转前，否则插件会绕过
前端播放器如何配合后端限制不被绕过
听书插件（如 aplayer、xgplayer 或自研 H5 播放器）本身无法阻止用户 F12 抓包重放 URL。所以 PHP 接口返回的音频地址必须是**临时有效、带签名、单次或短时效**的。
典型做法：不返回原始 MP3 地址，而是返回一个由 PHP 签发的带参数的临时链接，例如：/api/play.php?book_id=123&sig=abc123&ts=1718234567，后端验证 sig 是用 md5($book_id . $user_id . $secret . $ts) 生成，且 $ts 5 分钟内有效。
容易踩的坑：签名密钥 $secret 写在配置文件里却未设权限，被 Web 目录意外暴露；或时间戳校验没做时区统一，导致部分用户提前失效。
