本文介绍在移动设备锁屏时保持网页音频连续播放的可行方案，包括浏览器行为差异分析、系统唤醒锁api现状及实用替代策略，帮助开发者构建可靠的web音乐播放器。
在现代移动浏览器中，实现“后台连续播放音频列表”看似简单——监听
根本原因在于操作系统级节能策略：锁屏后，浏览器进程可能被系统降级为低优先级，JS 定时器、事件监听器、Promise 回调等均可能失效。此时，依赖前端逻辑驱动的“手动切歌”方案天然不可靠。
✅ 可行方案对比与推荐路径
| 方案 | 是否可行 | 说明 |
|---|---|---|
| Screen Wake Lock API (navigator.wakeLock.request('screen')) | ❌ 不适用 | 仅防止屏幕熄灭，不保证 JS 继续执行，且需用户交互触发，违背“不常亮屏幕”需求。 |
| Web Workers | ❌ 无效 | Web Worker 在锁屏后同样被暂停（Chrome 90+ 起明确支持后台运行，但仍无法直接控制 ——Worker 无 DOM 访问权限，不能操作 |
| AudioContext + Web Audio API | ⚠️ 有限支持 | 可在 Worker 中生成/解码音频，但无法加载远程 MP3/WAV 并自动衔接播放，工程复杂度高，兼容性差。 |
| ✅ 当前最可靠实践 | 关键在于：首次播放必须由用户手势触发，后续自动播放（如 ended 后的下一首）在多数现代浏览器（Chrome、Edge、Samsung Internet）中被允许——前提是不中断媒体上下文。 |
✅ 推荐实现：保持媒体上下文连续性的播放链
核心原则：避免销毁/重建
<audio id="player" preload="auto"></audio>
const player = document.getElementById('player');
let queue = ['/songs/1.mp3', '/songs/2.mp3', '/songs/3.mp3'];
let currentIndex = 0;
// ✅ 用户首次点击播放（必需）
document.getElementById('play-btn').addEventListener('click', async () => {
try {
await player.play(); // 建立媒体会话
playCurrent();
} catch (e) {
console.error('Initial play failed:', e);
}
});
function playCurrent() {
if (currentIndex >= queue.length) return;
player.src = queue[currentIndex];
player.onended = () => {
currentIndex++;
if (currentIndex < queue.length) {
// ✅ 复用同一 audio 元素，保持上下文活跃
player.load(); // 重置状态（可选）
player.play().catch(e => {
console.warn('Auto-play blocked for next track:', e);
// 若被阻止（罕见），可引导用户轻触屏幕重试
});
}
};
}⚠️ 关键注意事项
-
iOS Safari 限制严格：即使用户已触发播放，锁屏后 ended 事件仍可能丢失。建议搭配 Media Session API 提升兼容性：
if ('mediaSession' in navigator) { navigator.mediaSession.metadata = new MediaMetadata({ title: 'Track Title', artist: 'Artist Name' }); navigator.mediaSession.setActionHandler('nexttrack', () => { currentIndex = Math.min(currentIndex + 1, queue.length - 1); playCurrent(); }); } - 服务端优化：使用 preload="metadata" 或 preload="auto" 减少切换延迟；音频文件建议采用 MP3（广泛兼容）或 Opus（更小体积）。
- 降级策略：检测 player.paused 或 player.ended 状态异常时，提示用户“轻触屏幕恢复播放”，或提供“后台播放”开关（启用 Wake Lock 作为可选增强）。
? 未来展望：System Wake Lock API
W3C 正在推进的 System Wake Lock API（非屏幕锁定，而是保持 CPU/JS 运行）有望从根本上解决该问题。其设计目标正是允许 Web 应用在后台持续执行任务（如音频调度、下载、同步）。目前处于草案阶段，Chrome 已在实验性标志中支持（chrome://flags/#wake-lock），但尚未默认启用。开发者可关注 W3C Issue #4 获取标准化进展。
总结：现阶段最稳健的方案是复用 ，辅以优雅降级。无需强行保活 JS 线程，而是顺应浏览器媒体策略，让播放逻辑“融入”系统音频生命周期——这才是 Web 音频在移动端长期可用的正道。
