用单个隐藏<audio>实例配合JS动态切换src实现轻量音乐列表，列表项绑定data-src属性，点击时暂停当前、更新源并播放，注意iOS用户手势触发、Promise错误捕获及跨域配置。
怎么用 <audio> 实现可点击播放的音乐列表
直接用原生 <audio> 标签 + JavaScript 控制，比引入第三方库更轻量、更可控。关键不是“放一个播放器”，而是让每首歌都能独立触发、状态可识别。
常见错误是把所有 <audio> 都设成 controls 显示控件，结果页面堆满重复 UI，既难维护又占空间。正确做法是只保留一个隐藏的 <audio> 实例，用 JS 动态切换 src 并控制播放。
- 列表项用
<li>或<button>，绑定data-src和data-title属性存音频路径和标题 - 主
<audio>标签不加controls，设preload="metadata"加速首帧加载 - 点击列表项时：先调用
audio.pause()（避免多首叠加），再赋值audio.src = clickedSrc，最后audio.play() - 注意 iOS Safari 要求首次播放必须由用户手势触发，所以不能在
DOMContentLoaded里自动播
如何让当前播放项高亮并实时更新播放进度
高亮靠 CSS 类切换，进度靠监听 timeupdate 事件 —— 但别每毫秒都更新 DOM，浏览器扛不住。
典型坑是直接在 timeupdate 里频繁操作 innerHTML 或修改 style.left，导致卡顿。应该节流 + 仅更新必要字段。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 给当前播放的列表项加
class="playing"，CSS 里定义背景色或图标变化 - 用
requestAnimationFrame替代setInterval更新进度条，更顺滑 - 进度条
<input type="range">的max值需等loadedmetadata后再设为audio.duration，否则初始为NaN - 拖动进度条时，先
audio.pause()，再设audio.currentTime，最后手动恢复播放（iOS 需再次play()）
Audio API 常见兼容性问题怎么绕过
不是所有格式都能播，也不是所有设备都支持 play() 返回 Promise。最常踩的坑是没处理拒绝状态，导致静音/无声却无报错。
Chrome 70+ 和 Safari 12.1+ 要求 play() 必须返回 Promise 并 catch 错误；旧版 IE 直接不支持 <audio>。务实做法是降级+提示。
- 音频源优先提供
.mp3和.ogg双格式，用<source>标签包裹，浏览器自动选可用的 - 调用
audio.play()后必须.catch(e => console.warn("Playback failed:", e))，尤其注意NotAllowedError（静音策略）和NotSupportedError - 安卓微信内置浏览器对
autoplay极度限制，哪怕加了muted也不行，得明确引导用户点击按钮 - 用
audio.readyState判断是否已加载元数据，避免在duration还是NaN时就设进度条
为什么不用 Web Audio API 做简单播放列表
除非你要做均衡器、音效合成、精确采样分析，否则没必要。它复杂、开销大、还要自己管理音频上下文激活（尤其是移动端的 suspend/resume 策略）。
原生 <audio> 已足够应付“点歌→播放→暂停→切歌”这类场景。硬上 Web Audio 容易卡在 context.resume() 被挂起，或者因跨域资源被静音拦截。
-
Web Audio API适合：可视化频谱、变声、游戏音效混音 -
<audio>适合：播歌单、播 podcast、播背景音效 - 想加淡入淡出？用 CSS transition 控制
volume更简单，而不是接入GainNode - 真要无缝切歌？
<audio>本身不支持，得用两个实例交替，比 Web Audio 的start(when)更难控精度
真正麻烦的是音频文件托管和跨域。如果音频放在不同域名下，记得服务端配好 Access-Control-Allow-Origin，不然 play() 会静默失败，连错误都不抛。
