disableremoteplayback仅作投屏提示，不拦截系统级快捷键；因快捷键由os/浏览器ui层直接响应，html属性无法干预，且keyboard lock api亦不支持锁定此类热键。
disableRemotePlayback 属性为什么拦不住快捷键
disableRemotePlayback 是 <video></video> 标签唯一原生支持的投屏控制属性，但它只向浏览器“提示”不希望被投屏，**不拦截任何快捷键**。比如 macOS 的 Cmd+Shift+P、Windows 的 Win+K 或 Chrome 地址栏的投屏图标，这些都由系统或浏览器 UI 层直接响应，HTML 属性完全无法干预。
常见错误是以为写上 disableRemotePlayback="true" 就能生效——其实必须写成无值布尔形式：disableRemotePlayback（不带等号和值），否则被忽略。
Keyboard Lock API 能锁投屏快捷键吗
不能。navigator.keyboard.lock() 只能锁定指定键码（如 'KeyP'、'ShiftLeft'），但投屏快捷键属于操作系统级热键，Chrome/Firefox 等浏览器明确不将其暴露给 JavaScript。调用 lock(['Meta','Shift','KeyP']) 会直接抛出 SecurityError 或静默失败。
真正能被 lock() 控制的，仅限于页面内自定义交互场景下的普通按键，比如游戏方向键或编辑器命令键。投屏类快捷键不在其管辖范围内。
监听 webkitbeginfullscreen 或 enterpictureinpicture 有用吗
有用，但只是事后响应，不是拦截。
-
enterpictureinpicture事件在小窗模式已激活后才触发，此时投屏可能早已开始 -
webkitbeginfullscreen（Safari）或fullscreenchange（通用）只能感知全屏状态变化，无法阻止投屏动作本身 - 你可以在这些事件里执行
video.pause()或弹警告，但用户只要重试一次，就绕过去了
真正需要防投屏时该盯住哪几个点
投屏防护本质是服务端策略问题，前端最多做轻量提示和响应：
- 确保视频资源走 HTTPS + 动态 Token（如
/video/123?token=abc&expires=1734700000），Token 绑定设备指纹或会话 ID - 在服务端校验
Referer和User-Agent，拒绝非预期来源的媒体分片请求 - 对 HLS/DASH 流启用 AES-128 加密，并让密钥 URL 也带时效签名
- 前端可监听
enterpictureinpicture后上报埋点，用于后台风控，而非阻断
别在 keydown 里反复尝试拦截 Cmd+Shift+P——它根本不会触发该事件，纯属白忙。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
