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