onHide中调用pause()是最稳方案，需遍历所有video并加防错判断；onShow中须等loadeddata/canplay再play()，App端注意资源释放与路径转换。
onHide 里调用 pause() 是最稳的方案
App 切后台时，onHide 生命周期一定会触发，比监听页面 visibilitychange 或监听系统事件更可靠。H5 和 App 平台都支持，微信小程序则需配合 onAppHide 全局监听——但 uni-app 的 onHide 在 App 和 H5 下已足够覆盖切后台场景。
实操建议：
- 在页面
onHide中通过this.$refs.myVideo.pause()主动暂停，不要依赖自动行为 - 避免只监听
@pause事件——它只是响应式回调，不是控制入口 - 若使用
uni.createVideoContext，确保传入正确的id和当前组件实例（第二个参数必须是this） - 暂停前可加防错判断：
if (this.$refs.myVideo && typeof this.$refs.myVideo.pause === 'function')
切后台后 resume 播放要等 loadeddata / canplay 触发
很多开发者在 onShow 里直接 .play()，结果黑屏或报错 DOMException: The element has no supported sources——这是因为切后台期间视频资源可能被系统回收，src 需重新加载，而 play() 调用过早。
正确做法是等元数据就绪后再播放：
- 监听
@loadedmetadata或@canplay事件，再执行播放逻辑 - 或者在
onShow中先重置currentTime = 0（可选），再调用play()，并 catch 错误后重试一次 - H5 下尤其要注意：部分安卓 WebView 会清空
video.src，需在onShow中手动重新赋值
多个 video 共存时，别只停当前 ref
如果页面有轮播、列表或分页多个 <video>，仅对当前 ref 调用 pause() 不够——切后台时所有视频都应暂停，否则后台音频仍在跑，耗电且影响体验。
推荐方式：
- 给每个
<video>设唯一id（如:id="'video-' + index"），用uni.createVideoContext(id)批量操作 - 在
onHide中遍历所有已知 id，逐个.pause()；onShow中按需恢复某一个 - 避免用
v-for+ref数组（如ref="videos"），H5 下this.$refs.videos可能返回伪数组或 undefined
App 端真机调试容易忽略的坑
开发时在 H5 预览没问题，一到 App 真机就黑屏、卡死或静音——根本原因常是平台差异没兜住。
关键点：
- App 端不支持
autoplay+muted组合自动播放，切后台恢复时也需手动.play()，不能靠属性 - 某些 Android 厂商 WebView（如华为、小米）会强制释放
<video>的底层资源，pause()后再play()必须等@canplaythrough，否则大概率失败 - 路径问题：App 内本地视频要用
_www/或uni.getRealPathSync转换，切后台后重新赋值src时别漏这步
最易被忽略的是：onHide 和 onShow 在 App 后台保活状态下不一定成对触发——比如用户锁屏再解锁，可能只触发 onShow，此时要检查视频是否已暂停，而不是无条件播放。
