safari因系统级策略禁止后台标签页音频播放，要求用户手势触发且切页即暂停，返回需手动恢复；chrome/edge相对宽松，支持部分后台播放场景；开发者可优化提示、元数据和加载延迟。

因为 Safari 主动限制后台标签页的音频播放，这是系统级策略，不是 bug。

浏览器默认执行“用户手势优先”原则

Safari 遵循 W3C 媒体播放规范，要求所有有声媒体必须由真实用户操作（如点击、触摸）触发。一旦你切走标签页，页面失去焦点，浏览器就认为“用户已中断交互”，自动暂停音频以节省资源、延长电池、避免干扰。

• 即使音频已开始播放，切到其他标签页后也会立刻暂停
• 返回时不会自动恢复，必须再次点击播放按钮或调用 play()
• 该行为在 macOS 和 iOS 的 Safari 中一致生效，且无法通过纯前端代码绕过

平台策略叠加双重约束

除了规范本身，Apple 还在系统层加了两道限制：

小红书长文-谷歌浏览器

在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。

下载

• 后台上下文冻结：非活跃标签页的 JavaScript 执行被大幅降频，AudioContext 可能被挂起，导致 Web Audio API 失效
• 自动播放拦截升级：从 iOS 15 / macOS Monterey 起，Safari 默认禁止“无用户交互的自动播放”，连 play() 调用都可能被静默拒绝

和 Chrome、Edge 的区别在哪？

Chrome 和 Edge（Chromium 内核）虽也响应 visibilitychange 事件，但允许部分场景下保持后台音频（如播客类 PWA），而 Safari 更严格：

• 不支持 navigator.mediaSession 的后台持续播放声明（仅限前台激活状态）
• 不开放 Service Worker 驱动的后台音频解码（App Store 明确拒绝此类实现）
• 即使网页用了 webkit-playsinline 或 autoplay muted，解除静音仍需用户点击

开发者能做什么？

不能强制后台播放，但可以优化体验：

• 监听 document.addEventListener('visibilitychange', ...)，在切回时提示用户“点击继续收听”
• 用 navigator.mediaSession 设置元数据（标题、封面），提升前台恢复体验
• 对长音频内容做分段加载 + 预解码，缩短用户点击后的唤醒延迟（实测可压至 120ms）
• 在 iOS 上引导用户将网页添加到主屏幕，PWA 模式下部分权限更宽松