最近后台总有人问我，说想做一个好看的 HTML 音乐播放器，但一搜教程要么是套现成框架，要么就是工程化配置把人劝退。其实用最基础的 html + css + js 三件套，完全能写出一款界面不糊、功能完整的音乐播放器，整个源码整理下来也就三个文件。这篇文章我会把从设计思路到落地实现的过程完整拆开讲一遍，核心源码直接贴在对应章节里。不管你是刚学前端想找个练手项目，还是学校课设需要交一个小作品，或者单纯想给自己的个人主页加一个播放器，都可以照着做。

这个项目不依赖任何第三方库，不用安装 Node 环境，不用拉脚手架，浏览器打开就能跑，理解起来几乎没有门槛。麻雀虽小五脏俱全——播放、暂停、切歌、进度条拖拽、封面旋转动画、歌词同步，该有的交互一个不少。我一直推荐新手拿它练手，是因为这些功能背后覆盖了 DOM 操作、事件监听、CSS 动画、音频对象、异步加载这些知识点，把这套流程走通，前端入门阶段的基础闭环基本也就建立起来了。

1. 先别急着写代码：把这个播放器拆成三块

写任何前端项目之前，我习惯先把拆解做扎实，这样后面填代码的时候不会东一榔头西一棒子。一个音乐播放器从用户能感知的层面看，无非是三块：看得见的界面、听得见的音频、以及两者之间的交互逻辑。落到代码上就是结构、样式、行为三分。

1.1 为什么选原生三件套，不碰框架

现在的开源播放器方案一大把，很多甚至封装好了炫酷的 UI 组件，拖进来就能用。但这类方案最大的问题是：出问题了你很难定位。音频上下文、生命周期钩子、状态管理这些抽象概念叠加在一起，新手一旦遇到诡异 bug，基本只能靠猜。

原生 HTML/CSS/JS 的好处恰恰是直白。你写的<audio>标签是浏览器原生能力，点击按钮触发的事件也一眼能看到，没有中间层，调试起来就是 F12 打断点、看 Network、看 Console，逻辑链路非常清楚。我常跟朋友说，框架是帮你盖楼用的脚手架，但前提是你得知道墙是怎么砌的。先用原生写一个播放器，将来你再去看 Vue 或 React 封装好的音频组件，会瞬间明白那些属性到底在干什么。

另外还有一个很实际的原因：体积和部署成本。这个播放器整包不过几 KB，随便扔到任意静态服务器就能跑，不需要 node_modules 塞满几百兆。对做个人网站、写课程设计、给公司内部工具加个小功能这类场景来说，原生方案就是最省心的选择。

1.2 先把功能边界定死：哪些做，哪些先不做

很多初学者写项目容易犯一个毛病：打开编辑器就想把脑子里所有功能全塞进去，结果写了一半发现驾驭不住，最后烂尾。我的建议是先割一刀，把“必做”和“暂不做”分清楚。

这个表落实下来，项目复杂度一下就收敛了。我们不需要考虑数据接口，音频文件直接用本地相对路径，歌词用 LRC 文本格式做成字符串数组，所有数据都可以硬编码在一个 JS 文件里。这样新手不用接触后端，也能把前端交互练得明明白白。

2. 好看的界面怎么做：落笔前先想清楚视觉稿

很多教程上来就贴 CSS，看的时候感觉自己会了，关掉页面自己写还是只会白底黑字。问题出在缺少“设计前置”这一步。播放器好不好看，跟你会不会写复杂样式关系不大，关键在于你在写代码之前有没有把视觉基调定清楚。

2.1 暗色玻璃拟态：零基础也能做出高级感的设计路线

我见过太多新手一上来就整高饱和渐变背景、大紫大蓝，结果页面像沐浴在霓虹灯里，看三秒眼睛就酸。通常对“好看”判断最稳妥的方案，是暗色底 + 毛玻璃卡片 + 单一强调色。

暗色底的好处是能压住整个页面的躁气，同时让封面图变成视觉焦点。毛玻璃效果用 CSS 的backdrop-filter: blur()就能实现，成本极低，但质感提升非常明显。强调色选一个，比如低饱和度的蓝紫色，其余文字、图标、辅助信息都用中性灰去搭配，整体就会显得干净、高级。

这一套组合拳在日常网页设计中被反复使用，因为它确实对新手友好：暗色遮噪，模糊显质感，强调色点睛。哪怕你的审美积累不够，只要守住这个原则，做出来的东西也很难翻车。

2.2 配色、圆角、阴影的取值心得

我为了省事，会把视觉参数抽成 CSS 变量，也就是:root里的一组自定义属性。这样后期改主题，只要改几个变量值就行，不用满文件找颜色。

:root { --bg: #12121a; --card-bg: rgba(30, 30, 46, 0.82); --primary: #6c8cff; --text-main: #e8e8f0; --text-sub: #9a9ab0; --radius-lg: 20px; --radius-md: 14px; --shadow: 0 12px 40px rgba(0, 0, 0, 0.45); }

几个取值背后都有逻辑在：背景#12121a是带一点蓝味的极深灰，比纯黑柔和，比纯白耐看；强调色#6c8cff属于蓝紫象限，在暗底上既明亮又不会刺眼；圆角用 20px 和 14px 两档，大圆角给外层卡片，小圆角给内部按钮，层次很自然。阴影我用大模糊低透明度的组合，而不是生硬的实边投影，这样卡片看起来是“浮”在背景上的。

整个界面布局采用典型的垂直居中卡片结构，卡片内部从上到下依次是封面区、歌名歌手区、进度条区、控制按钮区、歌词区。这个顺序符合用户操作直觉：先看听的是什么，再操作进度，最后看歌词。

3. HTML 结构：把骨架搭结实

HTML 是整栋房子的承重墙。很多新人写播放器，喜欢用一大堆嵌套的<div>硬堆，最后类名混乱、结构难调。我的习惯是先定义清晰的语义，让代码的层级能直接对上视觉层级。

3.1 播放器主体 DOM 按模块划分

代码结构上，我按“背景层、封面、信息、进度、控制、歌词”这几个模块来组织，每个模块用 class 清晰命名。以下是一个可以直接复制修改的 HTML 骨架：

<div class="player" id="player"> <div class="player-bg" id="playerBg"></div> <div class="disc-wrap"> <img class="disc-cover" id="cover" src="./music/cover1.jpg" alt="歌曲封面" /> </div> <div class="info"> <h2 id="songName">歌名占位</h2> <p id="singer">歌手占位</p> </div> <div class="progress"> <span id="currentTime">00:00</span> <input type="range" id="progressBar" min="0" max="100" value="0" /> <span id="duration">00:00</span> </div> <div class="controls"> <button id="prevBtn" class="btn" type="button">上一首</button> <button id="playBtn" class="btn btn-play" type="button">播放</button> <button id="nextBtn" class="btn" type="button">下一首</button> </div> <div class="lyric-box" id="lyricBox"> <p class="lyric-line active">歌词加载中...</p> </div> </div>

这里有几个容易忽略的细节值得多说一句。按钮我强制加了type="button"，因为一旦这个结构被误放进某个<form>里，默认的submit行为会导致页面刷新，明明能播的歌突然中断，排查起来还很隐蔽。封面图我直接放在disc-wrap里，后面做旋转动画时就只动这个容器，避免影响周围布局。

3.2 这套结构的语义逻辑是什么

几个主要 class 我会在样式阶段频繁引用，所以命名尽量简短且可读。player是整个卡片容器，负责宽高、圆角、阴影；disc-wrap是封面旋转的“转盘”；controls是按钮组容器，用 flex 布局排成一行；lyric-box是歌词区，默认固定高度，歌词超额时内部滚动。

HTML 的作用是先把内容语义固定下来，后面 CSS 才能谈得上“好不好看”。如果你在写结构的时候就已经焦虑布局，那会非常痛苦。正确的顺序是：先确认元素之间是父子还是兄弟关系，再确认哪些部分会跟着交互状态变化——比如封面旋转时，只有disc-wrap需要加上动画 class；播放按钮文字切换时，只有playBtn的文本需要变化。这就像画素描先打形，形不准，后面再多装饰都是浪费。

4. CSS 样式：从“能看”到“好看”的关键细节

骨架有了，接下来是大家蕞关心的样式部分。我见过很多提前写了大量 CSS 的同学，最终布局还是乱成一团，原因多半是没掌握好“让浏览器自动完成布局”的基本功。别急着写炫技代码，先把布局的关键点理顺。

4.1 布局上的三个关键思路

第一，垂直水平居中。整个页面我只用一个body的 flex 就能搞定，不需要手动算 margin。第二，卡片内部也用 flex 纵向排列，让各区块之间有稳定的间距。第三，封面用宽高一致的盒子，通过object-fit: cover保证图片不变形。

* { margin: 0; padding: 0; box-sizing: border-box; } body { min-height: 100vh; display: flex; align-items: center; justify-content: center; background: var(--bg); font-family: "PingFang SC", "Microsoft YaHei", sans-serif; } .player { width: 360px; padding: 28px 24px 32px; background: var(--card-bg); border-radius: var(--radius-lg); box-shadow: var(--shadow); backdrop-filter: blur(16px); display: flex; flex-direction: column; align-items: center; } .disc-wrap { width: 220px; height: 220px; border-radius: 50%; overflow: hidden; border: 6px solid rgba(255, 255, 255, 0.12); box-shadow: 0 8px 30px rgba(0, 0, 0, 0.4); } .disc-cover { width: 100%; height: 100%; object-fit: cover; }

disc-wrap设置成圆形并裁剪掉图片溢出部分，就得到了圆形唱片效果。加一圈半透明border是为了模拟黑胶唱片的边缘质感，细看会比直角图片精致很多。

4.2 封面旋转动画、进度条和按钮的精细打磨

旋转动画看起来很高端，其实就是几行 CSS。我用.disc-wrap.playing这个组合选择器控制动画状态，播放时旋转，暂停时停住。动画本身用rotate，不会触发重排，性能开销小得可以忽略。

@keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } } .disc-wrap.playing { animation: spin 20s linear infinite; }

进度条我建议直接用input[type="range"]改装，而不是自己造一套 div 模拟。原生 range 在触屏和键盘操作上都有内置支持，省掉大量边界判断。只需要把默认外观清掉，再画出轨道和滑块：

#progressBar { -webkit-appearance: none; appearance: none; width: 100%; height: 6px; border-radius: 3px; background: linear-gradient(to right, var(--primary) 0%, var(--primary) var(--progress, 0%), #3a3a4a var(--progress, 0%)); outline: none; } #progressBar::-webkit-slider-thumb { -webkit-appearance: none; width: 14px; height: 14px; border-radius: 50%; background: var(--primary); cursor: pointer; border: 2px solid #fff; } #progressBar::-moz-range-thumb { width: 12px; height: 12px; border-radius: 50%; background: var(--primary); cursor: pointer; }

这里我会用 CSS 变量--progress实时更新已播放比例，肉眼看起来就像是进度条被填充了一段颜色，不需要 JS 去改 DOM 背景，性能上更干净。滑块做成了圆形强调色，配白边，拖拽时焦点明确。

按钮模块我统一做成圆形图标按钮，主播放按钮稍大，营造“视觉重心”。hover 时加一点位移，按下时缩小，交互反馈越明确，越让人觉得这个播放器“活”的。

.controls { display: flex; align-items: center; gap: 18px; margin-top: 16px; } .btn { width: 42px; height: 42px; border: none; border-radius: 50%; background: rgba(255, 255, 255, 0.08); color: var(--text-main); font-size: 14px; cursor: pointer; transition: transform 0.15s ease, background 0.2s ease; } .btn:hover { background: rgba(255, 255, 255, 0.16); transform: translateY(-2px); } .btn:active { transform: scale(0.94); } .btn-play { width: 56px; height: 56px; background: var(--primary); color: #fff; font-weight: 600; }

4.3 移动端适配和兼容性别忽略

虽然这个播放器定位是网页小工具，但很可能有人用手机浏览器打开。我至少会保证卡片宽度不超过屏幕，间距合理。这里用max-width: 92vw和min()函数就能轻松适配：

.player { width: min(360px, 92vw); }

对于backdrop-filter，如果遇到老浏览器不支持，会直接显示为rgba底色，并不影响使用，属于渐进增强。进度条滑块部分，WebKit 和 Firefox 的前缀写法要写全，否则一个浏览器能拖，另一个浏览器拖不动，这种问题特别容易被忽略。

歌词区也需要一点样式，我给每个歌词行设了过渡动画，切换高亮时不会生硬跳变。歌词行被高亮的那个，我会加亮文本颜色、放大字号，其余行用灰暗色弱化。这样用户视线能瞬间锁定当前唱到的那句。

5. JavaScript 交互：播放、切歌、进度与歌词同步

HTML 和 CSS 让播放器看起来像一个播放器，但真正跑起来靠的是 JS。这个阶段最容易出问题的是事件顺序和状态同步，我下面按功能模块讲清楚。

5.1 初始化：用播放列表数据驱动一切

我用一个playList数组保存所有歌曲信息，初始下标为 0。页面上所有状态都从这份数据推导，维护起来只需要往数组里加对象，不需要改 HTML。

const playList = [ { title: '夜航星', singer: '示例歌手', cover: './music/cover1.jpg', src: './music/song1.mp3', lrc: `[00:12.50]第一句歌词 [00:18.10]第二句歌词 [00:25.60]副歌部分的第一句` }, { title: '远山', singer: '示例歌手', cover: './music/cover2.jpg', src: './music/song2.mp3', lrc: `[00:05.20]另一首歌的第一句` } ]; const audio = new Audio(); let currentIndex = 0; let isPlaying = false; let isDragging = false; let lyricData = [];

页面加载时调用loadSong(0)，把第一首歌的信息填充到 DOM 中，同时解析歌词。

function loadSong(index) { const song = playList[index]; currentIndex = index; document.getElementById('songName').textContent = song.title; document.getElementById('singer').textContent = song.singer; document.getElementById('cover').src = song.cover; audio.src = song.src; lyricData = parseLrc(song.lrc); renderLyric(lyricData); }

注意我创建音频对象用的是new Audio()，而不是在 HTML 里写死<audio>标签。这样做的好处是音频对象完全受 JS 控制，不需要在 DOM 里隐藏一个播放器元素。

5.2 播放、暂停与切歌：统一走一条更新逻辑

播放按钮的点击事件里，我不建议写一堆if else去判断当前状态，而是让逻辑保持线性：读当前状态，取反，然后调用对应方法。

playBtn.addEventListener('click', () => { if (audio.paused) { audio.play(); isPlaying = true; playBtn.textContent = '暂停'; coverWrap.classList.add('playing'); } else { audio.pause(); isPlaying = false; playBtn.textContent = '播放'; coverWrap.classList.remove('playing'); } });

切歌更简单，上一首和下一首本质都是修改currentIndex然后重新加载。唯一的坑是边界处理，第一首歌再点上一首，要能跳转到最后一首；最后一首歌点下一首，也能回到第一首。这种循环切歌是音乐类产品很常见的交互习惯。

function prevSong() { currentIndex = (currentIndex - 1 + playList.length) % playList.length; loadSong(currentIndex); if (isPlaying) { audio.play(); } } function nextSong() { currentIndex = (currentIndex + 1) % playList.length; loadSong(currentIndex); if (isPlaying) { audio.play(); } }

注意prevSong里的(currentIndex - 1 + playList.length) % playList.length写法，可以避免负索引，是循环列表标准解法。如果漏掉+ playList.length，第一首切上一首时会得到 -1，所有读取都会出错。

还有一个很多新手会犯的错：切换歌曲后忘记调用audio.play()，结果界面显示在播放，实际没有声音。解决思路是：切歌后，如果之前是播放状态，就立即继续播放。上面代码里已经体现。

5.3 进度条拖动：事件顺序是个大坑

进度条涉及两个方向的数据同步：音频播放时，timeupdate事件不断更新进度条的显示值；用户拖动进度条时，要把当前拖到的位置写回audio.currentTime。如果两个方向同时操作，就会产生跳变冲突。我的处理方式是加一个isDragging开关作为互斥锁。

audio.addEventListener('timeupdate', () => { if (isDragging) return; const duration = audio.duration; if (Number.isFinite(duration) && duration > 0) { const percent = (audio.currentTime / duration) * 100; progressBar.value = percent; progressBar.style.setProperty('--progress', percent + '%'); document.getElementById('currentTime').textContent = formatTime(audio.currentTime); document.getElementById('duration').textContent = formatTime(duration); } }); progressBar.addEventListener('input', () => { isDragging = true; const percent = parseFloat(progressBar.value); progressBar.style.setProperty('--progress', percent + '%'); document.getElementById('currentTime').textContent = formatTime(percent / 100 * audio.duration); }); progressBar.addEventListener('change', () => { if (Number.isFinite(audio.duration)) { audio.currentTime = parseFloat(progressBar.value) / 100 * audio.duration; } isDragging = false; });

这里我特意用了input和change两个事件，而不是都放在一个事件里。input在拖动过程中高频触发，适合实时更新 UI；change在松手时触发，适合真正写入播放进度。两者配合，就不会出现拖一下卡一下的问题。时间格式化函数也很简单，但必须做。

function formatTime(seconds) { if (!Number.isFinite(seconds)) return '00:00'; const m = Math.floor(seconds / 60); const s = Math.floor(seconds % 60); return `${String(m).padStart(2, '0')}:${String(s).padStart(2, '0')}`; }

5.4 歌词同步：LRC 文本的解析高亮实现

歌词同步是好多人的执念，热搜里也一直有人问“h5 音乐播放器歌词同步怎么弄”。其实原理透彻了非常简单：LRC 歌词的每一行都带时间戳，我把它解析成{ time: 秒, text: 歌词 }的数组，然后在timeupdate里找“当前时间之前最近的一条”作为高亮行。

解析函数看起来复杂，核心就是一条正则。时间戳格式通常是[分:秒.毫秒]，正则需要把分、秒、毫秒分别捕获出来再转换成秒数。

function parseLrc(lrcText) { const lineList = []; const lines = lrcText.split('\n'); const timeReg = /\[(\d{2}):(\d{2})(?:\.(\d{2,3}))?\]/g; for (const line of lines) { let match; while ((match = timeReg.exec(line)) !== null) { const minute = parseInt(match[1], 10); const second = parseInt(match[2], 10); const ms = match[3] ? parseInt(match[3].padEnd(3, '0'), 10) : 0; const time = minute * 60 + second + ms / 1000; const text = line.replace(timeReg, '').trim(); if (text) { lineList.push({ time, text }); } } } return lineList.sort((a, b) => a.time - b.time); }

注意排序那一步不能省，因为有些 LRC 文件里时间戳顺序是乱的，不排序的话高亮逻辑会出错。

渲染歌词时，我建议只渲染当前这首歌词的前后若干行，而不是一次性渲染几百行 DOM。一次性渲染不仅浪费性能，歌词滚动时还会卡顿。简单处理就是只渲染歌词数组的全部行也问题不大，但如果歌词有几百行，性能会开始吃紧。我给歌词容器设置了固定高度和overflow-y: auto，每次高亮到某一行时，用scrollIntoView({ block: 'center' })把当前行滚到中间，这样沉浸感很强。

function renderLyric(lyricList) { const box = document.getElementById('lyricBox'); box.innerHTML = ''; if (!lyricList.length) { box.innerHTML = '<p class="lyric-line active">暂无歌词</p>'; return; } lyricList.forEach((line, index) => { const p = document.createElement('p'); p.className = 'lyric-line'; p.dataset.index = index; p.textContent = line.text; box.appendChild(p); }); }

timeupdate里高亮对比我用了一个简单指针，避免每次从头遍历全部歌词。当前播放时间只可能往前进，所以用一个lyricIndex标记上次高亮到的位置，从那里继续向后找，直到找不到currentTime >= item.time为止。这样一秒钟播放触发几十次回调也不会有压力。

6. 源码结构、本地运行与后续扩展

代码都拆完了，再聊聊整个项目的文件组织方式。很多初学者把 html、css、js 全写在一个文件里，方便是方便，但一旦要加功能或者排查问题，几百行代码堆在一起非常痛苦。我通常一开始就分成三个文件，成本不高，收益却很大。

6.1 文件目录这样建最干净

我用下面的目录结构：

music-player/ ├── index.html ├── css/ │ └── style.css ├── js/ │ └── player.js └── music/ ├── cover1.jpg ├── cover2.jpg ├── song1.mp3 └── song2.mp3

index.html里通过<link rel="stylesheet" href="css/style.css">和<script src="js/player.js" defer></script>引入资源。注意script标签加了defer，这样 JS 会在 DOM 解析完之后再执行，不需要担心拿不到按钮节点。如果不用defer又放在<head>里，执行时会因为找不到 DOM 元素而报null错误。

音频文件和封面图统一放在music目录下，路径管理很清爽。如果你想先测试，也可以把歌曲文件换成网络上任意可访问的 mp3 链接，但要注意浏览器对跨域资源的限制，本地开发建议还是用本地文件，省得被 CORS 拦一道还莫名其妙。

6.2 本地运行的正确姿势

很多人以为双击index.html就能跑，这句话在只有纯静态 HTML 时对，但有音频资源时未必。双击打开是file://协议，部分浏览器对这个协议下的资源加载限制比较严，特别是某些版本的 Chrome 或者 Firefox，会导致音乐加载不出来。

最稳的做法是起一个本地静态服务器。在项目根目录打开终端，如果你有 Python，执行python -m http.server 8000；如果你用的是 VS Code，装个 Live Server 插件，右键index.html选 Open with Live Server，也很方便。然后访问http://localhost:8000就能看到播放器了。这个习惯建议养成，将来写任何纯前端项目都用得上。

6.3 这个播放器再往后还能加什么

如果基础版你已经跑通了，接下来扩展方向我给几个建议，按难度递增排序。

第一，加播放列表。把歌曲管理的playList数组渲染成列表，支持点击切换，再补一个随机播放模式，逻辑不复杂，但很锻炼数组操作能力。第二，把播放进度和音量写进localStorage，下次打开还能接着上次的位置听，涉及存储、读取、容错三块。第三，用 Canvas 实现音频可视化。AudioContext的getByteFrequencyData能取到频谱数据，画成不断跳动的柱子，观感提升非常直接。第四，做迷你悬浮窗模式，点击按钮后播放器缩小成一个固定在角落的小圆盘，这个就要用到position: fixed和状态切换，交互细节很值得练手。

7. 常见问题与排查技巧实录

写这个播放器的过程中，有几个问题我被反复问到，也几乎是我们这类小项目踩坑的重灾区。单独拉一节集中排查，方便你对照解决。

7.1 点击播放没有任何声音

先按顺序检查三件事。打开浏览器 DevTools 的 Console 面板，看有没有红色报错。如果没有，切到 Network 面板，刷新页面看 mp3 请求有没有成功，双击打开页面时音频文件路径要跟目录结构严格对应。如果路径没问题，再看代码里听过audio.src正确赋值，以及audio.play()是否在用户点击事件里调用。浏览器有自动播放策略，没有用户交互直接调用play()会被拒绝，只要点击按钮触发就不会有这个问题。

另外还有一个很隐蔽的点：系统音量、浏览器标签页音量、以及 Mac 上的“单独控制应用音量”，都可能让播放器看起来“没声音”。这种属于环境问题，先开一个网易云网页版对比一下就知道是不是代码问题。

7.2 封面旋转动画不转或时转时停

多半是 class 添加/移除的位置不对。确认你是在播放按钮点击事件里同时操作了音频和封面 class，并且不是在每次timeupdate里反复添加 class，那样动画会被打断。还有一个点：如果disc-wrap上有别的 transform 属性的交互，比如 hover 时盖了一个transform: scale(1.05)，那它会把动画的rotate覆盖掉。解决方式是把动画独立放在一个内层元素上，或者 hover 效果也写成复合transform，不要覆盖原属性。

7.3 歌词高亮总是对不上或闪烁

如果歌词整体时间偏移统一慢半拍，检查是不是解析时毫秒处理出了问题。ss如果写成[00:12.5]这种 1 位毫秒，必须padEnd(3, '0')补成 500 毫秒；如果直接用parseInt('5')当作 5 毫秒，对比时就差了 495 毫秒，视觉上能感觉到偏。如果歌唱过程中歌词闪跳，检查lyricIndex指针是不是被loadSong时重置了，每次切歌都要把高亮行的指针归还给初始位置。还有一个小技巧：timeupdate触发的频率大概每秒 4 次，不需要也不需要处理得太频繁，高亮切换的精度在 100 毫秒级别已经够用。

下面把常见现象、可能原因、解决方案汇总成一张速查表，方便收藏后对照。

最后再分享一个实际排障的小经验。我早期写播放器时，经常碰到“第一次点播放正常，切歌后再播放就废了”的诡异问题，后来发现是audio.src改变后没有等canplay事件就直接play()，音频还没就绪就收到 play 指令，直接抛异常。稳妥做法是在loadSong之后监听canplay，只有音频真正能播了才调play，或者干脆在切歌时先audio.load()再play。这个坑在现代浏览器上可能有兼容性差异，不同版本表现不完全一样，主动规避最保险。

这个播放器项目我回过头来写了几次，每次都能在细节上再抠出一点新东西。有时候是把动画做得更顺滑，有时候是发现一个之前没注意到的浏览器兼容点。如果你只想拿到一段能跑的代码，那今天的核心代码已经足够；如果你想理解背后每一行为什么存在，那建议把这几个章节再读一遍。前端的乐趣就在于，你每深挖一层，就多一层掌控感。