controlslist="nodownload"仅是UI提示而非安全机制，无法阻止抓包下载；真实防护需服务端实现临时签名URL、代理接口等措施。
controlslist="nodownload"只是UI提示，不是安全机制
它不改变资源可访问性，只告诉浏览器“建议别显示下载按钮”——Chrome 和 Edge 会照做，但 Safari 完全忽略，Firefox 基本不处理。W3C 规范里明确写它是 hint，不是指令。你加了这个属性，src 里的 URL 还在 DOM 里明文躺着，网络请求照样走，缓存照样存。
抓包能拿到视频地址，跟 controlslist 毫无关系
用户打开 DevTools → Network 标签页 → 筛选 media 或按文件后缀（如 .mp4、.m3u8）→ 找到对应请求 → 右键 Copy link address，就能直接下载。这个过程完全绕过 UI 层，controlslist 对此零影响。
-
controlslist="nodownload"不拦截 fetch、XMLHttpRequest，也不干预媒体栈底层加载 - 即使你同时加了
oncontextmenu="return false"，也拦不住 Network 面板里的请求 - 某些浏览器（如旧版 Chrome）在设了
controlslist="nodownload nofullscreen"后反而回退成无 controls，等于暴露更多调试入口
真正防抓包的路径不在 HTML 属性里
前端没能力阻止抓包，只能提高获取门槛。关键动作必须落在服务端：
- 用带签名和时效的临时 URL（如
AWS S3 presigned URL），链接几秒后失效 - 响应头加
Content-Disposition: inline，避免浏览器自动触发下载（但对右键另存无效） - 改用
MediaSource API+fetch分片加载，不暴露完整src，需后端支持流式响应 - 把真实地址藏在代理接口后，比如
/api/play?id=abc，校验session或Referer
如果你只改 HTML 属性就以为防住了，那抓包工具打开那一刻，你就已经输了。
立即学习“前端免费学习笔记（深入）”；
