企业官网建设流程全解析

“基于Java的在线音乐播放系统开发”这个选题，算是我见过做的人最多、也最多人做到一半就放弃的项目之一了。原因很简单，单看题目觉得无非是一个播放器页面套一个后台管理，真的动手才发现，文件上传、流式传输、进度拖动、播放队列、移动端适配，环环相扣，哪一环没想清楚都会卡壳。

这篇文章就把我从零搭建这样一个系统的完整过程拆开讲透，包括技术选型背后的理由、数据库怎么设计、核心接口怎么写、部署时有哪些容易被忽略的细节，以及我实际踩过的坑和排查思路。不管你是正在做课程设计的学生，还是想自己搭一个私有音乐库的开发者，只要能跟着把核心逻辑捋顺，就不只是“抄一套代码”，而是真正具备独立实现同类系统的能力。

1. 整体设计与技术选型

1.1 项目要做成什么样

先说清楚目标。这里要做的不是一个简单的本地播放器，而是一个基于B/S架构的在线音乐播放平台，用户通过浏览器就能完成注册、登录、搜索歌曲、创建歌单、在线播放、收藏评论等操作。后台还需要一个管理界面，用来上传歌曲、维护歌手和专辑信息、管理用户状态。

整个系统从功能上可以拆成两大块：面向普通用户的音乐前台，以及面向管理员的运营后台。前台的核心是“找歌”和“听歌”，后台的核心是“传歌”和“管歌”。如果只是为了交作业，做前台就够了；但如果是想当成一个完整作品来打磨，后台管理端反而是体现工程能力的地方。

我见过不少同学一上来就纠结界面好不好看，实际上这类系统最核心的价值在于数据怎么组织、文件怎么存、音频怎么流畅地吐给浏览器。界面是锦上添花，数据流和文件流才是骨架。

1.2 技术栈选型与选择理由

技术选型直接决定开发效率和后续维护成本。我这里用了一套非常主流、资料也丰富的组合，对新手友好，对后续扩展也不至于被框架卡住。

• 后端框架：Spring Boot。理由很直接，它把配置简化到了极致，内嵌Tomcat，打一个jar包就能跑，适合快速搭建RESTful API。项目结构清晰，也方便后续拆微服务。
• 持久层：MyBatis-Plus。选它不是因为MyBatis不好，而是MyBatis-Plus提供了单表CRUD的通用方法，省掉大量重复SQL。多表关联查询依然可以手写XML，两不耽误。
• 数据库：MySQL 8.x。存储用户、歌曲元信息、歌单关系等结构化数据，稳定可靠，生态成熟。
• 缓存：Redis。主要用于热点数据的缓存和在线状态的记录，比如热门歌曲榜单、用户最近播放列表，减少数据库压力。
• 文件存储：本地磁盘加Nginx静态映射，或者MinIO。音频文件体积大，不适合直接怼进数据库。本地文件系统最简单，MinIO则能提供更规范的对象存储接口，二者可以在代码里做一层抽象，切换成本很低。
• 前端：Vue 3 + Element Plus。用现成组件库能快速完成管理界面；用户前台可以自己写播放器UI，配合HTML5 Audio标签播放音频。

选这套组合最大的好处是“下限不低、上限不卡”。每个组件都是一线项目里常用的，你学到的知识不是只在作业里生效，拿到真实工作中依然可复用。

1.3 动手前必须想清楚的三件事

第一件，音频文件怎么存。MP3文件动辄几MB到十几MB，如果走数据库二进制字段，数据库会迅速膨胀，备份和查询都会变慢。正确思路是数据库只存路径和元信息，文件落盘，访问交给静态资源服务器。

第二件，播放请求怎么处理。浏览器直接请求一个MP3地址就能播放，但一旦要做权限控制、播放次数统计、防盗链，就必须通过后端接口做音频流转发。这也是在线音乐系统比较核心的一个点：接口既要能播放，又要支持拖动进度，也就是HTTP Range请求。

第三件，并发场景下数据库会不会被打爆。播放入口如果直接每次都查数据库，在线用户一多就会出问题。需要把热门数据缓存到Redis，并做好接口层的限流兜底。

这三件事在开发前想清楚，后面每一步都会走得很顺。

2. 数据库设计与存储方案

2.1 核心数据表结构拆解

在线音乐系统的表不会特别多，但每张表之间的关系要理清楚。我这里的核心表包括：用户表、歌手表、专辑表、歌曲表、歌单表、歌单歌曲关联表、收藏表、评论表、播放记录表。

用户表主要字段：id、username、password（加密存储）、nickname、avatar、role（区分普通用户和管理员）、status、created_at。

歌手表：id、name、avatar、intro、created_at。

专辑表：id、title、cover_url、singer_id、publish_time、intro。

歌曲表是所有业务的核心，字段相对多一些，至少包含：id、song_name、singer_id、album_id、duration、audio_url、cover_url、lyric_url、play_count、status。duration可以在上传时通过解析音频文件拿到，audio_url存相对路径，不存完整域名，方便换环境迁移。

歌单表和歌单歌曲关联表要特别注意。歌单与歌曲是多对多关系，所以必须拆一张关联表：playlist_song，字段是id、playlist_id、song_id、sort_order。不要把歌曲直接塞在歌单表的一个字段里，那会让后续增删改查都变得非常痛苦。

评论表：id、user_id、song_id、content、parent_id（支持楼中楼）、like_count、created_at。歌曲详情页要展示评论，所以必须对song_id建索引。

播放记录表：id、user_id、song_id、play_time。这张表用于生成“最近播放”和“猜你喜欢”，数据量会比较大，建议按用户维度做定期清理。

下面是建表SQL的关键片段，可以直接套用：

CREATE TABLE `song` ( `id` bigint NOT NULL AUTO_INCREMENT, `song_name` varchar(128) NOT NULL COMMENT '歌曲名称', `singer_id` bigint DEFAULT NULL COMMENT '歌手ID', `album_id` bigint DEFAULT NULL COMMENT '专辑ID', `duration` int DEFAULT NULL COMMENT '时长(秒)', `audio_url` varchar(255) DEFAULT NULL COMMENT '音频文件路径', `cover_url` varchar(255) DEFAULT NULL COMMENT '封面路径', `lyric_url` varchar(255) DEFAULT NULL COMMENT '歌词文件路径', `play_count` int DEFAULT '0' COMMENT '播放次数', `status` tinyint DEFAULT '1' COMMENT '状态 1-上架 0-下架', `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_singer_id` (`singer_id`), KEY `idx_album_id` (`album_id`), KEY `idx_song_name` (`song_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意几个细节：字符集一定要用utf8mb4，别用utf8，否则存emoji和生僻字会出问题。所有关联字段记得建索引，否则歌曲多了之后关联查询会慢到让你怀疑人生。

2.2 文件存储的路径规范与命名规则

文件存储看起来简单，实际上命名不规范会带来大量后续问题。音频文件和封面图建议分开目录存放，比如/audio和/cover，音频按歌手ID分一层子目录，避免单目录文件过多。

文件命名不能用原始文件名，因为用户上传的文件名可能是中文、带空格，甚至包含特殊字符，直接落盘容易引发URL编码问题和服务端解析问题。我的做法是用UUID + 原始扩展名重命名，原文件名只存到数据库的song_name字段里，作为业务展示名称。

// 生成唯一文件名 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String storeName = UUID.randomUUID().toString().replace("-", "") + ext;

还有一个容易踩的坑：封面图和音频的访问URL，在数据库里最好存相对路径，比如/cover/202406/xxx.jpg。这样无论是本机部署、换服务器还是迁移到云存储，只需要改一层映射关系，不用批量刷数据库。

2.3 Redis缓存了哪些数据

不是所有数据都适合缓存，音乐系统里最值得缓存的是三类：

第一类，热门歌曲列表。比如排行榜Top100，这个数据实时变化不大，完全可以缓存10分钟。

第二类，歌曲详情信息。详情页打开频率高，每条歌曲记录几分钟内被读几十次是常态，缓存5分钟能显著降低数据库查询压力。

第三类，验证码和登录Token。这类数据天然带过期时间，用Redis的expire机制管理最方便。

缓存逻辑不要复杂化，优先保证一致性诉求不高的场景。排行榜数据就算滞后几分钟，用户根本感知不到。

3. 核心业务功能与关键代码实现

3.1 注册登录与JWT鉴权设计

登录这块我直接用了JWT方案。用户登录成功后，后端签发一个Token返回给前端，前端存在本地，每次请求带上Authorization请求头，后端通过拦截器校验Token，把用户信息塞到请求上下文里。这样服务端不需要维护Session，天然支持多实例部署。

密码存储一定要用加密算法，绝对不能明文入库。BCrypt是目前比较稳妥的选择，每次哈希结果都不同，还能顺便抵御彩虹表攻击。

// BCrypt加密 String encodedPassword = BCrypt.hashpw(rawPassword, BCrypt.gensalt()); // 校验 boolean matched = BCrypt.checkpw(rawPassword, encodedPassword);

JWT生成代码也需要控制好过期时间。学习项目里常见的问题是Token过期时间设置过长，比如一个月，这会带来安全隐患。合理做法是短Token配合刷新机制，但初学者可以先设置7天，等后续有精力再实现刷新逻辑。

后端拦截器要放行登录、注册、音频流播放这几个接口，其他接口统一校验Token。这里有一个很重要的细节：音频播放接口必须放行，否则前端Audio标签拿不到音频流。但放行意味着任何人都能解析出音频地址，盗链风险很大，后续可以通过防盗链策略再加强。

3.2 歌曲上传与元信息解析

歌曲上传是后台管理的核心功能。前端用multipart/form-data提交文件，同时带上歌曲名、歌手ID、专辑ID等信息。后端除了要把文件落盘，还要顺手解析音频时长，这样前端播放器才能正确显示进度条。

解析音频时长我推荐使用JAudioTagger，它支持MP3、FLAC、OGG等常见格式，能读取歌曲标题、时长、艺术家等元信息。

// 解析MP3时长 File audioFile = new File(storePath); MP3File mp3 = (MP3File) AudioFileIO.read(audioFile); MP3AudioHeader header = mp3.getMP3AudioHeader(); int duration = header.getTrackLength();

上传接口必须做三个限制：文件格式白名单（mp3、flac、wav）、单文件大小上限（建议50MB）、总上传超时时间。否则有人传一个1GB的假音频上来，你的磁盘和带宽都会很尴尬。

后台管理界面上传成功后，需要能立刻在歌曲列表中看到新歌曲并试听。所以上传接口返回的数据结构要完整，除了成功状态，还要返回歌曲ID、音频URL、封面URL、时长等字段，方便前端不做额外请求直接刷新列表。

3.3 音频流式播放接口，支持拖动进度

这一节是整个系统里含金量最高的部分，务必仔细看。

浏览器Audio标签播放音频，默认会发送一个普通的GET请求。但如果用户把进度条拖到第60秒，浏览器会重新发起一个带Range请求头的请求，要求服务器返回从第60秒开始的数据块。如果接口不支持Range，浏览器要么无法拖动，要么只能重新从头加载整首歌。

后端核心代码如下，通过RandomAccessFile按Range读取文件片段并返回：

@GetMapping("/audio/{songId}") public ResponseEntity<Resource> play(@PathVariable Long songId, @RequestHeader(value = "Range", required = false) String range) { Song song = songService.getById(songId); String audioPath = song.getAudioUrl(); File file = new File(basePath + audioPath); if (range == null) { byte[] data = Files.readAllBytes(file.toPath()); return ResponseEntity.ok() .header("Accept-Ranges", "bytes") .contentType(MediaType.parseMediaType("audio/mpeg")) .contentLength(data.length) .body(new ByteArrayResource(data)); } String[] ranges = range.replace("bytes=", "").split("-"); long start = Long.parseLong(ranges[0]); long end = ranges.length > 1 && !ranges[1].isEmpty() ? Long.parseLong(ranges[1]) : file.length() - 1; long length = end - start + 1; try (RandomAccessFile raf = new RandomAccessFile(file, "r")) { raf.seek(start); byte[] data = new byte[(int) length]; raf.read(data); return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT) .header("Accept-Ranges", "bytes") .header("Content-Range", "bytes " + start + "-" + end + "/" + file.length()) .contentLength(length) .contentType(MediaType.parseMediaType("audio/mpeg")) .body(new ByteArrayResource(data)); } catch (IOException e) { return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).build(); } }

注意两个细节：第一，ResponseEntity状态码必须是206，不是200，否则浏览器认为返回的是完整资源，无法续传；第二，必须返回Content-Range头，告诉浏览器当前返回的是哪一段数据，以及文件总大小。

这里我还建议在接口中同步增加播放次数统计。播放一次就加一次计数，但要注意不能每次请求都写数据库，可以把计数先放到Redis里做原子自增，再定时刷回数据库，这个方案对并发压力非常友好。

3.4 搜索功能实现，别只会LIKE查询

搜索是高频操作，很多初学项目的搜索就是一条LIKE '%%'，数据量小的时候没问题，数据量上来之后全表扫描会直接把数据库拖垮。

基础做法是对歌曲名、歌手名分别做模糊查询。但注意，歌手名在song表里只有singer_id，没有冗余歌手名，所以必须关联查询。核心SQL类似这样：

SELECT s.*, si.name AS singer_name FROM song s LEFT JOIN singer si ON s.singer_id = si.id WHERE s.song_name LIKE CONCAT('%', #{keyword}, '%') OR si.name LIKE CONCAT('%', #{keyword}, '%') ORDER BY s.play_count DESC;

这个方案够用，但有两个问题：一是LIKE的%前缀会导致索引失效；二是搜索“一生”不如搜索“一生所爱”得到的结果准。想做得更好，可以引入全文索引。MySQL 8自带的全文检索对中文支持还是不够优雅，更稳妥的方案是引入Elasticsearch，但如果是学习项目，做这个会引入大量额外复杂度。

折中方案是把热搜词缓存到Redis，热门搜索和热门歌曲都用缓存返回，真正落到数据库的模糊查询请求占比会大幅降低。我实际测过，几千首歌的规模下，加上缓存之后的接口响应基本都在100ms以内，不做全文搜索引擎也完全够用。

3.5 歌单管理与播放队列逻辑

歌单就是一张多对多关联表，创建歌单、删除歌单、往歌单里加歌、移除歌，本质都是对playlist_song表的增删改查。真正需要动脑子的是“播放队列”和“播放模式”。

前端播放器的队列和后端没有太大关系，更合理的做法是前端维护一个队列，把当前列表的歌曲ID数组存起来，播完当前歌之后自动播放下一首。后端只需要提供一个“根据歌曲ID批量查详情”的接口，前端一次性拉取队列完整数据即可。

播放模式有三种：顺序播放、单曲循环、随机播放。这些完全可以放在前端处理，不需要后端参与。唯一要注意的是一次性不要选太多歌曲进队列，前端如果塞入几百首歌，内存和交互都会变得笨重，建议队列上限100首。

4. 前端播放体验与接口对接细节

4.1 播放器组件怎么搭

前端用Vue 3的话，播放器组件可以独立封装。底部一个固定的播放条，包含封面、歌曲名、歌手名、播放/暂停按钮、上一首/下一首按钮、进度条、音量控制。

HTML5的Audio标签是播放核心，用JavaScript控制它的play和pause方法，监听timeupdate事件更新进度条。代码如下：

// 播放器核心逻辑 <audio ref="audioRef" :src="currentSongUrl" @timeupdate="onTimeUpdate" @ended="onEnded"></audio> function playSong(song) { currentSong.value = song; nextTick(() => { audioRef.value.src = `/api/audio/${song.id}`; audioRef.value.play(); }); } function onTimeUpdate() { currentTime.value = audioRef.value.currentTime; duration.value = audioRef.value.duration || 0; }

这里有一个经验之谈：切换歌曲时，不要直接修改audio元素的src属性后再调用play，而是先暂停、再换src、再调用load，最后再play。否则在部分浏览器里会出现点击播放无响应，或者音画不同步的问题。

4.2 音频接口跨域问题，提前打好预防针

前后端分离项目下，前端地址是localhost:5173，后端是localhost:8080，跨域问题必然存在。后端需要配置CORS策略。

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

allowedOriginPatterns用虽然是开发期最快的办法，但生产环境建议锁定前端域名。不要用allowedOrigins加配合allowCredentials(true)，那是非法组合，部分浏览器会直接拒绝响应。

还有一类诡异问题：第一次打开页面播放正常，刷新后音频403。这种通常不是CORS配置断了，而是Token过期或拦截器把音频请求挡掉了。排查时优先看浏览器Network面板里音频请求的状态码，是401还是403，定位会快很多。

4.3 封面图加载与歌词同步，体验感的两个细节

封面图加载看似简单，但要注意三件事：图片资源路径要能跨域访问、图片文件格式要统一（优先webp或jpg）、封面尺寸不能太大。后台管理上传封面时，最好限制宽高比和文件大小。

歌词同步是个加分项。标准做法是LRC格式歌词，后端存LRC文件路径，前端解析成时间点和歌词文本的映射数组，在timeupdate事件中判断当前时间落在哪个区间，高亮对应句子。LRC解析代码不算复杂，但要注意编码问题，LRC文件一般是UTF-8，如果读到GBK编码的内容，中文会乱码。

5. 部署架构与性能优化经验

5.1 从本地到服务器的部署步骤

开发环境和生产环境的部署方式差别很大。本地开发时Spring Boot直接跑jar包，Vue用devServer代理请求就够了。真要部署到云服务器，我推荐用Nginx + Spring Boot jar包的方式，简单可靠，不需要搞容器化。

第一步，前端执行npm run build，生成dist目录。第二步，把dist目录上传到服务器，配置Nginx静态文件根目录指向它。第三步，后端执行Maven打包，得到jar包，用nohup启动。第四步，Nginx监听80端口，把/api/前缀的请求反向代理到localhost:8080，把/audio和/cover静态目录直接映射到本地文件路径。

Nginx配置的关键片段：

server { listen 80; server_name yourdomain.com; # 前端页面 root /var/www/music-web/dist; index index.html; # 后端API代理 location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 音频文件直接走静态文件，减小后端压力 location /audio/ { alias /data/music-server/audio/; } # 封面图 location /cover/ { alias /data/music-server/cover/; } }

这里有一个常见错误：Vue Router使用history模式后，用户刷新非首页路径会出现404。解决办法是在Nginx配置中加上try_files $uri $uri/ /index.html。不处理这个，前端路由一刷新就白屏，这是部署里最容易被忽略的坑。

5.2 高并发读场景下的缓存与保护

音乐系统的读请求远多于写请求，优化思路很明确：尽可能在离用户近的地方返回数据。

第一层是Nginx静态资源缓存，封面图、音频文件这类不经常变化的文件，可以配置expires指令，让浏览器强缓存。

第二层是Redis缓存，热点歌曲详情、排行榜、热搜词都放进去。我实际用过的方案是缓存5分钟，配合随机过期时间，防止缓存同时失效导致数据库瞬间被打满，也就是缓存雪崩。

第三层是接口限流。播放接口必须做限流，不然有人用脚本疯狂请求，再好的机器也会被打穿。最简单的做法是用Redis计数器，比如单个IP每分钟最多请求120次，超过直接返回429。

5.3 数据库层面的调优手段

数据库调优不用一上来就上分库分表，关键是先做好基础优化。

第一个优化是索引。song_name、singer_id、album_id、playlist_song表的playlist_id，这些字段必须有索引。冷门字段不要乱加索引，写入端也会受影响。

第二个优化是分页查询。歌曲列表默认按播放量排序，随着数据量增长，深度分页会越来越慢。解决办法是记录上次查询的最后一个歌曲ID，用id > lastId配合limit做滑动分页，而不是用offset翻页。这个方案在音乐列表这种场景下效果非常明显，因为用户很少真的去翻第500页。

第三个优化是数据库连接池参数。默认连接池配置可能只有10个连接，稍微有点并发就连接耗尽，接口报错或者长时间等待。我一般设置为initialSize=10，maxActive=100，maxWait=5000，具体数值根据服务器内存和实际并发调整。

6. 常见问题排查实录

6.1 音频能下载但无法在线播放

这个现象非常典型：浏览器直接访问音频URL能播放，但页面上Audio就是不出声。问题通常不是后端接口，而是前端给audio.src赋值的方式不对。如果你用的是相对路径，比如audio/123，那么浏览器会以当前页面路径为基础去拼接，最终变成前端域名的audio/123，自然拿不到资源。

正确写法是使用绝对路径，或者带上API网关前缀，比如/api/audio/123。另外，如果你后端做了Token校验，Audio标签发起的请求默认不会携带Authorization头，需要改用fetch先获取音频数据再转成Blob URL，或者把Token拼到查询参数上。

6.2 进度条拖不动，或者拖完直接从头播放

这个问题百分之九十是后端没有正确支持Range请求。打开浏览器Network面板，点击音频请求，看响应状态码是不是206。如果是200，说明你的接口把整个文件一次性返回了。这时候回头检查是不是自己在Controller里写了错误的状态码，或者前端有中间层把Range头吞掉了。

还有一个细节：Range请求的start值不能大于或等于文件总大小，否则浏览器会直接报错。后端实现时需要做一次边界判断，超出范围返回416状态码。

6.3 上传歌曲后封面不显示

封面不显示的排查顺序是：先看数据库里cover_url字段是否存了值，再看这个路径对应的文件是否真实存在，最后看Nginx静态映射是否正确。多数情况是路径拼接出了问题，比如文件存在服务器/data目录，但Nginx映射指向了/data2目录。

另一个隐蔽原因是Windows开发环境和Linux部署环境的路径分隔符不同。开发时用C:\data\cover\xxx.jpg，Linux下斜杠是反的。代码里写路径拼接时尽量用File.separator，或者干脆统一用正斜杠，让系统自动处理。

6.4 中文歌名搜索不到

中文搜索不到通常有两个原因。第一个原因是MySQL连接串里没加characterEncoding=utf8，导致查询条件乱码，匹配失败。第二个原因是前端搜索关键词没有做URL编码，中文在HTTP传输时被转成了无法识别的字符串。

解决方式：数据库连接串加上useUnicode=true&characterEncoding=utf8mb4；前端所有带中文的请求参数，用encodeURIComponent处理一下。这样处理后绝大多数中文搜索问题都能解决。

6.5 部署上线后接口访问很慢

本地跑着没问题，部署到服务器就变慢，这通常不是代码逻辑的锅，要按从近到远的顺序排查。先看是不是服务器带宽不够，音频文件走公网传输本来就会慢；再看Nginx有没有配置gzip压缩，虽然音频文件压缩率有限，但JSON接口数据压缩后体积能降一半以上。

还有一个容易被忽略的点是服务器时区。如果服务器时区与数据库时区不一致，时间类型字段存储会错乱，用户看到的时间不对，排查起来特别迷惑。部署前统一设置时区为UTC+8，数据库连接也明确指定serverTimezone=Asia/Shanghai，可以省掉很多后续的灵异问题。

6.6 用户登录突然失效，过一会儿又自己好了

这种间歇性登录失效，极大概率是Token过期时间设计不合理，或者多台服务器之间时钟不同步。如果只部署了一台机器，那问题多半来自前端没有正确把Token存到本地。localStorage和sessionStorage的选择也很关键：用户关闭浏览器后希望保持登录状态就用localStorage，希望安全一点就用sessionStorage。

还有一层：JWT是无状态的，Token签发后无法在服务端主动撤销。如果你的系统需要封禁用户，或者用户修改密码后强制下线，建议在Redis里维护一个Token黑名单，或者存一份当前有效Token的版本号，每次请求时校验。

这套系统做完之后，我个人的体会

项目做到能跑、能播、能部署，算是完成了70%，剩下的30%全在细节里。比如Range请求的206状态码、Nginx的try_files、文件名UUID重命名，这些东西不做也不会报错，但做了之后整个系统才真正像一个能上线的东西，而不是一个课程作业。

我在实际开发中还有一个觉得很值的小习惯：把接口文档在工作开始时先草草写一遍，再动手写代码。不用写得很正规，一张纸列清楚每个接口的入参、出参、状态码就行。音乐系统的接口虽然不多，但播放接口、上传接口、搜索接口之间互相依赖，提前梳理会让联调阶段省下大量时间。

如果做完上面这些还想继续扩展，可以考虑往这几个方向发力：用户个性化推荐、歌词滚动卡拉OK效果、社交功能里的好友歌单分享、移动端适配。以目前这套架构，加功能不需要推翻重来，这也是当初在设计表结构和文件存储时没有偷懒带来的底气。