JSP+MySQL在线音乐管理系统：从数据库设计到部署全解析

简介：一个基于 JSP 技术栈开发的在线音乐信息管理系统完整项目，采用 Java Web + JSP + MySQL + JavaScript 实现，适合正在学习 Java Web 开发、需要课程设计或毕业设计参考的学生。系统区分管理员与普通用户两类角色：前台支持歌曲查询、在线试听、下载、分页浏览与最近播放；后台支持管理员登录、歌曲上传/添加/删除及维护歌曲信息。压缩包共 110 个文件，包含 JSP 页面、Java 源码与 class 编译文件、MySQL 建库 SQL、JAR 依赖库以及界面图片等，整体 14.32MB；附带管理员表、歌曲类别表和歌曲表的字段设计说明，方便直接导入数据库运行。资源包中提供后台核心类如 SongDAO、ManagerDAO 及分页工具类，可帮助读者快速理解业务分层与常见操作逻辑。目前已有 447 人学习下载，适合作为实战练习或二次开发的起点。

1. 这套基于 Jsp 的在线音乐信息管理系统，到底解决什么问题

前端出身的同学看不上它，后端转行的同学又嫌它老，但如果你正在选 Jsp 方向的毕设或课设题目，恰好需要同时覆盖 Java、MySQL、JavaScript 三个考点，这套「在线音乐信息管理系统（含前后台）」是很典型的闭环：前台给游客和注册用户用，做歌曲浏览、搜索、试听、评论；后台给管理员用，做歌手、歌曲、歌单的增删改查。传统 JSP 项目不需要额外搭前端工程，页面、逻辑、数据三层都在一个 war 包里面，部署起来也省事。

它的价值在于：系统麻雀虽小，却能完整走一遍「建表 → 连接池 → Servlet 控制器 → JSP 渲染 → JavaScript 交互」的主链路，把书本上分散的知识串成一套可运行的东西。如果你的目标是搞懂 Java Web 传统开发模式，而不是追逐微服务和大数据，那这套东西是把基础打扎实的捷径，后面学 Spring 时你会感谢现在踩过的 JSP 和各种坑。

2. 先定数据结构再写页面：五张核心表和连接池配置

做任何管理系统，第一件事不是新建 JSP 页面，而是先把表结构定下来。页面可以返工，表设计错了要改的地方几乎是全局的。在线音乐系统的核心实体拆下来就五个：用户、歌手、歌曲、歌单、评论。

2.1 实体拆分：为什么是这五张表

前台和管理后台共用同一套数据模型，只是操作权限不同。用户表管登录注册和收藏，歌手表管艺人信息，歌曲表挂在歌手下面，歌单表做收藏夹，评论表挂在歌曲下面。五张表之间的外键关系用最简单的主外键关联即可，不需要多对多的中间表。

歌曲表是整张数据模型的心脏，它不只是存文件名，还要区分音频 URL、封面图 URL、歌词文本和播放次数。字段设计上我习惯把「文件存路径、数据存内容」分开，数据库里只存相对路径，不存完整 URL，这样将来换服务器域名不用改数据。播放次数单独一个字段，后台首页要展示热门歌曲排行时直接 order by play_count，避免每次实时 count 评论表。

用户表要注意把密码加密字段独立出来，别把密码和盐拼在一个字段里。很多 JSP 毕设喜欢明文存密码，答辩时被问一句「如何防脱库」就很尴尬。虽然这套系统不要求超纲安全设计，但存一个加盐的 MD5 并不复杂，表结构里预留 password_salt 字段成本很低。

2.2 建表 SQL 与初始化数据：把索引和字符集一次做对

创建数据库时直接指定 utf8mb4，这个字符集能存 emoji 和生僻字。很多老项目用 utf8，用户在评论里粘贴一个特殊符号就报 Incorrect string value，排查半天发现是字符集问题。以下是建表核心代码，字段说明写在注释里：

CREATE DATABASE IF NOT EXISTS music_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE music_db; CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录名，唯一', `password` varchar(64) NOT NULL COMMENT '加盐后的MD5，长度64', `salt` varchar(16) NOT NULL COMMENT '随机盐值', `email` varchar(100) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL COMMENT '头像相对路径', `role` tinyint(1) NOT NULL DEFAULT 0 COMMENT '0普通用户 1管理员', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4; CREATE TABLE `singer` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL COMMENT '歌手名', `avatar` varchar(255) DEFAULT NULL COMMENT '歌手头像', `intro` text COMMENT '简介，后台富文本区域', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4; CREATE TABLE `song` ( `id` int(11) NOT NULL AUTO_INCREMENT, `singer_id` int(11) NOT NULL COMMENT '关联歌手表', `name` varchar(100) NOT NULL, `audio_url` varchar(255) NOT NULL COMMENT '音频相对路径', `cover_url` varchar(255) DEFAULT NULL COMMENT '封面相对路径', `lyrics` text COMMENT 'LRC格式歌词文本', `play_count` int(11) NOT NULL DEFAULT 0, `status` tinyint(1) NOT NULL DEFAULT 1 COMMENT '1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_singer_id` (`singer_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;

连接种子数据比较简单，但注意管理员账号要单独插入，普通用户留一个测试账号即可。歌曲初始化数据别贪多，放十几条就够了，重点是让前台页面有内容可以展示，并且演示分类和歌手关联效果。

上面这段 SQL 有三个关键点值得说。第一个是 user 表的 salt 字段，注册时生成随机字符串，登录时把用户输入的密码和盐一起做 MD5，这样即使数据库被拖走也无法直接反查明文。第二个是 song 表对 status 和 singer_id 建了索引，前台按歌手查、按上下架状态过滤都能走索引，数据量到十万级也不会卡。第三个是外键我故意没建物理外键，只建了普通索引，因为管理后台经常要批量删除歌手和其下歌曲，物理外键会阻塞删除逻辑。

2.3 数据库连接池参数：Druid 的配置和每个参数的坑

传统 JSP 项目里最常见的连接池是 Druid 和 C3P0。搜索引擎里大量出现「mysql 的数据库连接池」这种搜索词，说明很多人虽然会用但并不知道为什么需要它。不用连接池时每次请求都 DriverManager.getConnection 一次，一个页面十个查询就开十次物理连接，Tomcat 下高并发直接就 Too many connections。连接池的作用是复用连接，把建连的昂贵开销变成参数。

我一般用 Druid，因为它的监控页面在调优时很直观。配置文件名放 src/druid.properties，由工具类加载：

# druid.properties driverClassName=com.mysql.cj.jdbc.Driver url=jdbc:mysql://localhost:3306/music_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username=root password=你的数据库密码 initialSize=5 minIdle=5 maxActive=20 maxWait=10000 validationQuery=SELECT 1 testWhileIdle=true

工具类加载 properties 的代码各框架略有差异，核心就是 DruidDataSourceFactory 创建数据源，然后对外暴露 getConnection。注意 url 里 serverTimezone 必须写，MySQL 8.x 驱动不写时区会直接报 CST 时区异常；allowPublicKeyRetrieval=true 是 MySQL 8.0 用 caching_sha2_password 认证时必须加的，不然连不上。

这些参数里最容易踩坑的是 maxActive 配得过大。有人为了性能一口气配 200，结果 Tomcat 和 MySQL 都在同一台两核四G的云服务器上，MySQL 默认最大连接数是 151，连接池把数据库打爆后所有请求都在等连接释放，页面表现就是「转圈很久然后报超时」。我的建议是 maxActive 控制在 20 到 50 之间，initialSize 保持 5，maxWait 设 10000 毫秒，超出就快速失败，别让用户无限等下去。

提示：validationQuery=SELECT 1不是可有可无。MySQL 空闲 8 小时会自动断开连接，连接池里的连接变成「死连接」，应用拿到的瞬间才报错。加上 testWhileIdle 后空闲连接会被定期探测，失效的直接剔除。

3. 前后台请求链路：JSP、Java、JavaScript 各自该管什么

很多 JSP 毕设翻车就翻在「所有逻辑都写在 JSP 里」。一个 index.jsp 里写了 Java 查询、拼 HTML、还嵌了一段 onclick 调 AJAX，最后页面两千行谁也改不动。传统 JSP 项目一样可以分层，只是 Spring 帮我们做好的事现在要自己手写。

3.1 从页面直接查库到 Servlet 控制器：为什么必须绕这一层

JSP 的本质是在 HTML 里写 Java，Java 的本质是在 Servlet 里处理请求。正确的做法是浏览器请求打到 Servlet，Servlet 调 DAO 查询数据，再把结果塞进 request 作用域转发给 JSP。JSP 只负责渲染，不负责查库。这样做的好处是：改页面不需要动 Java 逻辑，换数据库不用改 JSP，前后台权限拦截也只需在 Servlet 层统一加。

// com.music.web.IndexServlet.java @WebServlet("/index") public class IndexServlet extends HttpServlet { private SongDao songDao = new SongDao(); @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { List<Song> hotList = songDao.findHotSongs(10); List<Singer> singerList = singerDao.findAll(); req.setAttribute("hotList", hotList); req.setAttribute("singerList", singerList); req.getRequestDispatcher("/index.jsp").forward(req, resp); } }

上面的代码逻辑很简单：doGet 里查两个集合，放进 request，转发到 index.jsp。页面里用 JSTL 循环渲染即可。关键点是编码问题，Java 文件里和 JSP 文件里的字符编码必须统一 UTF-8，很多中文乱码是这里不一致造成的。另外所有跳转都走后端路由而不是直接访问 JSP 文件，这样才能在下游的 Filter 里统一做权限校验。

搜索热搜里经常有「idea 新建 jsp 项目找不到 Servlet」的提问，本质上是没有引入 Tomcat 运行时，新建项目时到 Project Structure 的 Libraries 里添加 Tomcat 的 lib 目录，或者右键项目 Add Framework Support 勾选 Web Application 即可，这一点在第五章节展开。

3.2 登录鉴权过滤器：前后台隔离的第一步

前后台项目必须做权限隔离。游客能访问首页、歌曲详情、搜索；注册用户能评论、收藏；管理员才能访问 admin/ 前缀的资源。这里只需要一个 Filter，检查请求路径前缀，再看 Session 里的登录态。

// com.music.filter.AuthFilter.java @WebFilter("/*") public class AuthFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); // 静态资源和公共页面直接放行 if (uri.endsWith(".css") || uri.endsWith(".js") || uri.endsWith(".jpg") || uri.contains("/index") || uri.contains("/login") || uri.contains("/register")) { chain.doFilter(request, response); return; } // admin 前缀必须管理员登录 if (uri.contains("/admin/")) { Object user = request.getSession().getAttribute("loginUser"); if (user == null || !"1".equals(((User) user).getRole())) { response.sendRedirect(request.getContextPath() + "/login.jsp?redirect=admin"); return; } } chain.doFilter(request, response); } }

这个 Filter 的设计逻辑是「白名单放行，其余走登录检查」。实际开发中白名单会随功能逐渐加长，我的习惯是把公共路径集中放在一个数组里，不要写成一长串 if。过滤器拦截的是 URI 而不是 JSP 里的内容块，所以后台管理页面一定要放在 webapp/admin/ 目录下，物理目录隔离比逻辑判断更直观。

还有一个容易漏的细节：设置 response.setCharacterEncoding("UTF-8") 在 Filter 里统一处理，会比每个 Servlet 里写一遍更省心。SetCharacterEncodingFilter 是 Java Web 的老套路，现在用 @WebFilter + 初始化参数可以直接等价实现。

3.3 JavaScript 在前台的边界：播放器交互与校验

Java 管数据流，JavaScript 管用户交互，这是传统 JSP 项目的分工。JavaScript 在这套系统里主要干三件事：表单校验、AJAX 局部刷新、播放器控制。表单校验用原生 JS 就够，没有必要引大框架；AJAX 用一个函数封装 XMLHttpRequest；播放器则是整个前台交互的亮点。

// js/player.js 全局唯一播放器控制对象 var player = { audio: null, currentId: null, playing: false, init: function() { this.audio = document.createElement('audio'); this.audio.preload = 'metadata'; document.body.appendChild(this.audio); }, toggle: function(songId, songUrl) { if (this.currentId === songId) { this.playing ? this.audio.pause() : this.audio.play(); } else { this.audio.src = songUrl; this.currentId = songId; this.audio.play(); } } };

这段代码把音频元素做成全局单例，管理播放状态。很多 JSP 新手会把多个 audio 标签直接塞在每个歌曲卡片里，点一下播一个音，切歌时全响。全局单例播放器是解决切歌混乱的标准做法。注意 preload 设为 metadata，页面加载时只读取歌曲时长信息，不直接下载整首音频，这样列表页加载会快很多。

播放器还有个隐藏问题：自动播放策略。Chrome 会拦截非用户手势的 audio.play()，所以页面加载时不能自动开播，只有用户点击按钮的事件流里才能播放。搜索引擎里「javascript input 模拟输入」「javascript 函数」这类热词也常出现在表单校验场景，比如搜索框做防抖、输入框失去焦点查重名，这些用原生 JS 都能做，不需要引入 axios。

4. 功能落地：搜索分页、文件上传、播放列表的具体实现

骨架打好后，真正让系统活起来的是几个高频功能：搜索分页、歌曲上传、播放列表。这三个功能分别考察 Java 查询能力、文件 IO 能力和 JavaScript 交互能力，也是答辩时最容易被追问的点。

4.1 搜索与分页组合查询：参数拼接和三个边界条件

搜索框会传给 Servlet 一个 keyword，还要支持按歌手筛、按分类筛。如果把所有筛选条件都做出来，SQL 要动态拼接。这里最容易翻车的点是：keyword 为空时 SQL 语法错误，以及分页 page 参数越界。以下是最小可用的搜索分页代码：

// SongDao.java 核心搜索方法 public List<Song> search(String keyword, Integer singerId, int page, int size) { StringBuilder sql = new StringBuilder("SELECT * FROM song WHERE status=1 "); List<Object> params = new ArrayList<>(); if (keyword != null && !keyword.trim().isEmpty()) { sql.append("AND name LIKE ? "); params.add("%" + keyword.trim() + "%"); } if (singerId != null && singerId > 0) { sql.append("AND singer_id = ? "); params.add(singerId); } // 分页参数做防御：page最小1，size控制在20以内 int safePage = Math.max(page, 1); int safeSize = Math.min(Math.max(size, 1), 20); sql.append("ORDER BY play_count DESC LIMIT ? OFFSET ? "); params.add(safeSize); params.add((safePage - 1) * safeSize); PreparedStatement ps = conn.prepareStatement(sql.toString()); for (int i = 0; i < params.size(); i++) { ps.setObject(i + 1, params.get(i)); } // 执行查询并映射结果集，篇幅原因省略 }

这段代码的核心不是 SQL 本身，而是「预编译 + 参数绑定」的习惯。用字符串拼接 SQL 然后把 keyword 直接拼进语句里，搜索框输入'or 1=1--就能把整张表拖出来，这是合作企业里代码评审一票否决的问题。PreparedStatement 的 setObject 会自动处理转义，比拼字符串安全得多。

分页参数这里的 safePage 和 safeSize 是防御性代码。用户完全可以手动改 URL 把 size 改成 9999，不加限制的一次查一万条会让小服务器直接内存溢出。LIMIT 后面的 OFFSET 计算是 (safePage-1)safeSize，第一页 offset 为 0，很多人在这里写错成 pagesize，导致第一页就跳过了前几条数据。

注意：这种防御式处理只是入门级方案。生产级做法是限制最大 offset，超过比如 10000 时直接返回空数据，防止有人翻页翻到几十万页拖垮数据库。毕设阶段做到前两个防御就足够了，但面试时能答出 offset 深翻页问题会加分。

4.2 歌曲上传实现：文件存磁盘、路径存数据库

后台管理要能上传 MP3 和封面图。Servlet 3.0 之后用 @MultipartConfig 注解即可处理 multipart 请求，不需要引 commons-fileupload。文件存储策略上，我建议按日期分子目录，避免一个文件夹里堆几千个文件导致文件系统遍历变慢。

// AdminSongServlet.java 处理歌曲上传 @WebServlet("/admin/song/upload") @MultipartConfig(maxFileSize = 20 * 1024 * 1024, maxRequestSize = 25 * 1024 * 1024) public class AdminSongServlet extends HttpServlet { @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { Part audioPart = req.getPart("audio"); Part coverPart = req.getPart("cover"); String songName = req.getParameter("name"); // 生成存储目录：/upload/audio/20240215/uuid.mp3 String dateDir = new SimpleDateFormat("yyyyMMdd").format(new Date()); String realPath = getServletContext().getRealPath("/upload/audio/" + dateDir); File dir = new File(realPath); if (!dir.exists()) { dir.mkdirs(); } String uuid = UUID.randomUUID().toString().replace("-", ""); String ext = getExtension(audioPart.getSubmittedFileName()); String fileName = uuid + ext; audioPart.write(realPath + File.separator + fileName); // cover 部分逻辑相同，数据库保存相对路径 String audioUrl = "/upload/audio/" + dateDir + "/" + fileName; songDao.insert(songName, audioUrl, coverUrl,...); } }

代码里三个参数值得解释：maxFileSize 限制单个文件 20MB，避免有人传几 G 的文件把磁盘塞满；audioPart.write 是 Part 接口自带方法，写完自动处理临时文件；文件名用 UUID 重命名是为了防止中文文件名乱码和目录遍历攻击，用户的原始文件名不能直接用来拼路径，里面可能带../。

文件存储路径还有一个坑：getRealPath 拿到的是 Tomcat 解压后的目录，很多人发现重启 Tomcat 后上传的文件「丢」了。那是因为重新部署 war 包会把整个目录重写，上传文件被清了。常见做法是把上传目录放到 Tomcat 之外比如/data/music_upload/，然后给 Tomcat 配置虚拟路径映射，或者在代码里写死一个外部绝对路径。毕设阶段用 getRealPath 图省事可以接受，但答辩时主动说出这个缺陷会显得你真的上线过，而不是只跑通演示。

4.3 播放列表与收藏功能：后端渲染还是 AJAX 拼接

前台歌曲列表的基本链路是后端 JSP 渲染循环列表，点击收藏则用 AJAX 发送请求。这里存在一个典型的设计分歧：整个列表用 JSP 循环渲染，还是后端只返回 JSON 然后用 JavaScript 拼 DOM？

JSP 循环渲染适合首屏加载和 SEO；AJAX 拼接适合搜索后无刷新更新列表。我采用的是混合方案：首页榜单用 JSP 渲染，因为要快；搜索结果用 AJAX 局部刷新，因为要保持页面不跳转。两种方案并存才能把「JSP + JavaScript」的结合讲清楚。

// js/search.js 搜索结果的局部刷新 function searchSongs(keyword) { var xhr = new XMLHttpRequest(); xhr.open('GET', '/music/search/api?keyword=' + encodeURIComponent(keyword) + '&page=1', true); xhr.onreadystatechange = function() { if (xhr.readyState === 4 && xhr.status === 200) { var list = JSON.parse(xhr.responseText); renderSongList(list); // 内部用 createElement 生成卡片 } }; xhr.send(); }

这里 encodeURIComponent 不可省略，用户搜索框输入空格、加号、中文时，不编码会导致参数被截断或变成乱码。搜索接口返回 JSON 而不是 HTML 片段，是为了前端拿到数据后可以自由决定渲染形式，将来换 Bootstrap 卡片布局不用动后端。JSON 解析用原生 JSON.parse，老项目里常看到 eval(xhr.responseText) 的写法，那种写法执行任意代码的风险极高，现在没有理由再用。

5. 打包部署与思路梳理：war 包、Tomcat 运行与排查

代码写完后要打包、部署、跑通，这是整篇里最折磨人的环节。传统 JSP 项目和新式前后端分离项目的部署逻辑完全不一样，JSP 文件要在 Tomcat 里被编译成 Servlet 才能运行，所以 Nginx 只放静态文件是不能执行 JSP 的，必须有 Tomcat 在背后做容器。

5.1 传统 JSP 项目打包 war：IDEA 导出与部署路径

IDEA 中「Build → Build Artifacts → Build」可以打出 war 包。前提是在 Project Structure 里把 Artifacts 配置好，Type 选 Web Application Archive，Output directory 选一个你找得到的位置，然后在 Available Elements 里右键 Output Root → Put into Output Root。这一步对第一次做的人会有困惑，但打完第一次包之后整个过程就固定了。

打好的 war 包有两种部署方式。第一种最简单：把 war 文件复制到 Tomcat 的 webapps 目录，启动 Tomcat 后它会自动解压。第二种是通过 Tomcat 的 Manager 界面图形化部署，但默认需要配置 tomcat-users.xml 里的 manager-gui 角色，还要处理本机 IP 访问限制。毕设演示用第一种足够，但推荐两种都了解，因为面试官会问「除了丢 webapps 还有没有别的部署方式」。

# 假设 Tomcat 安装在 /opt/tomcat9 cp /data/build/music.war /opt/tomcat9/webapps/ # 启动并查看日志 cd /opt/tomcat9/bin ./startup.sh tail -f /opt/tomcat9/logs/catalina.out

启动后访问 http://localhost:8080/music/ ，这个 /music/ 是 war 包的名字决定的。如果你把 war 包改名为 ROOT.war，访问路径就是 http://localhost:8080/。这里有个前端开发容易忽略的坑：JSP 页面里写死/music/css/style.css的路径，会把应用名写死在代码里。换一台服务器部署时应用名改了，所有静态资源全部 404。我一般用${pageContext.request.contextPath}拼路径，这样应用名怎么改都不用动页面。

5.2 环境匹配关系：JDK、Tomcat、MySQL 写进一个表里

环境问题在 JSP 项目里占比非常高，而且报错信息很不直观。做这个项目时最省心的组合是 JDK 8 + Tomcat 9 + MySQL 5.7 或 8.0，JDBC 驱动用兼容两者的 5.1.49 或 8.0.33。用新版本 JDK 17 跑老 JSP 项目经常会遇到模块化限制，一个java.lang.NoClassDefFoundError: javax/xml/bind就够卡一天。

Tomcat 10 的一个大坑是：它把 Java EE 的包名从 javax 换成了 jakarta，老 JSP 项目里所有import javax.servlet.*全部编译失败。如果教程或别人代码用的是 Tomcat 10，而你复制过来在 Tomcat 9 上跑，也会因为反向的问题报错。搜索热词里「nginx 支持 jsp 吗」的答案上文已经说了：Nginx 本身不解析 JSP，生产环境常见做法是 Nginx 做静态资源代理、动态请求转发给 Tomcat，这个配置在毕设阶段不要求但知道没坏处。

5.3 常见问题排查：从现象到解决的四条记录

毕设阶段大家问的往往不是架构问题，而是非常具体的报错。以下是我在类似项目里见过最多、也最典型的四类问题，每条按「现象、原因、解决」的顺序说清楚。

Q1：页面报 500 错误，Tomcat 日志里是 java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver

现象是页面能打开，但一查数据库就 500。原因是 mysql-connector-java 的 jar 包没放进 WEB-INF/lib 目录。很多人下载了 jar 放在桌面上，IDEA 里也能编译通过，但打包时没把它打进去。解决方式：把 jar 复制到 webapp/WEB-INF/lib/ 下面，重新打包。注意不能只放在 Tomcat 的 lib 下，因为部署到别的环境时 Tomcat lib 里不一定有这个 jar。

Q2：中文乱码，且 GET 请求和 POST 请求表现不同

GET 请求乱码要改 Tomcat 的 conf/server.xml，在 Connector 节点加URIEncoding="UTF-8"；POST 请求乱码要在所有 Servlet 里request.setCharacterEncoding("UTF-8")。两者成因完全不同，一个是 Tomcat 解码 URL 的默认字符集，一个是请求体解码字符集。只改一处会在另一种请求方式下依旧乱码。还有第三种来源是数据库连接 URL 没加 characterEncoding=utf8，这种情况下数据写进去是乱的，查出来也乱。

Q3：MySQL 报 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'

这个报错在 Linux 上装 MySQL 后很常见，搜索热词里就有人踩过。原因是 mysql 这个命令行客户端默认走 socket 文件连接，但 MySQL 服务没启动，或者 socket 文件路径不对。解决方式：先确认服务是否启动，systemctl status mysqld；如果服务已启动但依旧报错，在连接命令里显式指定 TCP 参数：mysql -h 127.0.0.1 -P 3306 -u root -p。在 Java 代码里发生类似的 Communications link failure，则要查端口是否被防火墙拦截。

Q4：上传的歌曲能写入数据库，WEB-INF/lib 也没缺包，但页面点开没有声音

原因大概率是音频文件的存储在部署目录里丢了。如果用了 getRealPath 存储上传文件，Tomcat 重启或者重新部署 war 包后，上传目录会被覆盖。解决方式：把上传目录配置为 Tomcat 之外，用 context 里的 docBase 做虚拟路径映射。以 Tomcat 9 为例，在 server.xml 或 webapps 目录下的对应 context.xml 里加<Context docBase="/data/music_upload" path="/upload" />，代码里存储路径写/upload/...，外层用 Nginx 或 Tomcat 直接映射，文件和数据分开，问题彻底解决。

这个上传文件的设计缺陷，正好可以展示你对工程的认知深度，主动在答辩里提出来，比被面试官问出来被动解释要有利得多。

6. 能跑通只是第一步：验证与优化的三个习惯

学习这套系统的最后一步，是建立「能跑」和「能用」之间的分界线。我的项目验收习惯是三个动作：第一，写一个简单的 JSP 页面把所有 DAO 方法手动调用一遍，确认每张表的数据都能正确读写，别只靠页面点击，有些隐藏的查询错误在 UI 上不会立刻暴露；第二，用浏览器开发者工具查看网络面板，确认音频请求返回 200 且 Content-Type 是 audio/mpeg，很多「加载不出来」其实是后端把文件当普通流输出，Chrome 无法识别；第三，在正式演示前导出一份 SQL 备份文件，万一演到一半把表结构改坏了可以快速恢复，这个习惯救过我很多次。

进阶层面，我会建议把 DAO 里的 Statement 全部换成 PreparedStatement 并把数据库密码放到 JNDI 配置里，再把 JavaScript 播放器拆成独立模块、把歌曲切换和进度条更新的逻辑分开。这些改动不会让功能界面有任何变化，但代码评审时的观感完全不同。最后说一个我自己的教训：这套系统我先后写过两遍，第一遍把所有页面逻辑都塞在 JSP 里，第二遍才老老实实按 Servlet 控制器加 DAO 分层重写；后者排错时间省了不止一半。新上手的人往往想快点看到页面效果，就去抄那些「一行 JSP 查全库」的代码，短期爽了，后面每一处改动都在还债。宁可前期多用半小时做结构设计，也别在后期用三个通宵填补混乱。希望这篇笔记帮你在做这套在线音乐信息管理系统时，少走一段我走过的弯路。

本文还有配套的精品资源，点击获取