本贴原文来自从零开发 Slingerspir：一个纯前端音乐播放器的完整实战记录 – Slingerspir的博客

如果你想访问我的纯前端网页播放器：请访问Slingerspir · 音乐

我一直想做一个属于自己的音乐播放器。市面上的播放器要么功能臃肿，要么UI设计不符合我的审美，更重要的是，我想完全掌控自己的音乐体验。于是我开始着手开发 Slingerspir。

项目背景

我平时听歌主要用 QQ 音乐和网易云，但这两个平台的网页版体验实在一般。QQ 音乐的网页版功能倒是齐全，但页面太花哨，加载一堆用不上的东西；网易云音乐网页版稍好一些，但登录态经常掉，而且界面偏暗偏挤。我想做一个自己用着舒服的播放器，功能不需要多，但核心体验必须流畅：能搜歌、能播、能看歌词、界面干净。

更重要的是，我想借这个机会深入了解几个我之前没碰过的技术领域：Web Audio API 做频谱分析、LRC 歌词的解析与同步滚动、以及如何在一个纯前端项目里优雅地管理状态和性能。

技术选型的思考过程

我一开始想过用 React 或者 Vue 来做，毕竟现在做前端页面基本都用框架。但后来想想，这个播放器不需要复杂的组件通信，也不需要路由、状态管理那些东西，引入框架反而增加加载时间和复杂度。最后我决定用纯原生：HTML + CSS + JavaScript，没有任何框架依赖。这样项目加载快，打开即用，也没有 npm install 的烦恼。

辅助库我只选了必要的：Chart.js 用来画频谱图，QRCode.js 用来生成登录二维码（虽然登录功能最后没用上），CryptoJS 用来处理网易云的加密（虽然最后也没用上）。这些库我都用 CDN 引入，不打包，不改动。

我当时的文件结构很简单：

music-player/
├── index.html # 主页面，所有 DOM 结构
├── style.css # 全部样式
├── script.js # 全部 JavaScript 逻辑
├── proxy.php # PHP 代理，解决 CORS 跨域
├── qq_login.php # QQ 扫码登录（实验性，未完成）
└── README.md # 使用说明

数据源的选择：从绝望到柳暗花明

第一次尝试：直接调用官方 API

我一开始的想法很直接：QQ 音乐和网易云音乐都有网页版，它们的 API 肯定能被调用。我在网上搜了大量资料，发现有人已经分析了网易云音乐的加密机制，核心是 AES 和 RSA 组合加密。

我照着网上的教程，用 CryptoJS 实现了 AES 加密，用 BigInt 做了 RSA 的大数运算。这段代码我写了大概两百行，反复对照网上的实现确保逻辑正确。

// 网易云 AES 加密
function AESEncrypt(text, key, iv) {
    const keyWord = CryptoJS.enc.Utf8.parse(key);
    const ivWord = CryptoJS.enc.Utf8.parse(iv);
    const encrypted = CryptoJS.AES.encrypt(text, keyWord, {
        iv: ivWord,
        mode: CryptoJS.mode.CBC,
        padding: CryptoJS.pad.Pkcs7
    });
    return encrypted.toString();
}

// RSA 加密，用 BigInt 替代 jsbn
function RSAEncrypt(text, exponent, modulus) {
    const reversed = text.split('').reverse().join('');
    const hex = CryptoJS.enc.Hex.stringify(CryptoJS.enc.Utf8.parse(reversed));
    const bigBase = BigInt('0x' + hex);
    const bigExp = BigInt('0x' + exponent);
    const bigMod = BigInt('0x' + modulus);
    const result = bigBase ** bigExp % bigMod;
    return result.toString(16).padStart(256, '0');
}

// 组合加密
function getEncryptedParams(data) {
    const randomStr = generateRandomStr(16);
    const firstEncrypt = AESEncrypt(data, '0CoJUm6Qyw8W8jud', '0102030405060708');
    const params = AESEncrypt(firstEncrypt, randomStr, '0102030405060708');
    const encSecKey = RSAEncrypt(randomStr, '010001', '00e0b509f6259df8642dbc35662901477df22677ec152b5ff68ace615bb7b725152b3ab17a876aea8a5aa76d2e417629ec4ee341f56135fccf695280104e0312ecbda92557c93870114af6c9d05c4f7f0c3685b7a46bee255932575cce10b424d813cfe4875d3e82047b97ddef52741d546b8e289dc6935b3ece0462db0a22b8e7');
    return { params, encSecKey };
}

然后我信心满满地发起请求，结果网易云给我返回了这个：

{
    "code": 8821,
    "message": "请切换其他登录方式或升级新版本再试",
    "redirectUrl": "https://qa-yyy.igame.163.com/anquanhuanjingfengxian"
}

我当时整个人都不好了。加密逻辑没错，参数格式也对着，但就是被风控拦截了。后来我才明白，网易云的风控系统会检查请求的来源、User-Agent、Cookie 完整性等一系列因素，纯前端的请求链太"干净"了，反而被判定为异常。

QQ 音乐那边更直接。我参考了一个开源爬虫项目的实现，用 PHP 代理去请求 ptlogin2.qq.com 获取二维码，结果返回 403 Forbidden。试了各种参数组合，换了不同的 User-Agent，改了 Referer，全部无效。

第二次尝试：MetingAPI 聚合服务

就在我准备放弃的时候，我偶然发现了一个叫 MetingAPI 的聚合服务。这个服务把 QQ 音乐和网易云的接口统一封装了，而且支持 CORS，可以直接从前端调用。

// 加载歌单只需要一个 GET 请求
const API_URL = 'https://meting.mikus.ink/api?server=tencent&type=playlist&id=5264193760';

async function fetchPlaylist() {
    const resp = await fetch(API_URL);
    const data = await resp.json();
    playlist = data.map(item => ({
        title: item.title,
        author: item.author,
        url: item.url,      // 播放链接
        pic: item.pic,      // 封面
        lrc: item.lrc,      // 歌词地址
        id: item.id
    }));
}

用上这个之后，我一下子轻松了很多。不需要管加密，不需要管风控，只需要关心播放器本身的功能。这个决定让我把精力从"怎么拿到数据"转移到了"怎么把播放器做好"上，回头看这是一个很关键的选择。

播放控制：从基础到细节

HTML5 的 audio 标签我之前用过，但只是简单地加在页面上让用户自己控制。这次我要用 JavaScript 完全控制它。

核心代码其实不多，几十行就能搞定基本功能：

const audio = new Audio();
audio.crossOrigin = 'anonymous';  // 这行很重要，不然后面频谱拿不到数据

function playIndex(index) {
    const song = playlist[index];
    audio.src = song.url;
    audio.load();
    audio.play();
}

function togglePlay() {
    audio.paused ? audio.play() : audio.pause();
}

但让进度条顺滑地工作，比我想象的要复杂一些。进度条我用了 div 模拟，这样样式更好控制，也方便拖拽交互。

<div class="progress-track" id="progressTrack">
    <div class="progress-fill" id="progressFill"></div>
</div>

监听 timeupdate 事件来更新进度条宽度，这个很简单。但是拖拽进度条的时候，要处理好鼠标事件和触摸事件，还要在拖拽过程中暂停自动更新，避免两个来源互相干扰。

// 进度更新
audio.addEventListener('timeupdate', () => {
    if (!isDragging) {
        const pct = (audio.currentTime / audio.duration) * 100;
        progressFill.style.width = pct + '%';
    }
});

// 拖拽开始
progressTrack.addEventListener('mousedown', (e) => {
    isDragging = true;
    setProgressFromEvent(e);
});

// 拖拽移动
document.addEventListener('mousemove', (e) => {
    if (isDragging) setProgressFromEvent(e);
});

// 拖拽结束
document.addEventListener('mouseup', () => {
    isDragging = false;
});

这里我同时适配了 touch 事件，让手机也能用。touch 事件的写法跟 mouse 基本一样，只是获取坐标的方式不同。

歌词同步：最花时间的功能

歌词同步看起来简单，实际做起来涉及到解析、渲染、滚动、动画、性能等多个方面，是我在这个项目中花时间最多的部分。

LRC 解析

MetingAPI 返回的歌词是标准的 LRC 格式，每行是 [分钟:秒.毫秒] 歌词内容。我需要解析成结构化数据。

function parseLrc(text) {
    const regex = /\[(\d{2}):(\d{2})\.(\d{2,3})\]/;
    const result = [];
    for (let line of text.split('\n')) {
        const match = line.match(regex);
        if (match) {
            const min = parseInt(match[1]);
            const sec = parseInt(match[2]);
            const ms = parseInt(match[3].padEnd(3, '0'));
            const time = min * 60 + sec + ms / 1000;
            const content = line.replace(regex, '').trim();
            if (content) result.push({ time, text: content });
        }
    }
    return result;
}

解析后的数据结构很简单，就是一个数组，每个元素有 time（秒数）和 text（歌词内容）。

实时高亮与聚焦

高亮当前行很简单：遍历所有歌词行，找到 time 小于等于当前播放时间且最接近的那一行，给它加上 active 类。

困难的是"聚焦"——让当前行始终保持在歌词容器的正中央。我一开始用 scrollIntoView：

activeEl.scrollIntoView({ block: 'center', behavior: 'smooth' });

效果看起来不错，但实际使用中发现两个问题：一是 smooth 动画有时候会卡，特别是在快速切歌的时候；二是频繁调用 scrollIntoView 会导致滚动抖动，视觉上很不舒服。

后来我改用手动计算 scrollTop：

const container = lrcScroll;
const containerHeight = container.clientHeight;
const elOffsetTop = activeEl.offsetTop;
const elHeight = activeEl.offsetHeight;
container.scrollTop = elOffsetTop - containerHeight / 2 + elHeight / 2;

这个公式的意思是：把目标行滚动到容器正中央的位置。计算方式是：目标行的 offsetTop 减去容器高度的一半，再加上行高的一半。这样当前行就精准地居中显示了。

用户滚动与自动聚焦的冲突

用户手动滚动歌词的时候，如果自动聚焦还一直把用户拉回中间，体验会很差。苹果音乐的歌词滚动体验就很自然，用户滚动后不会立刻被拉回去。

我实现了一个 3 秒延迟机制：用户滚动时设置一个标志，自动聚焦暂停；3 秒后如果没有新的滚动操作，恢复自动聚焦。

lrcScroll.addEventListener('scroll', function() {
    if (lrcIsAutoScrolling) return;  // 自动滚动不触发
    
    lrcUserScrolling = true;
    clearTimeout(lrcScrollTimeout);
    lrcScrollTimeout = setTimeout(function() {
        lrcUserScrolling = false;
        // 3 秒后恢复聚焦
        updateLrc(audio.currentTime);
    }, 3000);
});

这里的关键是 lrcIsAutoScrolling 标志，用来区分是用户主动滚动还是程序自动滚动。自动滚动时不应该触发 3 秒延迟逻辑。

DOM 操作优化

歌词更新频率很高，每次 timeupdate 都可能触发。如果每次都操作 DOM，性能开销会很大。我加了一个缓存机制，只有当 activeIndex 发生变化时才更新 DOM：

let lastActiveIndex = -1;

function updateLrc(currentTime) {
    // 计算 activeIndex ...
    if (activeIndex !== lastActiveIndex) {
        lastActiveIndex = activeIndex;
        // 更新 DOM
        lines.forEach((el, idx) => {
            el.classList.toggle('active', idx === activeIndex);
        });
        // 滚动
        if (activeIndex >= 0 && !lrcUserScrolling) {
            // 计算 scrollTop...
        }
    }
}

这个优化看起来简单，效果却很明显。大部分时间 activeIndex 是不变的，所以 DOM 操作几乎不执行，只有换行的时候才触发。

全屏歌词

全屏歌词我用了独立的覆盖层，覆盖在整个页面上。点击歌词右上角的图标进入，按 ESC 或点击关闭按钮退出。

全屏歌词的挑战在于性能。如果歌词很长（比如一首歌有几十行），全部渲染成 DOM 节点会导致滚动卡顿，特别是在 4K 屏幕上。

我的解决方案是只渲染当前行前后各 10 行，其他行用占位符保持高度：

const FS_RENDER_RANGE = 10;

function renderFullscreenLrc() {
    const activeIdx = fsLastActiveIndex >= 0 ? fsLastActiveIndex : 0;
    const start = Math.max(0, activeIdx - FS_RENDER_RANGE);
    const end = Math.min(total, activeIdx + FS_RENDER_RANGE + 1);
    
    let html = '';
    for (let i = 0; i < total; i++) {
        const line = currentLyrics[i];
        if (i >= start && i < end) {
            html += `<div class="fs-line" data-time="${line.time}">${line.text}</div>`;
        } else {
            html += `<div class="fs-line" data-time="${line.time}" style="visibility:hidden;">${line.text}</div>`;
        }
    }
    fsContent.innerHTML = html;
}

超出范围的行用 visibility:hidden 隐藏但保留位置，这样滚动条的总高度是对的，不会因为渲染少量行而导致滚动条跳动。

全屏模式下，普通歌词的渲染会暂停，避免两个区域同时更新。这个优化进一步降低了 CPU 占用。

频谱可视化

频谱是我觉得最酷的功能。看到声音在屏幕上跳动，感觉播放器一下子就"活"了。

我用了 Chart.js 来做频谱图，用 Web Audio API 来获取音频数据。Web Audio API 需要用户交互后才能激活（浏览器安全策略），所以我在播放按钮点击时才初始化。

function initAudioContext() {
    if (audioCtx) return;
    audioCtx = new AudioContext();
    analyser = audioCtx.createAnalyser();
    analyser.fftSize = 256;
    const source = audioCtx.createMediaElementSource(audio);
    source.connect(analyser);
    analyser.connect(audioCtx.destination);
    dataArray = new Uint8Array(analyser.frequencyBinCount);
    isSpectrumRunning = true;
}

绘制频谱时，我从 analyser 读取频域数据，然后更新 Chart.js 的数据集。

function drawSpectrum() {
    analyser.getByteFrequencyData(dataArray);
    // 下采样到 48 个柱
    const newData = [];
    const step = Math.floor(dataArray.length / 48);
    for (let i = 0; i < 48; i++) {
        let sum = 0;
        for (let j = 0; j < step; j++) {
            sum += dataArray[i * step + j] || 0;
        }
        newData.push(sum / step);
    }
    spectrumChart.data.datasets[0].data = newData;
    spectrumChart.update('none');
    requestAnimationFrame(drawSpectrum);
}

我做了三种模式：条形、波形和圆形。切换模式时重建 Chart 实例，调整 type 和样式参数。

性能优化

合并 RAF 循环

最初的代码中，歌词更新、频谱绘制和全屏歌词更新各自用独立的 requestAnimationFrame 循环。这意味着每一帧有三个回调函数在执行，增加了主线程的负担。

我把它们合并成一个统一的循环，一次帧刷新处理所有任务：

function mainLoop() {
    const isFullscreen = fsOverlay && fsOverlay.classList.contains('active');
    
    // 频谱更新
    if (isSpectrumRunning && analyser) {
        analyser.getByteFrequencyData(dataArray);
        updateSpectrumChart(dataArray);
    }
    
    // 普通歌词 - 全屏时暂停
    if (!isFullscreen && lrcLoaded) {
        updateLrc(audio.currentTime);
    }
    
    // 全屏歌词
    if (isFullscreen) {
        updateFullscreenLrc(audio.currentTime);
        updateFullscreenProgress();
    }
    
    requestAnimationFrame(mainLoop);
}

合并后 CPU 占用从 15% 降到了 8% 左右，在 4K 屏幕上全屏歌词的帧率也从 30fps 提升到了稳定 60fps。

降低更新频率

歌词更新不需要每帧都执行，人眼在 100-150 毫秒的间隔下已经感觉足够流畅。我把普通歌词的更新频率降到了 150 毫秒，全屏歌词降到了 100 毫秒。

减少 DOM 操作

除了前面提到的 activeIndex 缓存，我还注意避免在循环中反复查询 DOM。比如在 updateLrc 中，一开始就把所有歌词行缓存到一个变量里，而不是每次都用 querySelectorAll。

UI 设计

液态玻璃效果

我想要 iOS 风格的液态玻璃效果，用 CSS 的 backdrop-filter 实现。核心是背景模糊加半透明叠加：

.glass-player {
    background: rgba(255, 255, 255, 0.25);
    backdrop-filter: blur(32px) saturate(180%);
    -webkit-backdrop-filter: blur(32px) saturate(180%);
    border: 1px solid rgba(255, 255, 255, 0.12);
    border-radius: 48px;
    box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.15), 
                0 30px 60px -20px rgba(0, 0, 0, 0.6);
}

这个效果在浅色和深色模式下都适用，只需要调整背景和边框的透明度。

对比度的反复调整

我一开始在浅色模式下用了半透明的浅色文字，结果在浅色背景下几乎看不清。后来我把浅色模式的主文字改为深色 #1a1410，深色模式改为浅色 #f5f0eb，并确保所有文字的透明度不低于 50%。这个改动看似简单，但视觉上提升很大。

布局演进

最初的布局是上下结构，播放器在上面，歌词和列表在下面。后来我发现这样在宽屏显示器上利用率不高，就改成了三栏布局：左栏播放器（固定宽度 240px），中栏歌词（自适应），右栏列表（固定宽度 260px）。

移动端则自动切换为上下排列，所有控件堆叠在一起。CSS 用了 media query 来实现响应式。

设置面板

设置面板是我后期加的功能，把之前零散的控制项统一整理到一个地方。包含五个区域：

外观设置：主题切换（浅色/深色/跟随系统），歌词字体大小和行距调节。

播放设置：自动播放开关，播放模式（列表循环/单曲循环/随机），默认音量。

歌词设置：实时聚焦开关，翻译显示开关（预留）。

账号管理：网易云和 QQ 音乐的 Cookie 输入和状态显示。

性能与高级：频谱显示开关，频谱柱数调节，渲染帧率选择，歌单封面开关。

所有设置都保存在 localStorage 中，刷新页面后自动恢复。

// 保存设置
function applySettings() {
    const theme = document.querySelector('.settings-toggle-btn.active[data-theme]')?.dataset.theme;
    if (theme) {
        localStorage.setItem('slingerspir-theme', theme);
        // 应用主题...
    }
    const fontSize = document.getElementById('lrcFontSize').value;
    localStorage.setItem('slingerspir-font-size', fontSize);
    // 应用字体大小...
    // ... 更多设置
}

登录功能

登录功能是我尝试了但最终没有完全实现的部分。我花了很多时间在网易云和 QQ 音乐的扫码登录上，但最终被风控拦住了。

网易云扫码登录：我试了 apis.netstart.cn 的接口，二维码能获取到，但 /login/qr/check 接口返回 404。换用官方 weapi 接口后，又遇到了 8821 风控错误。

QQ 音乐扫码登录：ptlogin2.qq.com 接口需要计算 ptqrtoken 和传递 login_sig，我参考开源项目实现了 hash33 算法，但最终请求返回 403。

我最终采用手动 Cookie 输入的方式。用户从浏览器开发者工具复制 Cookie 后粘贴保存，播放器用这个 Cookie 去请求用户歌单。虽然不够自动化，但稳定可靠，而且对用户来说操作也不算复杂。

踩坑记录

坑一：CORS 跨域

在本地 file:// 协议下打开页面时，所有请求都被浏览器拦截。控制台显示 No Access-Control-Allow-Origin header is present。

我一开始以为换一个 CDN 地址就能解决，试了好几个都不行。后来才意识到这不是资源加载的问题，而是 AJAX 请求的跨域问题。解决方案有两个：用 VS Code 的 Live Server 在 http://localhost 下打开，或者用 PHP 代理转发请求。

我两个方案都保留了，日常开发用 Live Server，部署时用 PHP 代理。

坑二：网易云 8821 风控

我搞了一周的 AES/RSA 加密实现，结果被风控拦住。当时非常挫败，但后来了解到这是正常现象。网易云的风控系统会检查请求来源、User-Agent、Cookie 完整性等多个维度，纯前端请求被拦截是常态。

坑三：歌词滚动抖动

用 scrollIntoView 导致频繁调用时滚动抖动。改用手动计算 scrollTop 解决。

坑四：封面图片撑大布局

某首歌曲的封面是 2000x2000 像素，导致播放器被撑大。用 CSS 限制 max-width 和 max-height 解决。

.cover-wrap {
    max-width: 300px;
    max-height: 300px;
}

坑五：AudioContext 被挂起

一开始频谱数据全是 0，调试了半天才发现是 AudioContext 被浏览器挂起了。浏览器要求 AudioContext 必须在用户手势（如点击）后创建，否则会处于 suspended 状态。我在播放按钮点击时才初始化 AudioContext，并在创建后调用 resume 方法。

最终成果

经过多轮迭代，Slingerspir 实现了以下功能：

歌单加载：支持 QQ 音乐和网易云，通过歌单 ID 加载。

播放控制：播放/暂停、上一首/下一首、进度拖拽、倍速调节（0.5x-2.0x）。

歌词同步：LRC 解析、实时高亮、自动聚焦居中、用户滚动暂停聚焦。

全屏歌词：独立覆盖层、只渲染可见区域、ESC 退出。

频谱可视化：三种模式（条形/波形/圆形）、实时更新。

UI：液态玻璃效果、深色/浅色主题、三栏布局、移动端适配。

下载功能：下载当前歌曲、歌词文件、封面图片。

本地存储：主题、播放模式、音量、播放进度、当前歌曲索引、歌单 ID。

播放器已经部署在线上，可以直接访问使用。

未完成的功能

歌词动态模糊效果：我研究了 Apple Music 的实现方式，核心是用 clip-path 遮罩实现逐字高亮。但尝试后放弃了，因为性能开销过大且实现复杂。逐字高亮需要把每行歌词拆分成词语数组，然后逐个控制遮罩位置，对 CPU 消耗很大。

扫码登录：网易云和 QQ 音乐的扫码登录都因为风控原因未能实现，改为手动 Cookie 输入。

歌词翻译：预留了开关但功能未实现。

经验总结

回顾整个项目，有几个决策是正确的：

选择 MetingAPI 而非直接调用官方 API，避免了加密和风控的复杂问题。如果当时死磕官方 API，可能现在还在跟加密算法较劲。

合并多个 RAF 循环，从架构层面优化性能，比在细节上抠代码有效得多。

全屏歌词只渲染可见区域，这个策略让 4K 屏幕上的流畅度大幅提升。

手动 Cookie 登录虽然不够自动化，但稳定可靠，且用户操作成本并不高。

如果将来有时间继续迭代，我会优先做这几件事：增加均衡器等音频处理功能；增加 PWA 支持让用户离线使用；如果有后端支持，实现真正的扫码登录。

给其他开发者的建议是：别在纯前端上死磕官方 API 登录，风控机制不是那么容易绕过的；性能优化要从架构层面考虑，不要在细节上过度优化；第三方 API 要做好随时失效的准备，设计好降级方案。

感谢阅读我的开发记录，希望对你有所帮助。