基于JavaWeb的音乐播放器开发实战：从架构到部署

做基于JavaWeb的音乐播放器，核心要考虑的不仅仅是“播放”这一个动作，还有用户体系、歌曲资源管理、播放列表、歌词同步等一系列模块的联动。这篇文章我结合自己实际开发和部署的经验，从架构选型、数据库设计、核心功能实现到性能优化，把整个项目的关键细节都拆开讲一遍。

这个项目能解决什么问题？说白了就是让你通过浏览器就能完成音乐的在线试听、歌曲管理、歌单收藏这些操作，不需要安装任何客户端软件。它适合谁看？适合正在做JavaWeb课程设计、毕业设计的同学，也适合想了解Web端音频流媒体处理机制的开发者。全文不走虚的，都是实际操作中总结出来的干货。

1. 项目整体设计与技术选型

1.1 核心需求拆解

在动手写代码之前，我花了两天时间梳理需求。这里面的经验是：音乐播放器虽然看起来功能不复杂，但如果你上来就写，很容易写着写着就乱套了。

我最后列出的是一份标准的功能清单：

• 用户模块：注册、登录、个人信息修改（头像、昵称）
• 音乐管理：歌曲上传、歌曲信息维护（歌名、歌手、专辑、封面）
• 歌单模块：创建歌单、收藏歌曲到歌单、歌单编辑与删除
• 播放功能：在线播放、上一首/下一首、播放模式切换（顺序/随机/单曲循环）
• 搜索功能：按歌名、歌手、专辑搜索
• 歌词模块：歌词展示与同步，支持LRC格式解析

为什么要有这些功能？因为单独一个“播放器”没有内容来源，也没有用户粘性。加入用户体系和歌单功能，数据才有闭环，项目才有完整度。这也是为什么很多课程设计、毕设题目都倾向于音乐播放器——它麻雀虽小，五脏俱全。

功能定了之后，我根据优先级把开发排成三轮：第一轮只做播放器最核心的在线播放和歌曲列表；第二轮做用户系统；第三轮做歌单和歌词联动。这样每轮结束都有一个能跑通的版本，不用全部做完才看到效果。

1.2 技术栈选型：为什么用这套组合

我的技术栈选型如下：

• 后端：Spring Boot 2.x + MyBatis Plus
• 数据库：MySQL 8.0
• 前端：HTML + CSS + JavaScript（原生）
• 音频播放：HTML5 Audio标签
• 文件存储：本地磁盘存储，文件路径存数据库

有些同学可能会问，为什么前端不直接用Vue、后端用Spring Boot做前后端分离？原因很简单：如果你是在做课程设计，很可能需要演示的时候直接双击HTML就能看到页面效果，或者不熟悉Node构建流程。传统的Servlet/JSP或者Spring Boot + Thymeleaf模板渲染，对教学环境和答辩展示是更友好的选择。

但我也不是完全放弃前后端分离的思路。因为纯模板渲染的话，音乐播放器这种高频交互的页面会变得很别扭。我的做法是：页面结构和后台管理用模板渲染，播放器核心页面用AJAX + JSON接口交互。这样既保留了传统Web开发的简单性，又兼顾了播放器页面的交互体验。

另外关于开发工具，我用的VS Code加Java扩展插件来写后端，前端页面也直接在一个工程里管理。如果用Eclipse或者IDEA也完全可以，看个人习惯。这里我多说一句，如果是学生党，建议尽早把VS Code或者IDEA的快捷键摸熟，后面写代码会顺手很多。

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

2.1 数据库表结构设计

数据库设计是整个项目的地基。我见过太多人一开始图省事，把字段全塞在一张表里，最后改需求的时候哭都哭不出来。

我的表设计如下（只展示核心字段）：

用户表 user

歌手表 singer

歌曲表 song

歌单表 playlist

歌单歌曲关联表 playlist_song

这几张表基本够用了。设计的时候有几点要注意：

第一，密码一定要加密存储。我之前见过不少学生的项目直接明文存密码在数据库里，答辩的时候老师一问密码安全性，一下子就慌了。用BCrypt加密很简单，Spring Security里自带，或者你自己引入一个jBCrypt的jar包都行。

第二，歌曲状态字段要预留。有的歌曲可能因为版权原因需要下架，你总不能物理删除吧，留一个status字段做逻辑删除就好，后面运营和维护都方便。

第三，歌词单独存文本。LRC格式的歌词本质上就是一个文本文件，没必要单独建表或者存文件服务器。直接塞在song表的lyric字段里，前端解析文本就行。

2.2 音频文件的存储与管理

音频文件存储有两个主流方案：本地存储和云存储。

对于课程设计或小项目，我建议用本地存储。原因很简单：不依赖外部服务，部署简单，演示稳定。具体做法是在项目根目录建一个 static/media/ 文件夹，把上传的mp3文件按日期分目录存放，比如 static/media/2025/01/15/uuid.mp3，文件名用UUID避免冲突和中文乱码。

云存储（比如OSS）的优势是容量大、带宽高、不怕磁盘满，但你需要额外配置AccessKey，还得花钱。作为一个练手项目，完全没必要。不过我在代码里做了一层FileStorage接口的抽象，后续如果想切云存储，只需要实现一个接口替换掉实现类即可，这个设计思路值得参考。

另外注意一点，上传文件一定要做类型和大小校验。类型只允许mp3、wav、flac这些音频格式，大小限制在50MB以内。别只在前端限制，后端也要校验，否则会有人绕过前端直接发POST请求传个脚本上去。

我这里说一个比较隐蔽的坑：MIME类型校验不能只看Content-Type，因为HTTP请求头是可以伪造的。最稳妥的方式是读文件的前几个字节，也就是魔数校验。后面我会在常见问题部分详细讲这个方案的具体写法。

3. 核心功能实现与踩坑记录

3.1 流式播放接口的实现

这是整个项目最关键也最容易出问题的地方。

如果只是简单地把音频文件的URL丢给浏览器，让Audio标签自己加载，那也可以，但有几个问题：

1. 播放进度无法拖动：很多浏览器对不支持Range的文件不允许seek（跳到中间播放）
2. 无法断点续传：网络差的时候容易卡住
3. 不防盗链：别人拿到URL就能随便下载

我的解决方法是自己写一个流式传输接口。核心原理就是支持HTTP Range请求。这个接口长这样：

java复制@RestController
@RequestMapping("/api/media")
public class MediaController {

    @GetMapping("/stream/{songId}")
    public void stream(@PathVariable("songId") Long songId,
                       HttpServletRequest request,
                       HttpServletResponse response) throws Exception {
        Song song = songService.getById(songId);
        // 更新播放次数
        songService.incrementPlayCount(songId);
        
        File audioFile = new File(song.getFileUrl());
        if (!audioFile.exists()) {
            response.setStatus(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
        
        long fileLength = audioFile.length();
        String range = request.getHeader("Range");
        
        if (range == null) {
            // 不带Range，直接返回完整文件
            response.setContentType("audio/mpeg");
            response.setHeader("Accept-Ranges", "bytes");
            response.setContentLengthLong(fileLength);
            Files.copy(audioFile.toPath(), response.getOutputStream());
        } else {
            // 解析Range头，返回部分内容
            String[] ranges = range.replace("bytes=", "").split("-");
            long start = Long.parseLong(ranges[0]);
            long end = ranges.length > 1 && !ranges[1].isEmpty()
                    ? Long.parseLong(ranges[1])
                    : fileLength - 1;
            
            long contentLength = end - start + 1;
            response.setStatus(HttpServletResponse.SC_PARTIAL_CONTENT);
            response.setContentType("audio/mpeg");
            response.setHeader("Accept-Ranges", "bytes");
            response.setHeader("Content-Range", "bytes " + start + "-" + end + "/" + fileLength);
            response.setContentLengthLong(contentLength);
            
            try (FileInputStream fis = new FileInputStream(audioFile);
                 OutputStream os = response.getOutputStream()) {
                fis.skip(start);
                byte[] buffer = new byte[8192];
                long bytesToRead = contentLength;
                while (bytesToRead > 0) {
                    int len = fis.read(buffer, 0, (int) Math.min(buffer.length, bytesToRead));
                    if (len == -1) break;
                    os.write(buffer, 0, len);
                    bytesToRead -= len;
                }
                os.flush();
            }
        }
    }
}

这段代码的原理不复杂，关键是 Range 头的解析。当播放器拖进度条时，浏览器会发一个类似 Range: bytes=123456- 的请求，后端需要定位到对应的字节偏移量，从那个位置开始继续返回数据。

在动手写这个接口之前，我其实犯过一个很低级的错误——只用 Files.copy() 把整个文件输出，然后发现进度条可以拖，但是拖了之后浏览器会重新从0开始播放，体验很糟糕。后来查了浏览器网络请求才发现，问题出在服务端返回的状态码不对，没有返回206，导致浏览器认为这个资源不支持部分请求。

另外提醒一下，如果你是用Servlet 3.0+的容器，其实还有更简单的方式：在response里直接设置Header，然后用RequestDispatcher转发给静态资源处理器，让容器帮你处理Range。但自己写的好处是可以加日志、做权限控制，尤其是当你想限制某些歌曲只能VIP用户在线播放不允许下载的时候，自己写接口灵活得多。

3.2 前端播放控制与歌词同步

前端我用的是原生HTML5 Audio标签，加一套自绘的控制栏。

HTML结构大概是这样的：

html复制<audio id="player" preload="metadata"></audio>
<div class="player-controls">
    <button id="playBtn">播放/暂停</button>
    <button id="prevBtn">上一首</button>
    <button id="nextBtn">下一首</button>
    <div class="progress">
        <div id="progressBar"></div>
    </div>
    <span id="currentTime">00:00</span>
    <span id="totalTime">00:00</span>
    <select id="playMode">
        <option value="order">顺序播放</option>
        <option value="random">随机播放</option>
        <option value="single">单曲循环</option>
    </select>
</div>
<div id="lyricContainer"></div>

播放的核心逻辑我在JavaScript里封装成一个播放器对象，关键事件监听如下：

javascript复制const audio = document.getElementById('player');

// 监听播放进度
audio.addEventListener('timeupdate', function () {
    const current = audio.currentTime;
    const duration = audio.duration;
    // 更新进度条和当前时间
    document.getElementById('progressBar').style.width = 
        (current / duration * 100) + '%';
    // 同步歌词
    syncLyric(current);
});

// 拖进度条
document.getElementById('progressBar').addEventListener('click', function (e) {
    const rect = this.getBoundingClientRect();
    const ratio = (e.clientX - rect.left) / rect.width;
    audio.currentTime = ratio * audio.duration;
});

歌词同步这里有一个大坑——LRC格式的时间戳解析。LRC歌词是一个带时间标签的文本，格式类似：

code复制[00:12.34]第一句歌词
[00:18.56]第二句歌词

你需要先把每一句的时间戳解析成秒，存到数组里。然后在 timeupdate 事件里判断当前播放时间落在哪一句的区间，把对应的歌词高亮显示。

解析代码大致是：

javascript复制function parseLRC(lrcText) {
    const lines = lrcText.split('\n');
    const lyricLines = [];
    const timeReg = /\[(\d{2}):(\d{2}\.?\d*)\]/g;
    
    lines.forEach(line => {
        let match;
        while ((match = timeReg.exec(line)) !== null) {
            const minutes = parseInt(match[1]);
            const seconds = parseFloat(match[2]);
            const time = minutes * 60 + seconds;
            const text = line.replace(timeReg, '').trim();
            lyricLines.push({ time, text });
        }
    });
    
    // 按时间排序
    lyricLines.sort((a, b) => a.time - b.time);
    return lyricLines;
}

这里有个细节：一句歌词可能对应多个时间戳（比如前面唱一遍、副歌再唱一遍），所以 while 循环必不可少，不能用 exec 一次就完事。我第一次写的时候就是用了 if 而不是 while，结果副歌部分的歌词只高亮了第一段，后面全都不显示。

除了高亮，歌词区域还要做自动滚动。如果纯文字在高亮的时候不动位置，长歌词就会被截断。我用的方案是给歌词容器设置一个固定高度加 overflow: hidden，每次高亮到当前句时，通过 scrollTop 平滑滚动到当前句所在的位置，这样视觉效果就像歌词在“翻页”一样。当然如果你不追求这个效果，直接 overflow-y: auto 让用户手动滚动也可以，但演示效果会差不少。

3.3 播放模式的逻辑处理

播放模式看着简单，但逻辑上有个容易被人忽视的边界情况：在随机播放模式下，连续两首不能重复播放同一首歌。

我当时先用了 Math.random() 直接随机生成下标，然后发现一首歌可能会连续被播放两次，体验很怪。最后改成洗牌算法（Fisher-Yates），每次切歌时从剩余歌单里随机选，选完重新洗牌。这个算法虽然简单，但能保证同一个播放周期内每首歌只出现一次。

而单曲循环模式下，播放完当前歌曲需要监听 ended 事件，然后调用 audio.currentTime = 0; audio.play();，而顺序播放模式的 ended 事件则要判断是否到达歌单末尾，末尾了就直接停住，不然会从头开始。

三种模式的逻辑我在代码里用一个 switch 来处理：

javascript复制audio.addEventListener('ended', function () {
    switch (playMode) {
        case 'order':
            if (currentIndex < playlist.length - 1) {
                currentIndex++;
            } else {
                return; // 播完就停
            }
            break;
        case 'random':
            currentIndex = getRandomIndex();
            break;
        case 'single':
            audio.currentTime = 0;
            audio.play();
            return;
    }
    loadSong(currentIndex);
});

这个逻辑不复杂，但一定要把边界条件想清楚，不然在演示的时候很容易出现“明明该停还在唱”的尴尬局面。

还有一个和音乐播放器测试相关的话题：如果你要写自动化测试，比如用Appium做移动端播放器的测试，Play/Pause、SeekBar拖动、歌词滚动这些动作基本都是核心用例。Web端的播放器也可以用Selenium配合JS执行来模拟点击和拖拽，但需要注意Audio元素的状态断言要比普通元素复杂一些，通常要等 loadedmetadata 事件触发之后才能拿到真实的 duration 值。

4. 常见问题与性能优化实录

4.1 音频上传失败的N种原因

上传功能我调试了整整一个下午，踩了这些坑：

第一个坑：Tomcat的默认大小限制。 Tomcat 9 默认最多允许上传1MB，超过就报 org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException。解决方法是在Spring Boot的配置文件里加：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 100MB
      max-request-size: 200MB

第二个坑：MIME类型校验不严。 有些用户把mp3文件改个扩展名传上来了，前端校验看后缀名合法，但实际上根本不是音频。后来我在后端加了一层魔数校验，读取文件前4个字节，MP3文件的帧头是 0xFF 0xFB 或 0xFF 0xF3，WAV文件开头一定是 RIFF。这个校验虽然不能100%防住所有情况，但能挡掉大部分有心或无意的问题。

第三个坑：文件名中文乱码。 上传一个歌名是中文的mp3，存到服务器上文件名全变成乱码了。解决方案：完全不要用原始文件名当存储文件名，用UUID生成新文件名，原始歌名放到数据库的字段里去。

下面是我后端上传接口的参考写法：

java复制@PostMapping("/api/song/upload")
public Result uploadSong(@RequestParam("file") MultipartFile file,
                         @RequestParam("songName") String songName,
                         @RequestParam("singerId") Long singerId) throws IOException {
    // 1. 校验文件大小
    if (file.getSize() > 50 * 1024 * 1024) {
        return Result.error("文件大小不能超过50MB");
    }
    
    // 2. 校验魔数
    byte[] header = new byte[4];
    try (InputStream is = file.getInputStream()) {
        is.read(header, 0, 4);
    }
    if (!isValidAudioHeader(header)) {
        return Result.error("文件类型不合法，仅支持mp3/wav/flac");
    }
    
    // 3. 保存到本地
    String ext = getExtension(file.getOriginalFilename());
    String newFileName = UUID.randomUUID() + "." + ext;
    String datePath = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM/dd"));
    File destDir = new File(uploadPath, datePath);
    if (!destDir.exists()) {
        destDir.mkdirs();
    }
    File dest = new File(destDir, newFileName);
    file.transferTo(dest);
    
    // 4. 保存数据库记录
    Song song = new Song();
    song.setSongName(songName);
    song.setSingerId(singerId);
    song.setFileUrl("/static/media/" + datePath + "/" + newFileName);
    song.setDuration(getAudioDuration(dest));
    song.setStatus(1);
    songService.save(song);
    
    return Result.success(song);
}

4.2 播放卡顿与首帧延迟优化

如果你是用本地文件存储，播放卡顿的概率不大。但如果歌曲文件放在服务器上，而服务器带宽不够，加载大文件就会明显卡顿。

一个有效的优化方式是适当设置预加载策略。默认 preload="metadata" 我只加载文件头部元数据，拿到时长信息，而不是一打开页面就把整首歌都加载完。这其实就是利用了前面做的那个流式接口的Range支持——浏览器要metadata时只会发个小请求，获取文件前几KB的内容。

第二招是生成多码率的音频转码。这不是必选项，但如果你想做“低带宽自适应”，可以用FFmpeg把MP3转成128kbps和64kbps两个版本，然后接口根据客户端网络情况返回不同版本。这部分工作量大，课程设计阶段就不推荐做了。

第三招是最容易被忽略的：前端不要反复修改audio元素的src属性。每次重新设置src，浏览器都会重新发起一次请求，如果用户频繁点击下一首，会造成大量请求堆积。我的做法是切歌前先判断是否同一首歌，是同一首就直接 audio.currentTime = 0，不是才更新src。

另外还有一个和小团队部署环境相关的点：如果你要部署在国产化服务器环境，比如银河麒麟系统V10的服务器版，Java环境配置本身没问题，但需要注意两个地方。第一个是FFmpeg这类外部命令是否自带，如果没装就要手动安装；第二个是音频文件的路径权限，如果文件目录的属主和Web容器运行用户不一致，上传和读取都会报权限异常。我当时就是没注意这个，文件能上传成功但播放时老是403，查了半天才发现是目录owner不对。

4.3 数据库连接池与查询优化

数据库这块，虽然数据量不大（几百首歌、几百个用户），但良好的设计和写法还是能看出功底。

我的建议是：

1. SQL不要写SELECT * FROM，只取需要的字段。
2. 播放次数用UPDATE而不是先SELECT再UPDATE。这样能避免并发下计数不准确的问题。比如要播放次数加1，直接写 UPDATE song SET play_count = play_count + 1 WHERE id = ?，不要先查出来再通过代码加。
3. 列表页分页查询，一首一首展示，不要一次查出几百首歌。

另外我加了一个简单的定时任务，每天晚上把当天的播放量汇总到一张统计表里。虽然这个项目没那么大访问量，但这套思路在真实产品里是通用的。

高并发下的一个经典问题我记得很清楚：有一次测试的时候，50个用户同时打开播放器首页，数据库连接池默认大小是10，瞬间报错了 Connection is not available, request timed out after 30000ms。解决方案很简单，调大连接池配置：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 10000

调大之后，那个错误就再也没出现了。

提示：连接池大小不是越大越好。数据库连接数量越多，MySQL自身压力也越大。一般来说20~30个连接足够覆盖课程设计这种量级。如果你真的要做大并发，更应该考虑的是加缓存和排队，而不是无限调大连接池。

4.4 其他容易忽略的小细节

还有个容易被忽略的问题：播放次数统计。每次播放都实时更新数据库，会导致歌曲详情接口响应变慢。我的做法是播放时只在前端计数，暂停或退出页面时再批量提交。这种“先本地累计，再异步上报”的思路很多大厂都在用，你可以在 beforeunload 事件里用 navigator.sendBeacon 发送数据，这样即使页面关闭也不会丢。

另外一个安全上的小坑：文件上传接口如果没有做登录拦截，任何人都能往你的服务器上传文件。虽然我加了很多校验，但还是要加上登录拦截。Spring Boot里可以用拦截器或者过滤器统一处理，大概十来行代码：

java复制@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        HttpSession session = request.getSession();
        if (session.getAttribute("user") != null) {
            return true;
        }
        response.setStatus(401);
        return false;
    }
}

然后注册拦截器的时候，只拦 /api/song/upload、/api/playlist/** 这类需要登录的接口，播放接口和歌曲列表接口放行，否则游客就不能听歌了。

5. 部署环境与项目扩展方向

5.1 打包部署时容易忽略的配置

本地开发一切正常，一到部署就各种问题，这是JavaWeb项目的常态。我总结几个部署阶段的高频问题：

问题一：静态资源404。 如果你的音频文件是存在项目根目录下的 static/media/ 里，Spring Boot默认会映射 classpath:/static/ 和 file:./static/。但如果你用了FatJar方式启动，./static/ 路径和你Jar包所在的目录不一样，就可能导致文件找不到。我建议单独配置一个外部存储路径，比如 /data/music-player/media/，然后在配置类里加一个资源映射：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Value("${media.storage-path}")
    private String storagePath;
    
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/media/**")
                .addResourceLocations("file:" + storagePath + "/");
    }
}

这样部署的时候只要保证配置目录存在，就不用关心Jar包内部的结构。

问题二：MySQL时区问题。 如果你在数据库里存了 create_time，部署到另一台机器上发现时间对不上，十有八九是时区设置问题。连接串里加 serverTimezone=Asia/Shanghai 可以解决。这个问题在本地开发时经常因为用了默认时区而没暴露。

问题三：数据库字符集。 建库的时候记得用 utf8mb4 而不是 utf8，不然存emoji或者某些特殊符号的时候会报错。MySQL的utf8并不是真正的UTF-8，它最多只支持3个字节，而utf8mb4才完整支持4字节的Unicode字符。表设计的时候统一字符集，后面少很多麻烦。

5.2 后续可以扩展的方向

项目骨架搭好之后，想继续往上做，优先级最高的是下面这几个方向：

音乐推荐功能。 你可以根据用户的播放记录做简单的“相似歌手推荐”或“猜你喜欢”。不用上协同过滤，只做最简单的“根据歌手ID统计播放次数Top N”就能出效果。这样不仅能展示自己的SQL能力，还让项目有了个性化的亮点。

评论与点赞。 给歌曲加一个评论区，用户登录后可以发表评论和点赞。这个功能能丰富项目的互动性，而且数据模型非常简单，就是在song_id、user_id、content、like_count这几张表之间打转。答辩的时候也容易讲清楚。

对接第三方音乐API。 如果你不想手动维护歌手和专辑数据，可以考虑对接第三方公开的音乐信息接口，自动拉取歌曲的封面、专辑、歌词等信息。但要注意版权问题，尽量只拿元数据不拿音频文件。

文件存储切云存储。 如果项目有真实的用户量，本地磁盘迟早会有瓶颈。我在代码里预留了FileStorage接口，后续只要再写一个OssStorageImpl实现类，替换Bean就可以了。从架构层面讲，这个扩展其实是最容易的。

我个人建议如果是毕设项目，挑一个方向深做就好，比如做好歌词同步和播放页交互，或者做好推荐算法，都比把所有功能都浅尝辄止强得多。毕竟答辩的时候，老师看的是你对某一块的理解深度，而不是功能的堆砌数量。

6. 最后分享一点个人经验

做这个JavaWeb音乐播放器项目，最大的体会是：一个看起来简单的功能，做到能用和做到好用之间，差距全在细节里。

比如播放进度条，能播和能拖之间差了一个Range请求的处理；比如播放模式，能随机和随机不重复之间差了一个洗牌算法；比如播放次数统计，能计数和计得准之间差了一个防并发方案。这些细节不会出现在需求文档里，但会真实地影响用户体验。

如果你也想做一个类似的JavaWeb音乐播放器，我建议你按这样的顺序推进：先把播放器单个页面跑通，再做用户登录注册，再做歌单系统，最后做歌词和管理后台。每一个阶段完成之后都实际验证一下再去推进下一个，避免一次写太多改起来无从下手。

另外一个经验是，多用浏览器的Network面板和Console面板。做音频项目时，很多问题比如Range请求没生效、并发太高、资源404等，其实从Network面板里一眼就能看出来。学会看浏览器开发者工具，比在网上瞎搜问题答案要快得多。

项目本身做完了之后，后续的扩展方向还是很多的。骨架搭好了，上面长什么内容都顺理成章。希望这篇文章能帮你少踩几个坑，早日把项目跑起来。