加playsinline只是申请内联播放的入场券，真正生效需同时满足：playsinline与webkit-playsinline共存、muted属性硬编码、用户手势触发play()，缺一即fallback全屏。
加 playsinline 不等于能绕过全屏强制托管——它只是“申请内联播放”的入场券，真正决定是否生效的，是浏览器内核对上下文安全性的判断。
为什么 iOS Safari 加了 playsinline 还跳全屏
iOS Safari（包括微信 iOS）要求三个条件必须同时满足，缺一不可：
-
playsinline和webkit-playsinline都得写上（iOS 10–12 仅认后者，iOS 13+ 才开始稳定支持前者） - 视频必须静音：
muted要直接写在 HTML 标签里，video.muted = true动态设置大概率来不及 - 播放调用必须发生在用户手势触发的上下文中，比如
click、touchstart事件回调里；setTimeout、fetch成功后、canplay事件中调用play()全部会被拦截并降级为全屏
常见错误现象：页面自动播放失败，控制台报错 NotAllowedError: play() can only be initiated by a user gesture，接着视频在全屏界面里“默默”开始播。
微信安卓端只认 x5-playsinline="true"
微信安卓用的是 X5 内核，和 Safari 完全不同体系：playsinline 和 webkit-playsinline 对它基本无效。
- 必须显式写
x5-playsinline="true"（注意：是字符串值，不是布尔属性；React 中不能只写x5-playsinline，否则 JSX 会忽略） - 同样需要
muted+ 用户手势触发；X5 对 autoplay 更敏感，即使静音，某些版本（如微信 8.0.4x）仍可能拦截 - 若视频是 m3u8 直播流，还要额外去掉
x5-video-player-type="h5-page"（它会强制接管并全屏），改用x-webkit-airplay="true"+x5-playsinline="true"
不写 "true" 值、或混用 iOS 属性但没配 X5 属性，安卓微信里 playsinline 就是摆设。
第三方播放器（如 video.js）里 playsinline 失效的根本原因
video.js、plyr 等库默认把原始 <video></video> 包进自定义容器，再通过 JS 控制播放。这会导致两个关键问题：
- HTML 属性没透传到真实
<video></video>元素上（比如你给<video-js></video-js>加了playsinline，但内部<video></video>没继承） - 播放调用走的是播放器封装的
player.play()，而非原生video.play()，Safari 无法识别这是用户手势链路的一部分 - 部分播放器默认启用
fullscreen插件，会主动调用requestFullscreen()，覆盖掉 inline 行为
实操建议：初始化时显式配置 playsInline: true（video.js），并确保 <video></video> 标签本身已带所有必要属性；禁用 fullscreen 插件，或重写其行为。
CSS 干扰导致内联播放被静默拒绝
某些 CSS 会让 WebKit 内核直接放弃内联播放，连错误都不报，视频照常播，但就是强制全屏：
- 父容器设置了
transform（哪怕只是transform: translateZ(0)）、perspective或will-change - 父容器有
overflow: hidden，尤其在微信 iOS 里极易触发 - 视频元素自身用了
position: fixed或position: absolute且脱离文档流太深
排查方法：临时移除父级所有 transform/overflow 相关样式，看是否恢复内联；修复方案是改用 margin 或 top/left 替代 transform 布局，或把 <video></video> 提升到更外层无干扰的容器中。
真正卡住的从来不是属性写没写全，而是播放那一刻——是否处在浏览器认可的“安全上下文”里。属性只是声明意图，而手势、静音、CSS 布局、内核差异，共同构成了那个不可妥协的执行边界。
