video的muted属性不隐藏音量控件但限制其功能，iOS因严格自动播放策略需用户手势触发play()才能解锁音量控制；muted与volume=0在UI和权限处理上本质不同，真正启用音量控件的关键是用户手势后建立音频上下文。
video 的 muted 属性不会隐藏音量控件，但会改变其行为
设置 muted="true" 后，浏览器仍会显示音量按钮（如 Chrome、Firefox、Safari 的默认 controls），但点击它时不会“取消静音”——除非视频已开始播放且用户主动交互过。这是浏览器策略决定的，不是 UI 渲染问题。
为什么 iOS 上点击音量按钮没反应？
iOS Safari 对自动播放限制极严：未触发用户手势（如 tap）前，video 元素即使有 muted，其音频轨道也处于“冻结”状态，音量控件无法接管控制权。常见现象是：controls 显示了音量图标，但点击无反馈，video.muted 读取为 true 却无法设为 false。
- 必须先通过用户手势（例如按钮 click）调用
play()，才能解锁音量控制逻辑 -
autoplay+muted可绕过静音拦截，但不等于解锁音量 UI 的可操作性 - 部分 iOS 版本下，即使播放中，首次点击音量按钮仍需二次点击才生效
muted 和 volume=0 在 UI 表现上有什么区别？
两者都让视频无声，但浏览器对它们的处理完全不同：
-
muted是布尔属性，反映“是否被静音”的策略状态；音量滑块可能仍显示在 100%，但实际输出为 0 -
volume=0是数值属性，滑块位置会同步归零，UI 更“诚实”，但无法绕过有声自动播放拦截 - 若同时设置
muted="true"和volume=0.5，最终效果仍是静音，volume值被忽略 - 用户手动拖动音量滑块时，
muted会被自动设为false（前提是允许该操作）
想让音量控件真正可用，关键要满足什么条件？
不是加了 muted 就万事大吉，核心是让浏览器认为“用户已授权音频交互”：
- 确保
video元素至少被一次用户手势触发过play()（哪怕只是空调用） - 避免在
load或canplay事件里直接设muted=false，大概率失败 - 在用户点击按钮后，先
play()，再muted=false，最后更新 UI 状态 - 注意：iOS 15+ 要求
play()必须发生在用户手势的同步调用栈内，异步 setTimeout 会失效
最易被忽略的一点：音量控件是否可用，取决于播放器底层是否已建立音频上下文，而不是 HTML 属性写没写对。
