muted属性本质是自动播放准入钥匙而非音量开关，仅HTML解析时设置有效，JS动态设置被Blink内核忽略；真静音需去除视频音频流或用Web Audio API。
属性在 HTML 中不能当作音量开关用，它只是一把“自动播放准入钥匙”——加了不一定静音，不加一定播不了（尤其在移动端）。真要 100% 静音，得从视频文件本身下手。
为什么
在 Chromium 里不生效
这不是你 JS 写错了，是 Blink 内核硬性限制：
方法里对
属性做了来源判断：
只有
（即 HTML 解析器初始加载时）才会真正触发静音状态更新；JS 调用
或赋值
都被忽略。
静态写法
✅ 生效
❌ 不触发静音逻辑
❌ 同样被内核跳过（仅同步 DOM 属性，不改内部状态）
后续再调
，浏览器仍按“未静音”策略拒绝自动播放
移动端
+
为何还是有声音
iOS 和多数 Android WebView 的音频策略根本不把
当音量控制——它只是向系统声明“我承诺没声音”，从而换取自动播放权限。一旦用户手动点开控件、拖动进度条或系统判定为“非可信上下文”，静音状态就可能被覆盖或忽略。
必须同时带
，否则 iOS 全屏后脱离当前上下文，静音失效
不能靠
或
事件延迟调
，iOS 15+ 认定这不算有效用户手势
哪怕 DOM 上
返回
，实际播放时仍可能出声——因为系统走了设备音量通道
怎样才能真正保证视频没声音
前端层面对抗音频策略是徒劳的。可靠方案是让视频本身就不含音频轨道：
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
下载
立即学习
“
前端免费学习笔记（深入）
”；
用
去掉音频流
用
确认输出只有
此时连
属性都不用写，彻底避开所有浏览器音频策略校验
如果必须保留音频轨道（比如要支持用户手动开启），那就别依赖
控制静音，改用 Web Audio API 动态 mute，但注意这无法绕过自动播放限制
是布尔属性，但写法有兼容陷阱
虽然规范允许简写
，但在 XHTML 或某些老旧构建工具中，会要求显式赋值：
HTML5：推荐
XHTML / 严格模式：必须写
IE9 及更早版本完全不支持
，别试图 polyfill，直接降级为 poster + 按钮触发
真正麻烦的从来不是怎么写
，而是误以为它能关掉声音——它只负责说服浏览器“让我播”，至于播出来有没有声，那是系统和用户说了算。
mutedvideo.setAttribute('muted', 'true')HTMLMediaElement::ParseAttributemutedparams.reason == AttributeModificationReason::kByParsersetAttributevideo.muted = truevideo.setAttribute('muted', 'true')video.muted = truevideo.play()mutedautoplaymutedplaysinlinesetTimeoutcanplayplay()video.mutedtrueffmpeg -i input.mp4 -an -c:v copy output.mp4ffprobe -v quiet -show_entries stream=codec_type -of csv=p=0 output.mp4videomutedmutedmutedmutedmuted