controlsList="nodownload" 在 audio 标签上无效，因Chromium明确仅支持video元素；Firefox和Safari则完全不支持该属性；禁用音频下载需采用自定义播放器+服务端鉴权+MSE等组合方案。
controlsList="nodownload" 在 audio 标签上根本不起作用
Chrome 和 Edge 从 73 版本起支持 controlsList 属性，但仅对 <video></video> 元素生效；<audio></audio> 元素传入 "nodownload" 或任何值，浏览器都会静默忽略——控制条照常显示下载按钮，右键菜单也照常提供“另存为音频”选项。
为什么 audio 不支持 controlsList？
这是 Chromium 的明确设计决策（见 Chromium issue #840425），理由是：音频内容体积小、场景轻量，且“下载音频”行为在多数用户场景中不构成显著风险。因此，该属性的实现被限定在 <video></video> 上，未向后扩展到 <audio></audio>。
Firefox 和 Safari 更进一步：连 <video></video> 都不支持 controlsList，所以这个属性本身跨浏览器兼容性就很差。
真想禁用音频下载，能做什么？
必须放弃依赖原生控件，改用自定义播放器 + 技术限制组合：
- 用
preload="none"+crossorigin="anonymous"防止直接拖拽 URL 下载（但无法阻止 DevTools 中抓取Network里的请求） - 把音频文件放在非公开路径，配合服务端鉴权（如临时 token、Referer 校验、User-Agent 限制），让直接访问链接返回 403
- 用
MediaSource Extensions (MSE)分片加载音频（如通过fetch+arraybuffer+sourceBuffer.appendBuffer()），切断原始 URL 暴露路径 - 禁用右键：
oncontextmenu="return false"（仅防小白，不影响快捷键或开发者工具）
注意：controlsList 不是安全机制，它只是 UI 提示开关；所有前端手段都无法真正阻止有心人获取音频数据——只要音频能播，就必然能录。
那 controlsList 还值得用吗？
只在明确目标是 Chrome/Edge 视频播放器、且接受低兼容性时才考虑。例如：<video controls controlslist="nodownload noremoteplayback" src="demo.mp4"></video> 可隐藏下载按钮并禁用投屏入口。但一旦换成 <audio></audio>，加了也白加。
最容易被忽略的一点：很多人以为加了 controlsList 就等于“防盗”，结果上线后发现音频链接在 Network 面板里明文躺着，还带完整时长和格式信息——这根本不是属性的问题，而是对前端可控边界的误判。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
