controlslist="noremoteplayback"仅隐藏浏览器UI投屏按钮，无法阻止系统级投屏；真正防投屏需HTTPS+EME加密+后端许可证策略闭环，缺一不可。
直接结论：仅靠 HTML 属性无法实现真正防投屏，必须组合 controlslist="noremoteplayback + HTTPS + EME + 后端许可证策略，否则用户仍可通过系统级投屏（如 macOS AirPlay、Windows 投影）绕过。
为什么 controlslist="noremoteplayback" 只能拦住浏览器 UI 投屏按钮
这个属性只影响浏览器原生控制条里的“投屏”图标和右键菜单项，它不会阻止操作系统层的投屏行为。Chrome 和 Edge 在启用 noremoteplayback 后，会隐藏 ::-webkit-media-controls-remote-playback-button，但用户仍可手动打开系统投屏面板，把整个浏览器窗口或标签页镜像过去。
- 它不修改视频流本身，也不触发 DRM，纯属 UI 层遮蔽
- Firefox 不支持该属性（截至 2026 年 10 月），
noremoteplayback在其上完全无效 - 移动端 Safari 忽略该属性，iOS 用户长按视频仍可唤出 AirPlay 选项
EME 是防投屏的底层前提，但必须加密视频源
若视频文件本身未加密（即普通 MP4/HLS 源），调用 navigator.requestMediaKeySystemAccess 会失败或静默降级，CDM 根本不会介入——此时投屏不受限。
- 必须用
shaka-packager或mp4-dash对原始视频做 Widevine/PlayReady 加密，并嵌入 PSSH box - HTML 中需显式绑定
mediaKeys到<video></video>元素，不能只写controlslist - 播放器初始化时若未成功调用
setMediaKeys()，noremoteplayback就只是个摆设
许可证服务器必须校验投屏设备能力
EME 的 mediaKeySession 在生成密钥时，会向许可证服务器发送设备指纹（如 CDM ID、硬件绑定标识）。服务器可据此拒绝投屏设备的 license request。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 例如：Widevine L1 设备可解密并允许投屏；L3（软件 CDM）则默认禁用投屏输出
- 后端需解析 license request 中的
key_system和init_data，识别是否来自投屏会话上下文 - 返回的 license 响应中，需设置
allow_persistent_license=false且output_protection策略强制启用 HDCP
容易被忽略的硬性依赖：HTTPS 与安全上下文
所有 EME API 在 HTTP 页面下直接不可用，controlslist 虽然还能生效，但失去 EME 支撑后防投屏形同虚设。
- 本地开发用
localhost可绕过，但部署到测试/生产环境必须配有效 TLS 证书 - 部分企业内网用自签名证书，Chrome 会拒绝加载 CDM，导致 EME 初始化失败
- 若页面混入 HTTP 资源（如 poster 图片、字幕 VTT），可能触发混合内容警告，中断 EME 流程
真正起作用的不是某个单一配置，而是从视频打包、许可证策略、前端绑定到网络传输的全链路闭环。漏掉任意一环，比如忘了加密视频或没配 HTTPS，用户点几下系统快捷键就能完成投屏。
