直接修改 audio 元素 CSS 几乎无效，因浏览器对原生控件样式支持有限且不一致；唯一跨浏览器可控方案是移除 controls 属性，用 HTML/CSS/JS 自定义界面。
为什么直接改 audio 元素的 CSS 几乎没用
浏览器对 <audio></audio> 的原生控件（播放/暂停、进度条、音量滑块）只暴露极有限的伪元素接口，比如 ::-webkit-media-controls，但这些在 Firefox、Safari 上不生效，且 Chrome 也逐步限制其样式能力。你写 audio { width: 100%; } 可能生效，但想改按钮图标、进度条轨道颜色或隐藏某个控件，基本靠猜——而且一换浏览器就失效。
真正可控的做法是：移除 controls 属性，用纯 HTML + CSS 构建界面，再靠 JS 绑定行为。这不是“多此一举”，而是唯一能跨浏览器一致渲染的方式。
input[type="range"] 进度条和音量条怎么统一适配各浏览器
进度条和音量条本质都是 <input type="range">，但它在不同引擎下默认样式差异极大：Chrome 用 ::-webkit-slider-runnable-track 和 ::-webkit-slider-thumb；Firefox 要用 ::-moz-range-track 和 ::-moz-range-thumb；Safari 对伪元素支持更保守，有时需加 -webkit-appearance: none 才能重置。
- 必须为每个浏览器前缀单独写样式，不能只写一套
- 移动端点击区域要 ≥ 44px，
height或min-height至少设为44px，否则 iOS Safari 点不中 - 拖动时触发
input事件（实时）、change事件（松手后），播放器逻辑里建议监听input做预览，change做最终提交 - 别忘了给
track设background，否则 Safari 下可能显示空白轨道
如何让自定义按钮在播放/暂停状态间正确切换 UI
核心不是“点一下播，再点一下停”，而是依赖 audio.paused 和 audio.ended 的组合判断。刚加载完、播放结束、网络中断都会让 paused 为 true，但语义完全不同。只靠它切按钮文字容易出错。
立即学习“前端免费学习笔记（深入）”；
- 推荐监听
play和pause两个事件来更新 UI，比轮询paused更可靠 - 按钮文本可设为：
btn.textContent = audio.readyState > 0 && !audio.paused ? '暂停' : '播放'，排除未加载完成的情况 - 图标切换优先用
classList.toggle('playing')，CSS 里控制.playing::before { content: '⏸'; }，避免 innerHTML 重绘开销 - 移动端需额外处理
touchstart替代click，否则部分 Android 机型点不动
移动端自动播放失败时，按钮为什么点了也没反应
这不是按钮问题，是浏览器策略拦截。iOS Safari 和新版 Android Chrome 明确要求：首次调用 audio.play() 必须发生在用户手势（click、touchstart、keydown）的同步调用栈内，延迟哪怕 1ms（比如套个 setTimeout）都会被拒绝。
-
audio.play()返回 Promise，必须加.catch(e => console.warn('play failed:', e))，常见错误是DOMException: play() failed because the user didn't interact with the document first. - 不要在
DOMContentLoaded或load里调play()，除非它包在用户事件回调里 - 如果音频是背景音乐，建议初始设
muted+autoplay，用户第一次点击按钮时再audio.muted = false并play()，成功率更高 - 路径错误（404）也会导致
play()Promise 永远 pending，务必检查 Network 面板确认音频资源加载成功
最易被忽略的一点：所有自定义控件的交互状态（如拖动中、播放中、加载中）必须和 audio 元素的真实状态严格同步，不能靠 JS 变量“模拟”。浏览器可能因网络、系统策略或用户操作（如系统静音）悄悄改变媒体状态，只监听 JS 侧逻辑会漏掉关键变化。
