WKWebView不支持RTSP协议，因其被系统级硬性屏蔽；必须通过服务端转封装为HLS或WebRTC等浏览器兼容格式，如用ffmpeg转HLS后前端加载.m3u8。
WKWebView 本身不支持 RTSP 协议
直接在 WKWebView 中用 是无效的，ios 系统级媒体栈（AVFoundation）从不向 webkit 暴露 RTSP 解析能力。这不是配置问题，而是协议层被硬性屏蔽 —— WKWebView 只认 http(S)、file:// 和部分本地代理回环地址（如 http://localhost:8080），RTSP 会被静默拒绝或触发 NotAllowedError。
可行路径只有「服务端转封装」+「前端用 HLS 或 MSE」
必须把 RTSP 流经服务端转成浏览器友好的格式。常见组合：
- 用
ffmpeg或gstreamer拉取rtsp://...，实时转成 HLS（.m3u8+.ts分片），前端用； - 用
nginx-rtmp-module或SRS接入 RTSP，输出 HLS 或 WebRTC（后者需额外信令）； - 若延迟要求高（Janus/
Mediasoup做 SFU，前端用RTCPeerConnection播放，但 WKWebView 对getUserMedia和部分 WebRTC API 支持有限，需 iOS 16.4+ 且用户手动开启「相机/麦克风权限」才可能工作。
别碰「JS 解码 RTSP」这种方案
网上有些库（如 rtsp-relay、h264-player）号称纯前端解析 RTSP，实际是靠 WebSocket 传裸 H.264 Annex-B 帧，再用 WebAssembly 解码 + Canvas 渲染。问题很现实：
- iOS WKWebView 禁用
SharedArrayBuffer和部分WebAssembly同步特性，解码卡顿或直接崩溃； - RTSP 的 SDP 握手、RTP 包重组、时间戳同步全得 JS 实现，CPU 占用飙升，iPhone SE（第一代）上基本不可用；
- 没有音频同步逻辑，有画面没声音是常态。
真要嵌入原生能力？只能走自定义 WKURLSchemeHandler
这是唯一绕过协议限制的合法方式：在 App 内实现一个 WKURLSchemeHandler，拦截类似 rtsp://xxx 的请求，内部用 AVPlayer 播放，再把帧数据通过 CoreImage 转成 CVPixelBuffer，最后用 WKWebView.evaluateJavaScript() 把 base64 图像推给页面 Canvas。但代价极高：
立即学习“前端免费学习笔记（深入）”；
- 每秒 30 帧 × 720p ≈ 10MB/s 内存拷贝，WKWebView 容易 OOM；
- 音视频不同步无法规避，
AVPlayer的currentItem.asset.tracks在后台常失效； - App 审核时需明确说明「使用私有 API」风险，苹果可能拒审。
真正落地的项目，99% 都选 HLS 中转。别在 WKWebView 上赌 RTSP 原生支持 —— 它从来就没打算支持。