audio.volume必须用0.0–1.0浮点数赋值，如0.35或0.0；设值前需确保readystate≥2或绑定loadedmetadata事件；微调需手动计算步进并防浮点误差；volumechange事件需比对实际值防重复触发；按钮与旋钮应分精度处理状态。
audio.volume 属性必须用 0.0–1.0 浮点数赋值
直接写 audio.volume = 50 或 audio.volume = "0.5" 都会失效：前者被当整数强制转成 1.0，后者字符串转 NaN 后 fallback 到 1.0，实际效果是音量“突然变最大”。
必须用小数，且建议保留两位精度：audio.volume = 0.35、audio.volume = 0.0（静音）。
常见错误现象：
• 页面一加载就设 volume → Safari 和部分安卓 WebView 忽略
• 未检查 audio.readyState >= 2（即元数据已加载）就设置 → 值被丢弃
• 设置后不验证：console.log(audio.volume) 可能输出 0.0（系统级静音锁定）
实操建议：
• 绑定 loadedmetadata 事件再设初始音量
• 或在用户点击按钮后设置（确保有手势上下文）
• 设完立刻读取比对：if (audio.volume !== target) { /* fallback 提示 */ }
用按钮实现“微调”必须手动计算步进值
HTML 原生 controls 不提供 +/− 按钮，也没内置步进逻辑。所谓“微调”，本质是每次点击让音量增减固定小量（如 0.05），而不是跳到某个绝对值。
实操建议：
• 定义步长常量：const STEP = 0.05
• 获取当前值：let current = Math.round(audio.volume * 100) / 100（避免浮点误差累积）
• 增加：audio.volume = Math.min(1.0, current + STEP)
• 减少：audio.volume = Math.max(0.0, current - STEP)
• 按钮需禁用状态管理：音量已达 0.0 时，“减”按钮应 disabled；达 1.0 时，“加”按钮同理
容易踩的坑：
• 直接 audio.volume += STEP → 浮点误差导致值超出范围（如 1.0000000000000002）
• 忘记四舍五入，UI 显示 0.7499999999999999 而非 0.75
• 未同步更新关联的 range 滑块 value，造成 UI 和状态脱节
volumechange 事件要防抖且区分触发源
volumechange 不只响应你代码里改 volume，还会在 muted 切换、系统全局静音开启、甚至耳机插拔时触发。它不告诉你“谁动的”，只告诉你“音量相关状态变了”。
实操建议：
• 在监听函数里加简单比对：if (e.target.volume !== lastKnownVolume) { updateUI(); lastKnownVolume = e.target.volume; }
• 若同时监听静音按钮和音量按钮，避免重复刷新 UI
• 移动端 touch 事件可能连续触发多次 input，但 volumechange 本身无性能压力，重点是防止 UI 频繁重绘
容易忽略的细节：
• 静音状态下改 volume 不会改变声音，但 volumechange 仍会触发
• iOS Safari 中，若用户未交互过，首次设置 volume 失败后，volumechange 仍可能触发（值没变，但事件发了）
按钮微调和旋钮拖拽不能混用同一套状态逻辑
如果你同时用了“+ / − 按钮”和“旋转式音量控件”，它们底层都操作 audio.volume，但用户预期不同：按钮是离散步进，旋钮是连续映射。强行共用一个 STEP 值会导致旋钮手感僵硬或按钮调节太粗。
实操建议：
• 旋钮组件内部用角度映射（如 0°→0.0，360°→1.0），精度可达 0.001 级别
• 按钮保持固定步长（0.05 或 0.1），并限制最小/最大显示值
• 两者都触发后，统一通过 volumechange 更新所有 UI 元素，而非各自维护独立状态
• 若旋钮松手后自动 snap 到最近 0.05 刻度，需显式触发一次按钮逻辑，而非覆盖原始值
复杂点在于：用户先用旋钮调到 0.37，再点“+”按钮，期望结果是 0.42（不是 0.4）；但如果旋钮内部做了四舍五入，就可能变成 0.4 → 0.45，破坏连续感。这个边界必须由业务层明确约定，不能靠组件自动猜。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
