HTML视频在后台暂停是浏览器主动限制策略，非bug；因隐私与性能考量，页面失焦时video.paused为true、currentTime冻结、音频静音，autoplay+muted仅解决首帧播放而非后台持续运行。
HTML 视频无法在后台（比如标签页失焦、浏览器最小化、系统锁屏）继续播放，不是 bug，而是现代浏览器的主动限制策略——play() 被暂停、currentTime 停滞、音频被静音或完全停止，这是默认行为，无法用纯 HTML 属性绕过。
为什么 video 标签在后台会暂停播放
所有主流浏览器（Chrome、Firefox、Safari、Edge）都对非用户主动触发的媒体播放施加运行时限制：一旦页面失去焦点（document.hidden === true），播放器会进入“受限状态”，表现为：
-
video.paused变为true，即使之前是播放中 -
video.currentTime不再更新，时间轴冻结 - 若未设
muted，音频通道会被强制关闭 -
play()调用可能立即 resolve 但实际无声音/画面推进
这不是兼容性问题，而是隐私与性能策略——防止网页在后台偷偷耗电、占用 CPU 或播放干扰性音频。
autoplay + muted 不能解决后台播放
很多人误以为加上 autoplay 和 muted 就能“一直播”，但这两者只影响页面加载初期的首次播放授权，不解除后续的焦点限制：
立即学习“前端免费学习笔记（深入）”；
-
autoplay muted只让视频在页面载入时“有机会”启动一次 - 一旦用户切走标签页，
visibilitychange事件触发后，播放必然中断 - 即使监听
visibilitychange并在document.visibilityState === 'visible'时调用play()，也仅能在切回时恢复，无法维持后台持续播放
换句话说：autoplay 解决的是“首帧启动权”，不是“后台运行权”。
真正能后台播放的唯一合法路径：Web Audio API + canvas 渲染
如果你确实需要后台持续处理视频帧（比如做实时分析、截图、转码预览），必须放弃 <video> 的原生播放逻辑，改用：
- 用
fetch()或MediaSource手动加载视频片段（MP4/H.264 raw NAL units） - 通过
OffscreenCanvas+createImageBitmap()解码关键帧（需 Chrome 85+ / Firefox 113+） - 用
Web Audio API单独拉取并播放音频轨道（需解复用） - 全程不依赖
video.play()，规避浏览器媒体策略拦截
注意：这已不属于“HTML 播放视频”的范畴，而是 WebAssembly 级别的音视频处理，开发成本高、兼容性差，且仍受系统级电源管理影响（如 macOS Safari 在后台会降频解码）。
实际项目中更务实的做法
绝大多数所谓“后台播放需求”，其实只需视觉/体验层面的延续感，而非真实持续解码：
- 用
poster+ CSS 动画模拟“还在动”（适合 banner、引导页） - 监听
visibilitychange，在切出时记录currentTime，切回时seek并play()（最常用） - 对纯背景视频，直接用 GIF 或 Lottie 替代，完全不受焦点限制
- 如果必须用视频且允许用户交互，把播放控制绑定到
notification或 PWA 的background sync（需 manifest 配置和用户授权）
别在 <video loop autoplay muted> 上反复试错——浏览器不会为你破例。判断清楚你要的到底是“真后台运行”，还是“用户感知不到中断”，后者几乎总能用更轻量的方式实现。
