onvolumechange 事件不响应所有静音操作，仅用户通过原生滑块或快捷键触发的静音才可靠触发；代码中设置 muted 不会触发该事件，故应结合主动同步与 visibilitychange 校验来保障 UI 准确。
video.onvolumechange 事件不响应静音操作？
onvolumechange 确实会触发，但不是所有静音方式都走它——关键看用户怎么静音。
点击你写的自定义按钮、按键盘 m 键、拖动原生音量滑块到 0，这三种行为中，只有后两者在部分浏览器（尤其是 Safari）里可能自动设 video.muted = true 并触发 volumechange；而你代码里执行 video.muted = true 不会触发该事件（这是规范行为，不是 bug）。
所以不能只靠监听 onvolumechange 来“捕获所有静音动作”，它更适合做“状态同步兜底”，而不是“动作监听入口”。
为什么 volumechange 是 UI 同步的唯一可靠时机
因为它是唯一能覆盖用户绕过你按钮的所有路径：
- 用户拖动浏览器原生音量滑块（哪怕没点喇叭图标）
- 用户用键盘快捷键（
m静音 /↑↓调音量） - 浏览器自动响应（比如把音量拉到 0，Safari 可能悄悄设
muted = true）
volumechange 触发时，video.muted 和 video.volume 都已更新完毕，你可以放心读取并同步 UI。
常见错误：
立即学习“前端免费学习笔记（深入）”；
- 在
volumechange里又去设video.muted或video.volume→ 触发二次volumechange，造成无限循环 - 只检查
video.volume === 0来判断是否静音 → 错！muted = true时volume可能仍是 0.7，音频照样不出声
正确做法是：
- 每次进入 handler，只读状态，不写状态
- 用
video.muted判断静音与否，不是volume值 - 更新按钮图标、文字、
aria-pressed属性
如何避免 volumechange 在 iOS Safari 中延迟或丢失
iOS Safari 在页面切到后台或 WebView 渲染卡顿时，volumechange 可能延迟几百毫秒，甚至完全不触发（尤其音量滑块拖动后）。
补救方案：
- 在按钮点击、键盘事件等明确用户意图的地方，主动调用一次 UI 同步函数（不要等事件）
- 对于音量滑块的
input事件，也立即同步：slider.addEventListener('input', () => { video.volume = slider.value; updateMuteButtonUI(); // 立即更新，不等 volumechange }); - 加一层
requestAnimationFrame容错：video.addEventListener('volumechange', () => { requestAnimationFrame(() => updateMuteButtonUI()); });
localStorage 持久化时别只存 muted
如果只存 localStorage.setItem('muted', video.muted)，恢复时直接设 video.muted = true/false，会导致一个问题：
- 上次静音前
volume是 0.6，静音后存了true - 下次打开页面，设
video.muted = false，音量立刻跳回 0.6 —— 用户没动滑块，声音却突然变大
必须同时存两个值：
-
localStorage.setItem('video-muted', JSON.stringify(video.muted)) -
localStorage.setItem('video-last-volume', video.volume)
初始化时先读muted，再读last-volume；取消静音时，手动恢复video.volume
容易被忽略的是：iOS Safari 在页面后台时可能丢掉 volumechange 事件，导致本地状态和实际 muted 值脱节 —— 所以每次页面可见（visibilitychange）时，最好强制校验一次 video.muted 并同步 UI。
