HTML5视频在移动端WebView中能播放但体验差异大，核心在于内核实现差异：Android 4.4+用Chromium支持MSE和Promise，iOS WKWebView依赖playsinline和muted才允许内联播放与自动播。
HTML5 多媒体元素（<video> 和 <audio>）在移动端 WebView 中能运行，但表现差异明显——不是“能不能播”，而是“播得稳不稳、控不控得住、体验顺不顺”。核心问题不在 HTML5 标准本身，而在不同 WebView 内核对标准的实现程度和补丁支持水平。
WebView 内核决定播放能力边界
Android 和 iOS 的 WebView 并非统一引擎，实际执行环境差异大：
- Android 4.4 以前：系统浏览器用旧版 WebKit，
<video>基本只支持 MP4 H.264 + AAC，且无全屏 API、无法监听canplaythrough等关键事件 - Android 4.4+：WebView 切换为 Chromium 内核（版本≈Chrome 30–110 不等），支持 MSE（Media Source Extensions）、
play()Promise 返回、disableRemotePlayback等新特性，但低版本仍缺失getVideoPlaybackQuality() - iOS（WKWebView）：基于 Safari WebKit，MP4 支持好，但 WebM 完全不识别；
<video>默认禁用自动播放（需用户手势触发），且playsinline属性必须显式声明才允许内联播放
常见失效场景与应对方式
很多“视频白屏”“点不动”“音画不同步”，其实不是代码写错，而是没绕过 WebView 的硬限制：
-
自动播放被拦截：iOS WKWebView 和 Android Chrome 66+ 要求
video同时满足：muted+autoplay+ 用户手势后首次调用play()；否则静音也不行 -
格式兼容靠 fallback：不要只传 MP4。建议按顺序提供：
<source src="vid.webm" type="video/webm">→<source src="vid.mp4" type="video/mp4">→ 文字提示。Android 旧 WebView 可能跳过第一个<source>直接加载第二个 -
事件监听不可靠：旧 WebView 中
loadedmetadata可能不触发，改用setTimeout轮询video.readyState；timeupdate在低端机上可能每秒只触发 1–2 次，不适合做高精度进度条 -
全屏控制失灵：Android 旧 WebView 不支持
requestFullscreen()，需降级为webkitEnterFullscreen()；iOS 必须设置playsinline="true"才允许 JS 触发全屏（否则只能点右下角原生控件）
CSS 与布局引发的渲染异常
多媒体元素在 WebView 中的尺寸、层级、缩放行为常被忽略，却直接影响可用性：
立即学习“前端免费学习笔记（深入）”；
-
width: 100%+height: auto在部分 Android WebView 中会塌陷，需加min-height: 1px或vertical-align: top防止父容器高度丢失 - iOS WKWebView 对
transform: scale(0.9)下的<video>可能触发黑屏或绿屏，避免对 video 元素直接使用 transform - 微信内置浏览器（X5 内核）会劫持
<video>并强制替换为自家播放器，若需自定义 UI，必须提前检测navigator.userAgent.includes('MQQBrowser')并禁用默认控件 - 某些安卓定制 ROM 的 WebView 会忽略
object-fit: cover，改用background-image+background-size: cover模拟视频封面更稳妥
音频特殊处理不能省
<audio> 表面简单，但在 WebView 中更容易出隐性问题：
- Android 旧 WebView 不支持
AudioContext，Web Audio API 全部失效，需用<audio>原生标签 +currentTime控制播放位置 - iOS WKWebView 中，
audio.play()必须由用户点击触发，且同一上下文中最多允许一个<audio>实例同时播放；多音效需复用同一<audio>标签并动态更换src - 微信 X5 内核对
<audio>的preload="auto"会预加载但不缓存，切页后重新加载，建议设为preload="metadata"减少首播延迟
