App端无法真正多视频并列播放，因iOS/Android系统原生播放器限制单实例解码，强制静音或暂停非焦点视频，仅H5端支持真并行；替代方案需用原生插件实现多播放器。
App端不支持真正的多视频窗口并列播放
uni-app 的 App 端（iOS/Android）底层使用 WebView 容器渲染，video 组件由系统原生控件接管，但仅允许**单个活跃视频实例**获得音频焦点和解码资源。所谓“并列播放”，实际是多个 video 元素同时存在于 DOM，但系统会强制静音、暂停或降频处理非焦点视频——你看到的“都在动”，很可能是解码帧残留或 poster 切换假象，真实音画不同步、卡顿、崩溃率高。
为什么 video 标签在 App 端无法真正并行播放
这不是 uni-app 的限制，而是 iOS AVPlayer 和 Android ExoPlayer 的设计原则：为省电、保流畅，默认禁用多实例硬解。尤其在低端 Android 机型上，两个 video 同时调 play()，第二个大概率触发 error 事件，e.detail.errMsg 类似 "MEDIA_ERR_DECODE" 或直接无响应。
- iOS：AVFoundation 强制单播放器栈，
playsinline+webkit-playsinline仅影响内联行为，不解除播放互斥 - Android：ExoPlayer 实例默认共享
MediaCodec资源，未做隔离配置时并发解码失败 - uni-app 封装层无透出多实例控制权，
uni.createVideoContext每次都返回新上下文，但底层复用同一播放器对象
可行替代方案：用原生插件桥接多播放器
若业务强依赖多路视频并行（如监控预览、多机位回放），必须绕过 video 标签，走原生能力：
- Android：用
TextureView+ 多个ExoPlayer实例，通过uni.requireNativePlugin('com.example.multiplayer')暴露startPlayer(url, containerId)方法 - iOS：用
AVPlayerLayer+ 多个AVPlayer，封装为 UTS 模块，导出addPlayer(url: string, viewId: string) - 关键点：每个播放器独占解码线程，UI 容器用
<view class="native-player">占位，由原生层 attach layer - ⚠️ 注意：这会导致包体积增大、审核风险（iOS 可能被质疑后台音频权限滥用）
H5 端可实现，但 App 端别硬刚
H5 环境下浏览器本身支持多 <video> 并行，只要不跨域、不自动播放（需用户手势），就能真·并列。但 App 端不是浏览器，它是 WebView 容器 —— 这个本质差异常被忽略。很多开发者反复尝试 @play + pause() 逻辑、加 autoplay 属性、改 preload 值，最终都败在系统级资源调度上。真正要落地，得接受「App 端只能模拟」这个前提：用缩略图+状态标签代替实时画面，点击才拉起单路全屏播放；或者直接切到原生模块开发，放弃纯 JS 方案。
