做过移动端 H5 视频的人大概率都遇到过这种场面Android 手机上 HLS 流播得好好的一到 iOS 的 H5 里就黑屏、转圈、只有声音没画面甚至控制台直接抛出MediaSource is not defined或者Hls is not supported。标题里说的 IOS H5 页面中 HLS 视频无法正常播放使用 hls.插件现实项目里这个“hls.插件”多半就是 hls.js。先把结论放前面iOS 的 Safari 和 WKWebView 原生支持 HLS但对 MSE 的支持长期缺失或受限而 hls.js 的核心工作方式又依赖 MSE所以无脑在 iOS 上new Hls()失败概率非常高。正确做法是先做能力探测iOS 走原生video.src m3u8Android 和桌面浏览器再交给 hls.js最后把两套逻辑封装成同一个播放器接口。这个思路适合前端、H5、混合 App、微信内嵌页、uni-app 以及小程序 web-view 场景下的开发者参考不管你是刚接触 HLS还是已经被 iOS 的播放问题折腾过几轮都可以按下面的步骤逐项排查和落地。1. 先把问题说透iOS H5 里 HLS 播放失败到底长什么样1.1 现象不是一种而是三类第一类是“完全不能播”。页面加载后 video 区域一直黑控制台报Hls is not supported、MediaSource is not defined、NotSupportedError或者 hls.js 初始化阶段就失败。这种情况通常是代码没有判断环境直接把 hls.js 当成全平台方案用了。第二类是“能播但体验不对”。视频能出画面但自动播放失败、全屏异常、没有进度条、拖动后卡死、清晰度切换无效。第三类是“表面正常偶发崩溃”。比如连续播放几个视频后页面卡顿或者切到后台再回来播放器直接黑屏。这三类问题的根源不完全一样但都绕不开 iOS 对媒体播放的限制。很多人一看到黑屏就怀疑 m3u8 地址错了其实在 iOS H5 里地址正确但播放器选错同样会黑屏。因为 iOS 的 video 元素可以原生解析 HLS但你用 hls.js 把流拆成 MP4 分片再喂给 video就需要 MSE 支持。iOS 的 WebView 如果没开 MSE或者只支持有限的 Managed Media Sourcehls.js 就接不上。这个区别非常关键也是后面所有方案分流的基础。1.2 为什么标题里特别强调“使用 hls.插件”hls.js 的优势很明显体积可控、API 丰富、支持 ABR 自动码率、错误恢复、直播低延迟、清晰度手动切换在 Android、Chrome、Firefox、Edge 以及桌面端都很好用。很多项目一开始只在 Android 和 PC 上验证发现 hls.js 跑得通就默认 iOS 也能跑。结果上线后 iOS 用户反馈黑屏开发同学再回头查才发现 iOS 根本不支持标准 MSE。这不是 hls.js 的 bug而是平台能力差异。所以标题里的“使用 hls.插件”其实点中了要害不是 HLS 有问题也不是 m3u8 一定有问题而是“用 hls.js 播放 HLS”这个组合在 iOS 上不成立。你需要把这个组合拆开按平台选择播放路径。iOS 用原生 HLSAndroid 和桌面用 hls.js其他环境再按容器能力判断。只有这样才能既保留 hls.js 的灵活性又避开 iOS 的限制。1.3 解决路线一句话能力探测后分流我会把播放逻辑分成三层。第一层探测video.canPlayType(application/vnd.apple.mpegurl)如果返回maybe或probably优先走原生 HLS。第二层探测Hls.isSupported()如果支持走 hls.js。第三层做兜底提示告诉用户当前环境不支持或者引导升级系统、切换浏览器、使用 App 原生播放器。这个顺序很重要不要反过来。因为有些 iOS 版本既支持原生 HLS也可能支持有限的 Managed Media Source但原生路径更稳资源占用也更低。很多团队会问那我能不能在 iOS 上也强上 hls.js只为了统一 API理论上 iOS 17.1 之后部分 Safari 支持 Managed Media Sourcehls.js 新版本可以尝试但兼容性、性能、后台恢复、全屏行为都不如原生。线上项目要的是稳定不是代码好看。所以我的建议很明确iOS 优先原生hls.js 作为非 iOS 环境的主力封装层统一对外暴露play、pause、destroy、switchQuality等方法。2. 原理拆解hls.js、MSE 与 iOS 原生 HLS 的三角关系2.1 HLS 本身是什么HLS 全称 HTTP Live Streaming核心思路是把一个完整视频切成很多小分片再用一个索引文件把这些分片串起来。索引文件通常是.m3u8里面记录了分片地址、时长、码率、版本等信息。播放器先下载 m3u8再按顺序下载分片边下边播。它的好处是适配 HTTP 基础设施能过 CDN、能缓存、能根据网络切换码率所以在直播和点播里都很常见。iOS 对 HLS 的支持是系统级的。Safari、WKWebView、原生 AVPlayer 都能直接识别 m3u8。你把 m3u8 地址赋给 video 元素的src系统媒体引擎会自己完成索引解析、分片下载、解码和播放。这个过程不需要页面 JS 参与也不依赖 MSE。也就是说在 iOS H5 里播放 HLS 最稳的方式其实就是让 video 自己去做。2.2 hls.js 的工作方式完全不同hls.js 是一个 JavaScript 库它把 HLS 的解析、分片下载、缓冲控制、码率切换都放在 JS 层完成。它拿到 m3u8 后自己解析出分片列表下载 TS 或 fMP4 分片然后通过 MSE 把分片喂给 video 元素。MSE 提供的是MediaSource和SourceBuffer相当于让 JS 可以动态向 video 里追加媒体数据。Android Chrome、桌面 Chrome、Firefox、Edge 都支持 MSE所以 hls.js 在这些环境里工作得很好。问题在于iOS Safari 长期不支持标准 MSE。没有 MSEMediaSource就不存在hls.js 自然无法把分片塞进 video。你在 iOS 上看到MediaSource is not defined不是网络问题也不是 m3u8 问题而是浏览器能力问题。即便某些版本提供了 Managed Media Source也有额外限制比如需要特定 API、对后台和全屏有约束不能简单等同于 Android 上的 MSE。2.3 iOS 原生 HLS 与 hls.js 的职责边界在 iOS 上原生 HLS 负责从 m3u8 到画面的一切。你不需要手动下载分片也不需要自己管理缓冲。你只需要给 video 正确的 m3u8 地址并处理好自动播放、内联播放、全屏和用户手势。hls.js 在 iOS 上最多只能做降级尝试不能作为主路径。反过来在 Android 和桌面浏览器上很多环境没有原生 HLS 支持尤其 Chrome 桌面版必须靠 hls.js 或类似库。所以职责边界很清楚iOS 把 HLS 交给系统其他环境把 HLS 交给 hls.js。封装层要做的是判断当前环境然后选择对应实现。不要试图用一套 hls.js 代码打天下那是踩坑的开始。2.4 iOS 17.1 之后的 Managed Media Source 变化iOS 17.1 之后Safari 开始支持 Managed Media Source这给 hls.js 在 iOS 上运行带来了一点可能性。但要注意这不是全面放开。Managed Media Source 对使用方式、播放器状态、后台行为都有额外要求而且旧版本 iOS 仍然不支持。线上用户不可能全部升级到最新系统所以你依然不能把 hls.js 作为 iOS 的默认方案。我的做法是在能力探测里仍然优先判断原生 HLS只有原生不可用时才考虑ManagedMediaSource或MediaSource。如果都没有就提示不支持。这样即使未来 iOS 支持得更好也不会影响现有稳定路径。技术选型要向前兼容但更要向后兼容。2.5 分片链接是 .png 时到底看什么有些 m3u8 里的分片地址以.png结尾这不代表它真的是图片。分片文件实际是什么类型要看服务端返回的Content-Type和字节内容。播放器通常根据 m3u8 里的声明、响应头和实际数据来判断扩展名不是唯一依据。但如果服务端把.png分片返回成image/png某些播放器或中间层可能会拒绝导致加载失败。所以排查时要打开 Network 面板看分片请求的响应头是不是正确的媒体类型。如果是合法授权的视频分发建议统一返回video/mp2t或application/octet-stream避免 MIME 误判。3. 环境判断与播放器选型别一上来就 new Hls3.1 三段式能力探测代码播放器初始化前先做能力探测。下面这段代码可以直接用function getPlaybackMode(video) { const canNativeHls video.canPlayType(application/vnd.apple.mpegurl); if (canNativeHls maybe || canNativeHls probably) { return native-hls; } const canMSE MediaSource in window || ManagedMediaSource in window; if (canMSE window.Hls Hls.isSupported()) { return hlsjs; } return unsupported; }这段逻辑的顺序很关键。先判断原生 HLS再判断 MSE 和 hls.js。iOS Safari 通常会返回maybe于是直接走原生。Android Chrome 原生 HLS 返回空字符串但Hls.isSupported()为 true于是走 hls.js。桌面 Chrome 同理。如果都不支持就进入兜底提示。注意不要只判断Hls.isSupported()因为 iOS 上它可能返回 false也可能因为缺少 MSE 而在后续步骤失败。3.2 不同容器里的差异Safari、WKWebView、微信、uni-appSafari 浏览器里原生 HLS 支持最好自动播放策略也相对明确。WKWebView 里App 需要配置allowsInlineMediaPlayback、mediaTypesRequiringUserActionForPlayback等参数否则视频可能全屏播放或者无法内联。微信 iOS 内置浏览器基于 WKWebView整体支持 HLS但视频可能被微信接管出现层级、全屏、返回后黑屏等问题。uni-app 的 video 组件在 App 端可能走原生播放器在 H5 端则回到浏览器能力需要区分编译平台。小程序 web-view 里更特殊。它本质上还是 WebView但受小程序平台限制视频域名、业务域名、同层渲染、全屏行为都要按平台规则处理。不要假设在 Safari 能播在 web-view 里就一定能播。最稳的验证方式是真机跑一遍而不是只看模拟器或开发者工具。3.3 选型建议表环境原生 HLSMSE / hls.js推荐方案iOS Safari支持旧版不支持新版有限原生 video m3u8iOS WKWebView支持取决于配置原生 video m3u8微信 iOS支持不推荐依赖原生 video 用户手势Android Chrome多数不支持支持hls.js桌面 Chrome不支持支持hls.js桌面 Safari支持有限原生优先uni-app App原生播放器视端而定按平台条件编译小程序 web-view受平台限制不稳定平台组件或原生能力这张表不是绝对因为系统版本和浏览器版本一直在变。但大方向不会错iOS 优先原生Android 和桌面优先 hls.js。4. 实操封装一个 iOS/Android 通用的 HLS 播放器4.1 最小可用页面结构先把 HTML 骨架搭好。video 标签要加上playsinline、webkit-playsinlineAndroid 微信里还可以加x5-playsinline、x5-video-player-typeh5。这些属性不是装饰它们直接影响视频是否内联播放、是否被浏览器接管全屏。!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1, viewport-fitcover / titleHLS 播放测试/title style html, body { margin: 0; padding: 0; background: #000; } .player-wrap { position: relative; width: 100vw; height: 56.25vw; max-height: 70vh; background: #000; } video { width: 100%; height: 100%; object-fit: contain; background: #000; } /style /head body div classplayer-wrap video idplayer controls playsinline webkit-playsinline x5-playsinline x5-video-player-typeh5 x5-video-player-fullscreenfalse preloadmetadata /video /div script src./hls.min.js/script script src./player.js/script /body /html注意hls.js 建议下载到本地静态资源里不要每次运行时去外网拉。外网 CDN 在某些网络环境下可能不稳定也会增加首屏等待时间。把hls.min.js放进项目静态目录用相对路径引入线上更可控。4.2 核心播放逻辑与代码下面是封装后的核心逻辑。它先探测环境再选择原生还是 hls.js。对外暴露统一对象方便业务层调用。function createHlsPlayer(videoEl, url) { let hls null; let mode unknown; const canNativeHls videoEl.canPlayType(application/vnd.apple.mpegurl); if (canNativeHls maybe || canNativeHls probably) { mode native; videoEl.src url; videoEl.addEventListener(loadedmetadata, () { videoEl.play().catch((err) { console.warn(原生播放失败可能需要用户手势, err); }); }); return { mode, play() { return videoEl.play(); }, pause() { videoEl.pause(); }, destroy() { videoEl.pause(); videoEl.removeAttribute(src); videoEl.load(); } }; } if (window.Hls Hls.isSupported()) { mode hlsjs; hls new Hls({ enableWorker: true, lowLatencyMode: false, backBufferLength: 30, maxBufferLength: 30, maxMaxBufferLength: 60, manifestLoadingTimeOut: 10000, manifestLoadingMaxRetry: 3, levelLoadingTimeOut: 10000, levelLoadingMaxRetry: 3, fragLoadingTimeOut: 20000, fragLoadingMaxRetry: 6, startLevel: -1, capLevelToPlayerSize: true }); hls.loadSource(url); hls.attachMedia(videoEl); hls.on(Hls.Events.MANIFEST_PARSED, () { videoEl.play().catch((err) { console.warn(hls.js 播放失败可能需要用户手势, err); }); }); hls.on(Hls.Events.ERROR, (event, data) { console.error(hls.js 错误, data); if (!data.fatal) return; if (data.type Hls.ErrorTypes.NETWORK_ERROR) { hls.startLoad(); } else if (data.type Hls.ErrorTypes.MEDIA_ERROR) { hls.recoverMediaError(); } else { hls.destroy(); } }); return { mode, play() { return videoEl.play(); }, pause() { videoEl.pause(); }, destroy() { if (hls) { hls.destroy(); hls null; } videoEl.removeAttribute(src); videoEl.load(); } }; } throw new Error(当前环境不支持 HLS 播放); }这段代码的关键点有三个。第一原生路径和 hls.js 路径分开互不干扰。第二hls.js 的错误恢复按类型处理网络错误重试加载媒体错误尝试恢复致命错误销毁。第三销毁时一定要调用hls.destroy()否则页面切来切去会残留缓冲和监听时间长了容易卡顿。4.3 hls.js 参数怎么调enableWorker: true可以让解析工作放到 Web Worker减少主线程压力但部分老设备可能不稳定如果发现播放异常可以关掉。lowLatencyMode适合直播低延迟场景点播不要开。backBufferLength控制回撤缓冲移动端内存小设置 30 秒左右比较合适。maxBufferLength和maxMaxBufferLength控制前向缓冲太大占内存太小容易卡顿。startLevel: -1表示自动选择起始码率capLevelToPlayerSize: true可以避免小窗口加载过高码率。这些参数不是越大越好。移动端内存有限缓冲太多可能导致页面崩溃尤其在 iOS 上WebView 内存超限会被系统直接回收。我的经验是点播场景下maxBufferLength控制在 30 到 60 秒直播场景再按延迟要求压缩。如果用户经常拖动进度条可以适当增大backBufferLength但不要无限制增长。4.4 自动播放与内联播放的坑iOS 对自动播放限制很严。一般情况下必须由用户手势触发play()或者视频处于静音状态。很多项目希望进入页面就自动播放这在 iOS 上很难稳定实现。更稳的做法是放一个封面图用户点击后再播放。如果是信息流场景可以尝试muted加playsinline但仍然要准备好被拦截的情况。内联播放也很重要。如果不加playsinline和webkit-playsinlineiOS 可能会把视频强制全屏页面布局和交互都会乱。App 内嵌 WKWebView 时还要在原生侧设置allowsInlineMediaPlayback true否则前端加再多属性也没用。微信内还要注意视频层级有时候视频会盖住弹窗需要做同层渲染或隐藏处理。4.5 播放器销毁与页面生命周期单页应用里路由切换时一定要销毁播放器。否则 video 还在后台加载hls.js 还在请求分片内存和带宽都会被浪费。监听visibilitychange页面隐藏时暂停页面恢复时再按需继续。不要小看这个细节很多“播放几个视频后页面卡死”的问题都是因为旧播放器没有销毁。document.addEventListener(visibilitychange, () { if (document.hidden) { player.pause(); } }); window.addEventListener(beforeunload, () { player.destroy(); });如果是列表页多个视频建议只保留当前可见视频的播放器实例其他全部销毁。移动端不要同时创建多个 hls.js 实例否则主线程和内存都扛不住。5. 服务端与 CDN 侧别让配置把播放器坑死5.1 MIME、CORS、Range 三件套播放 HLS 时服务端有三个配置必须检查。第一是 MIME。m3u8 最好返回application/vnd.apple.mpegurl或application/x-mpegURLTS 分片返回video/mp2tfMP4 分片返回video/mp4。如果分片是.png后缀也要返回正确的媒体类型或application/octet-stream不要返回image/png。第二是 CORS。原生 video 播放 m3u8 对页面 CORS 要求相对宽松但 hls.js 通过 XHR 或 fetch 加载分片必须有Access-Control-Allow-Origin。第三是 Range。拖动进度条时播放器可能发 Range 请求服务端要支持206 Partial Content否则拖动会失败或者从头下载。排查时可以直接用命令行看响应头curl -I https://example.com/video/index.m3u8 curl -I https://example.com/video/seg_001.ts重点看Content-Type、Access-Control-Allow-Origin、Accept-Ranges、Content-Range。如果这些不对播放器代码写得再好也没用。5.2 m3u8 与分片路径m3u8 里的分片地址可以是相对路径也可以是绝对路径。相对路径会基于 m3u8 所在目录解析如果 CDN 做了路径重写容易 404。建议生成 m3u8 时使用清晰的相对路径并在 CDN 侧保持目录结构一致。如果分片链接后缀是.png要确认 CDN 没有把它当成图片做特殊处理比如图片压缩、格式转换、缓存策略覆盖。任何对媒体分片的二次加工都可能导致字节流变化播放器解析失败。另外m3u8 本身不要强缓存否则直播流更新后客户端还在用旧索引。TS 分片因为文件名通常带序号或哈希可以设置较长缓存。这样既保证索引实时性又减少分片回源。5.3 缓存策略与 HTTPSHTTPS 页面里加载 HTTP 视频会被浏览器拦截这是混合内容限制。所有 m3u8 和分片地址都必须是 HTTPS。App 内嵌 WKWebView 还要检查 ATS 配置合法域名需要加入例外或使用合规证书。不要为了让视频能播就关闭全局 ATS那样会带来安全风险也可能影响上架审核。缓存策略上m3u8 可以设置Cache-Control: no-cache或较短时间分片设置Cache-Control: public, max-age31536000, immutable。如果 CDN 支持开启分片缓存和 Range 回源能显著改善拖动和二次播放体验。6. 常见问题与排查技巧实录6.1 典型故障速查表现象可能原因排查方式处理建议iOS 黑屏Android 正常hls.js 依赖 MSEiOS 不支持看是否MediaSource is not definediOS 改走原生 video.src一直转圈自动播放被拦截控制台看 NotAllowedError用户点击后再 playmanifestLoadErrorm3u8 请求失败或 CORSNetwork 看状态码和响应头配置 CORS、检查地址分片 404相对路径或 CDN 重写看 m3u8 内的分片路径修正路径或回源规则只有第一帧编码或 MIME 不对看分片 Content-Type转 H.264 AAC修正 MIME拖动失败服务端不支持 Rangecurl 看 Accept-Ranges开启 206 Partial Content.png 分片不播返回 image/png看响应头返回 video/mp2t 或 octet-stream微信内全屏异常微信接管视频真机观察加 playsinline、x5 属性页面 HTTPS 视频 HTTP混合内容控制台安全提示全站 HTTPS播放几轮后卡死播放器未销毁内存面板路由切换 destroy6.2 控制台与 Network 怎么看先看 Console。NotSupportedError、MediaSource is not defined、Hls is not supported基本都指向环境不支持。NotAllowedError是自动播放被拦截。manifestLoadError通常是 m3u8 请求失败、跨域或者 404。再看 Network过滤 m3u8 和分片请求检查状态码、响应头、响应大小。如果 m3u8 返回 200 但内容不对可能是服务端返回了 HTML 错误页。如果分片请求 403可能是鉴权参数过期。如果分片请求一直 pending可能是网络或 CDN 问题。真机调试时iOS Safari 可以通过开发菜单连接电脑查看控制台。Android 可以用 Chrome Inspect。微信内可以打开调试模式或者用 vConsole 之类的工具看日志。不要只在桌面浏览器模拟移动端桌面和真机的媒体能力差异很大。6.3 错误恢复代码模板hls.js 的错误恢复不能只写一个console.log。网络错误可以重试媒体错误可以恢复但如果是 manifest 解析失败或者环境不支持就要走降级。下面这个模板可以直接用hls.on(Hls.Events.ERROR, (event, data) { if (!data.fatal) { console.warn(非致命错误, data.type, data.details); return; } switch (data.type) { case Hls.ErrorTypes.NETWORK_ERROR: console.warn(网络错误尝试重新加载); hls.startLoad(); break; case Hls.ErrorTypes.MEDIA_ERROR: console.warn(媒体错误尝试恢复); hls.recoverMediaError(); break; default: console.error(致命错误销毁播放器); hls.destroy(); break; } });如果是原生路径没有 hls.js 错误事件但可以监听 video 的error事件根据video.error.code判断。常见的有MEDIA_ERR_SRC_NOT_SUPPORTED、MEDIA_ERR_NETWORK。原生路径下如果 m3u8 地址过期也会触发错误需要业务层重新获取地址。6.4 真机调试经验模拟器不能替代真机。iOS 模拟器的媒体能力和真机有差异尤其是硬件解码、内存回收、后台播放。微信、钉钉、企业微信等容器也要分别测试。测试时至少覆盖iOS Safari、iOS 微信、iOS App 内嵌 WKWebView、Android Chrome、Android 微信、桌面 Chrome、桌面 Safari。每个环境都验证首帧、播放、暂停、拖动、全屏、切后台、返回、销毁。只有这个矩阵跑完才敢说方案稳。7. 性能与体验优化能播之后还要好用7.1 首帧速度首帧速度受 m3u8 长度、分片大小、起始码率、网络环境影响。m3u8 如果包含几百个分片解析会变慢建议点播用 VOD 清单直播用滚动窗口。起始码率不要一上来就选最高startLevel: -1让 hls.js 自动选或者根据屏幕尺寸限制最高码率。分片时长建议 4 到 6 秒太短请求多太长首帧慢。原生 iOS 路径下首帧主要看 CDN 和 m3u8 响应速度。还可以做预加载。进入详情页前先请求 m3u8或者用preloadmetadata让浏览器提前拿元数据。但不要过度预加载移动端流量和内存都要考虑。7.2 清晰度切换与卡顿hls.js 支持手动切换清晰度调用hls.currentLevel levelIndex或hls.nextLevel。iOS 原生路径下清晰度切换依赖系统 ABR不能像 hls.js 那样直接控制。如果业务必须手动切清晰度iOS 上可以准备多个不同码率的 m3u8切换时重新设置 video.src。这样会重新加载但兼容性最好。卡顿通常来自缓冲不足、码率过高、网络抖动。可以开启capLevelToPlayerSize小窗口不加载高码率。直播场景可以调整liveSyncDurationCount但不要为了低延迟牺牲稳定性。移动端网络切换频繁4G 和 Wi-Fi 之间切换时hls.js 可能会报网络错误错误恢复逻辑要能接住。7.3 内存与后台恢复iOS WebView 对内存很敏感视频播放器占用内存较大。长时间播放或频繁切换视频容易触发系统回收。要控制缓冲长度及时销毁不用的播放器。切后台时暂停播放切回来时重新检查播放状态。有些 iOS 版本切后台再回来video 会黑屏需要重新设置 src 或调用load()。这个行为没有统一标准最好在真机上验证并在业务层加一个“恢复播放”按钮或提示。8. 我踩过的坑和给同行的建议8.1 不要忽略用户手势iOS 上自动播放失败是最常见的坑。很多人以为加了muted就能自动播实际上不同版本、不同容器策略不一样。最稳的方式是让用户点击一次再调用play()。如果是信息流可以用封面图诱导点击不要和系统策略硬碰硬。被拦截时不要只打日志要给出可点击的播放按钮。8.2 不要迷信一个插件hls.js 很强但不是万能。iOS 原生 HLS 更稳Android 上 hls.js 更灵活。播放器封装要做能力探测而不是绑定某一个库。未来如果 iOS 对 MSE 支持变好你也可以在探测逻辑里逐步放开 hls.js但不要一上来就全量切换线上稳定比技术尝鲜重要。8.3 测试矩阵要提前定不要等上线后再发现 iOS 播不了。开发阶段就定好测试矩阵系统版本、浏览器、容器、网络环境、视频类型。至少覆盖 iOS 15、16、17 和 Android 主流版本。每次修改播放器逻辑都跑一遍核心用例。尤其是 m3u8 地址、分片 MIME、CORS、Range这些服务端配置问题最容易在真机上暴露。8.4 最后再分享一个小技巧如果你在 iOS 上必须用 hls.js 做降级可以先判断ManagedMediaSource再判断MediaSource并且把Hls.isSupported()放在后面。同时给 video 加上playsinline和webkit-playsinline在 App 内嵌页面里让原生同学确认allowsInlineMediaPlayback已打开。排查问题时先看 Console再看 Network最后看服务端响应头。只要把“原生优先、hls.js 兜底、服务端配置正确”这三件事做好iOS H5 里的 HLS 播放问题基本就能从黑屏转圈变成稳定可用的状态。