disableRemotePlayback 在 Safari 中是提示而非开关，仅在 iOS 15.4+/macOS 12.3+ 上使 AirPlay 按钮置灰或隐藏，无法阻止手动镜像或系统录屏；其失效主因是版本兼容性差、依赖 playsinline 和视频加载状态，且不适用于 hls.js 等非原生播放器。
disableRemotePlayback 在 Safari 中不是“开关”，而是“提示”——设为 true 仅在 iOS 15.4+ 和 macOS Monterey 12.3+ 上触发 AirPlay 按钮置灰或隐藏，但无法阻止用户手动启用屏幕镜像，也不能禁用系统级录屏。
为什么 disableRemotePlayback 在 Safari 里经常失效
它不是强制策略，而是向浏览器传递一个偏好信号。Safari 实现上存在两个关键限制：
- iOS 15.4 之前版本完全忽略该属性，
disableRemotePlayback="true"写了也白写 - 即使支持，只要网页未显式声明
playsinline或视频未加载完成，Safari 可能跳过解析该属性 - 若页面使用了
hls.js或自定义播放器（非原生），该属性根本不会被读取——因为底层已脱离 HTML5 媒体栈
Safari 下真正能干预投屏的三个实操点
与其依赖单一属性，不如组合控制入口、行为和上下文：
- 确保
标签同时带disableRemotePlayback="true"和playsinline="true"：后者能抑制 Safari 全屏自动唤起 AirPlay 的默认行为，是前置条件 - 移除所有可能激活 AirPlay 的控件：不要渲染原生
，改用自定义按钮；尤其避免在 DOM 中保留未隐藏的::-webkit-media-controls-airplay-button伪元素（可通过 CSS 强制display: none） - 监听
webkitbeginfullscreen事件，在 Safari 全屏触发瞬间执行document.exitFullscreen()并暂停视频——这不是防投屏，而是阻断“投屏前必经的全屏过渡态”，对部分用户有干扰效果
别碰但必须知道的兼容性雷区
很多方案看似合理，实际在 Safari 上会反向暴露投屏能力或引发崩溃：
- 用
document.addEventListener('webkitairplaychange', ...)监听状态？Safari 不支持该事件，代码静默失败 - 给
加crossorigin="anonymous"试图配合 DRM？Safari 对 CORS 视频的 AirPlay 行为更不可控，且可能直接拒绝加载 - 在
canplay后立即调用video.disableRemotePlayback = true？属性是 HTML 布尔属性，JS 赋值无效，必须写在标签上或用setAttribute('disableRemotePlayback', 'true') - 以为禁用
picture-in-picture就能连带影响 AirPlay？两者完全独立，disablePictureInPicture="true"对隔空播放无任何作用
最易被忽略的一点：Safari 的 AirPlay 控件是否出现，不只看 HTML 属性，还取决于视频是否已进入 readyState >= 2 且播放器处于“可交互”状态。哪怕属性全对，如果用户首次点击播放前就尝试唤出 AirPlay 按钮，Safari 仍可能不响应——这个时机差，是真机调试时才会撞上的墙。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
