html中audio/video标签在页面失焦时必然暂停，因浏览器强制冻结媒体状态；仅muted+autoplay的video可切回后恢复播放，audio几乎不可行；需用户手势触发首次播放，visibilitychange中仅visible时重试，且须清理资源防泄漏。
HTML 中的 <audio></audio> 和 <video></video> 标签在页面失焦（如切换标签页、最小化窗口、锁屏）时**必然暂停播放**，这不是 bug，而是所有主流浏览器（Chrome、Firefox、Safari、Edge）统一执行的策略。你无法用纯 HTML 属性或简单 JS 调用绕过它。
为什么 play() 在 visibilitychange 里总失败
当 document.visibilityState === 'hidden' 时，浏览器已冻结媒体状态：video.paused 变为 true，video.currentTime 停止更新，且后续任何 play() 调用都会被静默拒绝或抛出 NotAllowedError。关键点在于：浏览器只允许“用户手势上下文”中触发播放，而 visibilitychange 事件本身不构成有效手势。
- 即使视频之前已由用户点击播放过，一旦进入 hidden 状态，就失去“可恢复播放”的资格
-
play().catch()捕获到的错误通常是"play() failed because the user didn't interact with the document first"，但此时用户其实已交互过——问题出在上下文丢失 - 试图在 hidden 时调用
play()是徒劳的，必须等回到visible状态后才可能重试
muted + autoplay 是唯一合规的后台持续方案
只有同时满足“静音 + 自动播放豁免”条件，视频才可能在标签页切走又切回时继续播放（注意：不是真正后台运行，而是快速恢复）。音频标签几乎不可能做到，因为 <audio></audio> 即使 muted，多数浏览器仍会强制暂停。
- 必须显式写
<video muted autoplay></video>，仅 JS 设置video.muted = true不够 - 首次播放必须由真实用户手势触发（
click、touchstart），不能靠setTimeout或load事件自动调用 - 后续恢复逻辑只能放在
visibilitychange的visible分支里，并检查video.paused && video.muted - 移动端 Safari 对此更严格：即使满足上述条件，锁屏后仍会终止播放
React/Vue 中媒体元素容易漏掉的生命周期陷阱
框架组件卸载或隐藏时，<video></video> 元素若未手动暂停和清空，会继续解码、消耗 CPU、占用网络带宽——哪怕它在 DOM 中已被 v-show 或 display: none 隐藏。
- React 中避免只用
useEffect：改用useLayoutEffect确保 DOM 插入后立即load()，并在 cleanup 中调用pause()+src = ""+ 移除timeupdate等监听器 - Vue 中慎用
v-if切换：它会销毁 DOM，导致播放进度、缓冲状态全部丢失；若需保留状态，用v-show并手动管理pause()/play() - 不要在模板中直接绑定
:src="url"：这会让浏览器提前加载，失去对加载时机的控制权；应先设空字符串，onMounted后再赋值 - 组件复用场景（如 Vue 的
<keep-alive></keep-alive>）下，需在onActivated中检查是否需要恢复播放，而非依赖初始挂载逻辑
真正难处理的不是“怎么让它播”，而是“怎么让它停得干净、切得平滑、恢复得可靠”。浏览器策略不会变，能做的只有严格对齐它的规则边界——比如把静音当作默认前提，把用户手势当作不可省略的启动开关，把 visibilitychange 当作恢复信号而非播放指令。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
