WKWebView 必须在初始化时设置 allowsInlineMediaPlayback = true，且 video 标签需同时含 playsinline 和 webkit-playsinline 属性；CSS 干扰（如 transform、overflow）或 viewport 设置不当也会导致强制全屏。
WKWebView 初始化时必须设 allowsInlineMediaPlayback = true
这个配置不是可选项，而是硬性前提。iOS 的 WKWebView 默认值是 false，哪怕 HTML 里写了 playsinline，只要原生层没开这个开关，video 一播放就跳全屏。
常见错误是：在 WKWebView 实例创建后，再去改它的 configuration.allowsInlineMediaPlayback —— 这完全无效，因为 configuration 是初始化时传入的只读拷贝。
- ✅ 正确做法：在
WKWebViewConfiguration初始化阶段就设置好 - ❌ 错误写法：
_webView.configuration.allowsInlineMediaPlayback = true - ⚠️ 注意：若用 React Native 或 Flutter 的 WebView 封装，需确认其底层是否透传该配置（比如
react-native-webview的allowsInlineMediaPlaybackprop 必须显式设为true）
playsinline 和 webkit-playsinline 必须同时写在 video 标签上
iOS 版本碎片化严重，playsinline 是 HTML5 标准属性，但 iOS 9–10 只认 webkit-playsinline；iOS 11+ 虽支持标准属性，但漏掉前缀仍可能在某些微信旧版本或定制内核中失效。
不要写成 playsinline="true"，这是无效语法——它是个布尔属性，只写名字即可。
- ✅ 推荐写法：
<video playsinline webkit-playsinline muted> - ✅ 微信 X5 内核兼容补丁：
x5-playsinline也建议加上（虽非必需，但无副作用） - ❌ 单独写
playsinline或只写webkit-playsinline都不够稳
加了 playsinline 却仍全屏？检查这三类典型干扰
属性和配置都对，但视频还是跳全屏，大概率是被其他因素“劫持”了渲染路径：
- 父容器用了
transform: translateZ(0)或will-change: transform—— iOS 15+ 会强制降级到 CPU 解码，连带禁用 inline 播放 - video 元素或其祖先设置了
overflow: hidden，部分 WKWebView 版本会拒绝 inline 渲染 - 页面未声明 viewport，或
viewport中含user-scalable=no等限制项，导致内联播放上下文不被信任
这些 CSS 干扰比 JS 错误更难排查，建议用 Safari Web Inspector 连真机，在 Elements 面板逐层关闭样式验证。
playsinline 对硬件解码和内存占用的实际影响
开启 playsinline 本身不直接启用 GPU 加速，但它是一条“通行证”：只有 inline 模式下，WKWebView 才会尝试走 GPU 解码路径（前提是资源格式合规、未被 CSS 干扰）。
反过来说，如果强制全屏，系统会切换到更高优先级的原生播放器，反而可能获得更稳定的解码性能——但这牺牲了 UI 控制权。
- ✅ 真正触发硬件加速还需：MP4 容器 + H.264 编码 + HTTPS 资源 +
preload="auto" - ⚠️ 注意：iOS 上对
transform类 CSS 的敏感度远高于 Android，稍不注意就会让 video 回退到软件解码，CPU 占用飙升、发热明显 - ? 性能提示：若视频仅作背景动效（如 banner），建议用
muted+autoplay+loop，并监听loadeddata后再 play()，避免白屏等待
最易被忽略的是：iOS 不允许无用户手势的自动播放，但“用户点击后立刻调用 play()”这个时机窗口极短，稍有延迟（比如等接口返回）就会失败。别依赖 setTimeout 去模拟，直接绑定在 touchstart 或 click 事件回调里最可靠。
