HTML原生<audio>标签无法限制播放次数，必须用JavaScript监听ended或play事件计数并拦截，且需服务端校验token才能真正防绕过。
用 <audio> 标签无法原生限制播放次数
HTML 原生的 <audio> 标签没有 maxplays、playcount 或类似属性。所谓“限制播放次数”必须靠 JavaScript 主动监听和拦截，否则用户右键另存、刷新页面、禁用 JS 后都能绕过。
常见错误现象：在 <audio> 上加自定义属性（如 data-max-plays="2"）但不写 JS 控制逻辑，结果毫无限制效果。
- 所有播放触发方式都要覆盖：
play()调用、用户点击播放按钮、空格键、自动播放（autoplay） - 需监听
ended事件来计数，不能只靠play事件——因为一次播放可能被中途暂停，不应计入完成次数 - 若允许多次加载同一音频（比如切换 tab 后重新进入），需把计数存在
sessionStorage或组件状态里，不能只用局部变量
用 JavaScript 拦截第 N+1 次播放请求
核心思路是：在每次 play() 被调用前检查已播放完成次数，超限时调用 pause() 并移除播放控制（如禁用按钮、隐藏控件）。
示例逻辑（假设最多播 2 次）：
立即学习“前端免费学习笔记（深入）”；
<audio id="my-audio" src="sound.mp3" controls></audio>
<script>
const audio = document.getElementById('my-audio');
let playCount = 0;
const maxPlays = 2;
<p>audio.addEventListener('ended', () => {
playCount++;
});</p><p>audio.addEventListener('play', (e) => {
if (playCount >= maxPlays) {
e.preventDefault();
audio.pause();
audio.controls = false; // 可选：移除控件防止误点
console.warn('已达最大播放次数');
}
});
</script>-
play事件在播放开始前触发，适合拦截；但要注意它会在自动播放、play()调用、用户点击时都触发 -
ended事件只在自然播完时触发，适合准确计数；若用户拖拽进度条跳过结尾，不会触发，因此不计入“一次完整播放” - 如果需要严格按“触发播放行为”计数（不管是否播完），就把计数逻辑移到
play事件里，但要加防重入（例如用setTimeout延迟判断paused状态）
兼容自动播放与移动端的注意事项
移动端浏览器（尤其是 iOS Safari）对自动播放限制极严：autoplay 属性基本无效，且首次播放必须由用户手势触发。这意味着你写的“限制逻辑”可能根本没机会运行——因为第一次 play() 就被静音或拒绝了。
- 不要依赖
audio.play().catch(...)的失败回调来计数，它抛的是DOMException，不是播放完成 - 若需支持自动播放场景，得先绑定用户点击/触摸事件，在回调里调用
play()，再在此处做计数判断 - iOS 上
ended事件有时延迟或丢失，建议加兜底：监听timeupdate，当currentTime >= duration - 0.1且paused为 true 时手动计数 - 避免用
loop="true"，它会让单次播放无限循环，彻底破坏计数逻辑
真正可靠的次数控制必须服务端参与
纯前端限制只防君子不防小人。用户禁用 JS、抓包重放、直接访问音频 URL，都能绕过。如果这是版权敏感内容（比如试听片段、付费课程音频），必须结合服务端校验。
典型做法：
- 音频 URL 带一次性 token（如
/audio/123?token=abc456），后端验证 token 有效性并记录使用次数 - 前端每次播放前先 fetch 一个
/api/play-check?track_id=123，服务端返回{ allowed: true, remaining: 1 }才允许调用play() - token 过期时间设短（如 60 秒），防止被截获复用
前端限制只是体验层优化，关键逻辑永远得落在服务端——这点容易被忽略，直到上线后发现日志里全是重复下载记录。
