html5多媒体在移动端需区分浏览器与webview环境：ios safari限制严格（如仅ios15+支持webm、autoplay需muted+playsinline），android chrome/firefox支持更宽松但旧webview能力受限；app内嵌webview（如微信、抖音）常阉割api，需jsbridge上报内核版本并降级处理；权限与生命周期管理关键，须监听visibilitychange和deviceorientation事件；上线前必须真机验证并按需兜底。
HTML5 多媒体能力（如 <video></video>、<audio></audio>、getUserMedia、MediaRecorder）在移动端浏览器与 WebView 容器中表现差异明显，不能简单按“是否支持 HTML5”来判断可用性，而要区分运行环境、内核版本和权限策略。
移动端浏览器：Safari、Chrome、Firefox 的关键差异
iOS Safari 是兼容性最严格的环境：iOS 15+ 才原生支持 WebM（VP9），此前仅支持 H.264/MP4；autoplay 必须搭配 muted 和 playsinline，且首次播放需用户手势触发；getUserMedia 在非 HTTPS 页面完全禁用，且 iOS 16.4 之前不支持后台音频采集。
Android Chrome 和 Firefox 支持度更宽松：WebM 全面可用，MediaRecorder 对 audio/webm 和 video/webm 均稳定支持；但旧版 Android Webview（如 4.4–6.x）缺少 MediaRecorder 或仅支持有限 MIME 类型，需检测 MediaRecorder.isTypeSupported('audio/webm') 后再启用。
- 优先用
<source></source>提供 MP4 + WebM 双格式，避免单格式 fallback 失败 - 对 Safari，可额外提供
video/mp4; codecs="avc1.42E01E"显式声明编码，提升解析成功率 - 不要依赖
navigator.userAgent判断是否为 iOS，改用matchMedia('(max-width: 768px)')+typeof navigator.mediaDevices?.getUserMedia === 'function'组合检测
App 内嵌 WebView：系统级限制比浏览器更隐蔽
微信、QQ、抖音等主流 App 使用的 WebView 并非标准 Chromium 或 WKWebView，而是定制内核（如 X5、TBS），其多媒体能力常被主动阉割：微信 iOS 端长期禁用 getUserMedia，安卓端则可能允许但默认关闭摄像头权限；抖音 WebView 中 MediaRecorder 返回 NotSupportedError 却不抛异常，需监听 onerror 并检查 state === 'inactive'。
Hybrid App 自建 WebView 更可控：Android 可调用 WebSettings.setMediaPlaybackRequiresUserGesture(false) 解除自动播放限制；iOS WKWebView 需在初始化时设置 allowsInlineMediaPlayback = true 和 mediaTypesRequiringUserActionForPlayback = []，否则即使加了 playsinline 也会全屏。
- 在 App 启动时通过 JSBridge 主动上报 WebView 内核版本和能力标识（如
window.webkit?.messageHandlers?.getVersion） - 对无法启用
MediaRecorder的场景，降级使用AudioContext+ScriptProcessorNode（旧）或AudioWorklet（新）采集 PCM，再交由 WASM 模块编码为 MP3 - 避免在 WebView 中依赖
localStorage存储录制片段——部分 App 清理策略会清空该存储，改用 IndexedDB 或临时 Blob URL
权限与生命周期：移动端独有的失败点
移动端多媒体调用失败，多数不是 API 不可用，而是权限未授予或页面不可见。Safari 和 Android Chrome 在页面切到后台时会自动暂停 <video></video> 播放并终止 MediaStreamTrack；微信 WebView 甚至会在页面滚动后静音音频轨道。
常见错误码需统一映射：NotAllowedError（用户拒绝）、NotFoundError（无设备）、SecurityError（非 HTTPS）、AbortError（后台暂停）——每种都应给出明确引导，比如“请返回页面顶部点击‘开始录制’”而非笼统提示“设备不可用”。
- 监听
document.visibilityState，在visibilitychange事件中暂停录制并保存进度 - 对 iOS，补充监听
deviceorientation事件作为手势替代方案，触发首次getUserMedia调用 - 在
video标签上绑定onstalled和onerror，捕获加载失败后尝试切换src或降级为图片占位
验证与兜底：上线前必须做的三件事
真实设备测试不可替代：模拟器无法复现 Safari 的权限弹窗时机、微信的静音策略、以及低端 Android 机型的内存回收行为。建议建立最小验证集：iPhone 12（iOS 16）、小米 Note 10（Android 11 + Chrome 115）、华为 P40（EMUI 12 + 华为浏览器）。
代码层兜底逻辑要轻量：不引入 full polyfill，而是按需封装。例如只在检测到 !MediaRecorder 时才加载 web-audio-recorder-js，只在 !navigator.mediaDevices?.enumerateDevices 时注入设备枚举 shim。
- 用
canPlayType()预检格式支持：video.canPlayType('video/webm; codecs="vp9, opus"')返回"probably"才加载 WebM - 对 App 场景，服务端下发能力配置表（JSON），前端根据 App 包名 + 版本号匹配预设策略，避免硬编码判断
- 所有媒体操作加超时控制（如
setTimeout3s 后 reject），防止因权限弹窗阻塞主线程
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
