本文探讨了在移动设备锁屏时 web 音频播放中断的根本原因，并提供基于现代浏览器能力的可行方案，包括利用 `audiocontext` 恢复策略、`mediasession` api 增强控制力，以及对系统唤醒锁（system wake lock）等前沿标准的实践展望。
在构建 Web 端类原生音乐播放器时，一个常见却棘手的问题是：当用户锁屏后，JavaScript 事件循环被浏览器主动挂起或降频，导致 ended 事件无法触发、src 切换失败，音频队列播放中断。这并非代码逻辑缺陷，而是移动浏览器（尤其是 Firefox for Android、部分 iOS Safari 版本）为省电而实施的后台限制策略——即使使用 元素 + ended 事件监听 + 动态 src 替换的标准方案，在锁屏后也大概率失效。
✅ 核心解决方案：利用浏览器“媒体播放豁免”机制
现代移动浏览器（Chrome/Edge on Android ≥ v84，Safari on iOS ≥ 15.4）对已进入播放状态的 元素提供后台运行豁免：只要首次播放由用户手势（如点击）触发，且后续操作不中断媒体上下文，浏览器会允许音频持续播放并响应 ended 事件，即使屏幕锁定。
关键实践要点如下：
-
必须由用户手势触发首次播放（不可自动播放）：
const audio = document.querySelector('#player'); let queue = ['song1.mp3', 'song2.mp3', 'song3.mp3']; let currentIndex = 0; // ✅ 正确：绑定到按钮点击 document.getElementById('play-btn').addEventListener('click', async () => { try { await audio.play(); // 首次播放需 await Promise setupQueue(); } catch (err) { console.error("Playback failed:", err); } }); function setupQueue() { audio.addEventListener('ended', () => { currentIndex = (currentIndex + 1) % queue.length; audio.src = queue[currentIndex]; audio.play().catch(e => console.warn("Auto-play blocked:", e)); }); } -
保持 AudioContext 活跃（可选但推荐）
某些场景下（如混音、可视化），显式管理 AudioContext 可增强稳定性：let audioContext; function resumeAudioContext() { if (audioContext?.state === 'suspended') { audioContext.resume().catch(e => console.warn("Resume failed:", e)); } } // 在 play() 后及 ended 回调中调用 resumeAudioContext() -
启用 MediaSession 提升系统级兼容性
设置元数据可提升锁屏界面显示效果，并间接强化播放生命周期管理：if ('mediaSession' in navigator) { navigator.mediaSession.metadata = new MediaMetadata({ title: 'Track 1', artist: 'Artist Name', album: 'Album Title', artwork: [{ src: '/icon-192.png', sizes: '192x192' }] }); // 可选：处理锁屏界面的播放控制 navigator.mediaSession.setActionHandler('nexttrack', () => { // 手动触发下一曲（增强健壮性） audio.dispatchEvent(new Event('ended')); }); }
⚠️ 注意事项与边界情况
- iOS Safari 限制更严格：即使满足上述条件，部分 iOS 版本在长时间锁屏（如 10+ 分钟）后仍可能暂停 JS；建议配合 setTimeout 心跳检测（非精确，仅作兜底）。
- Web Workers 无法直接播放音频：Worker 中无 HTMLMediaElement 或 AudioContext，不能替代主页面播放逻辑。
- Screen Wake Lock ≠ 解决方案：该 API 仅防止屏幕熄灭，不保证 JS 继续执行，且需用户授权、违背 UX 原则，不推荐用于纯音频场景。
- System Wake Lock 尚未落地：W3C 正在推进的 System Wake Lock API 理论上可维持 CPU 活跃，但截至 2025 年仍处于提案阶段，无主流浏览器实现，不可用于生产环境。
✅ 总结：稳态实践路径
| 措施 | 是否必需 | 说明 |
|---|---|---|
用户 手势触发首次 play() |
✅ 必需 | 浏览器强制要求，否则静音/阻断 |
| ended 事件链式切换 src | ✅ 必需 | 标准且轻量的核心逻辑 |
| MediaSession 元数据配置 | ✅ 强烈推荐 | 提升锁屏体验与系统兼容性 |
| AudioContext.resume() 调用 | ⚠️ 按需添加 | 针对含 Web Audio 的复杂场景 |
| 屏幕常亮或 System Wake Lock | ❌ 不推荐 | 无效或不可用，违背设计原则 |
最终，稳定实现锁屏连续播放的关键在于尊重浏览器媒体策略——以合规方式启动播放、善用系统提供的媒体生命周期豁免机制，而非试图绕过限制。随着 Web 标准演进（如 Background Fetch、Periodic Sync 的未来整合），长期方案将更成熟，但当下，上述实践已在 Chrome、Edge、Safari 主流版本中验证有效。
