音频列表需手动构建DOM结构，用存元数据，单个实例配合JS控制播放、高亮与状态同步，避免多实例冲突和自动播放失败。
audio 元素本身不提供列表能力，所有“音乐列表”必须用 <ul></ul>、<ol></ol> 或 <div> 手动构建，再靠 JS 绑定播放逻辑 —— 这是初学者最容易卡住的第一步。
<h3>怎么组织 HTML 音乐列表 DOM 结构</h3>
<p>列表不是靠 <code>audio 标签自动生成的，得自己写容器 + 条目。推荐用语义清晰、便于 JS 选中的结构：
- 外层用
<div id="playlist"> 或 <code><section aria-label="音乐列表"></section>包裹，避免用<ul></ul>单纯为了“看起来像列表”，除非每项确实是独立条目（如歌单目录） - 每首歌用
<div class="track" data-title="晴天">，把关键元数据塞进 <code>data-属性，比藏在文本节点里更可靠 - 播放按钮统一用
<button type="button" class="play-btn"></button>，加type="button"防止表单意外提交 - 不要把
audio标签嵌在每个.track里 —— 多个audio实例会争抢系统音频资源，且无法共享状态（如当前播放项高亮） - 常见错误现象：
audio.play()被多次调用后，部分浏览器（尤其是 iOS Safari）会静音或抛出NotAllowedError: play() failed because the user didn't interact with the document first - 正确做法：只保留一个
<audio id="main-audio"></audio>，所有播放操作都指向它；点击列表项时，先audio.src = newSrc，再audio.load()，最后audio.play() -
audio.load()不可省略 —— 否则换歌后第一次play()可能失败或延迟，尤其在 MP3 文件未完全加载时 - 监听
main-audio的play事件不够 —— 它只告诉你“开始播了”，但不知道播的是哪首；应该在 JS 播放前就标记目标项 - 推荐绑定点击事件到按钮上，而不是整个
.track—— 避免误触（比如点到歌名想复制文字，结果触发播放） - 示例关键片段：
document.querySelectorAll('.play-btn').forEach(btn => { btn.addEventListener('click', () => { const track = btn.closest('.track'); const src = track.dataset.src; const title = track.dataset.title; document.querySelectorAll('.track').forEach(t => t.classList.remove('active')); track.classList.add('active'); audio.src = src; audio.load(); audio.play().catch(e => console.warn('自动播放被阻止:', e)); }); });
为什么不能直接用 controls 属性做列表播放器
浏览器原生 controls 只控制单个 audio 实例，它没有“切换歌曲”“高亮当前项”“记住播放位置”这些能力。一旦你点击第二首歌的播放按钮，第一首不会自动暂停，甚至可能同时发声。
列表项高亮与状态同步怎么做
高亮不是靠 CSS 伪类自动完成的，必须手动管理 DOM 状态。核心逻辑是：播放哪首，就给对应 .track 加 active 类，同时移除其他项的该类。
立即学习“前端免费学习笔记（深入）”；
真正难的不是写出来，而是让列表状态、音频实例状态、UI 视觉反馈三者始终一致 —— 尤其在用户快速连点、切歌中途暂停、页面失焦又恢复时，playing、paused、ended、loadstart 这些事件的时序容易错乱，建议用一个简单状态机变量（如 currentTrackIndex）辅助判断，别全依赖事件回调堆叠。
