JSP+Servlet网盘系统实战：从环境搭建到权限控制

简介：这是一套面向Java Web初学者与课程设计需求的网盘系统源码，采用JSP+Servlet技术栈，后端以MySQL存储数据，适合作为毕业设计、课程作业或自学练手项目。项目实现了用户管理、文件上传下载、关注关系等核心模块，代码结构清晰，难度适中，便于理解MVC分层与过滤器机制。压缩包共123个文件，约2.28MB，其中22个jsp页面负责视图展示，20个java源文件与20个class文件构成业务逻辑，另有css、js及图片字体等静态资源，以及jar依赖、properties配置和xml描述文件，整体目录完整，导入后按文档配置环境即可运行。目前已有116人学习关注，说明其具备一定的参考价值。读者可获得一套可直接运行的完整项目，用于对照学习Servlet请求处理、过滤器权限控制、DAO数据访问等实现思路，也可在此基础上二次开发，快速完成自己的网盘类应用。

1. 从一堆 .class 文件说起：这套 JSP+Servlet 网盘系统到底能跑出什么

拿到这个压缩包，第一眼看到的不是源码，而是一串.class文件：UserFileDao.class、UserServlet.class、UploadServlet.class、DownloadServlet.class、LoginFilter.class……很多人会愣一下——这是编译产物，不是源码。但恰恰是这一点，说明这套 JSP+Servlet 网盘系统是「本地编译过、能直接跑」的状态，而不是那种丢给你一堆报错的半成品。它解决的核心问题很明确：用最传统的 JavaWeb 技术栈，把「用户注册登录 → 上传文件 → 文件列表 → 下载 → 关注/权限控制」这条网盘主链路完整走通，数据库用 MySQL 存元数据，Servlet 做控制层，JSP 做展示层，Filter 做登录拦截和下载鉴权。适合谁？正在做 JavaWeb 课程设计、毕设选题落在「基于 JSP 的网盘/文件管理」方向、或者想拿一个能跑的传统 MVC 项目对照理解 Servlet 生命周期和 Filter 链的人。如果你只想要 SpringBoot 那套注解式开发，这套东西会让你觉得「怎么这么多 web.xml 和手动转发」，但它能让你看清一个请求从浏览器到数据库再回到页面的完整路径。

2. 环境落地：Tomcat、MySQL 与项目导入的完整链路

2.1 为什么这套项目必须用 Tomcat 而不是内嵌容器

这套资源的技术栈是 JSP + Servlet + MySQL，没有 SpringBoot 的内嵌 Tomcat，所以你不能像跑 SpringBoot 那样java -jar一把梭。JSP 需要 Servlet 容器编译成 Servlet 再执行，Tomcat 是最常见的选择。常见做法是 Tomcat 8.5 或 9.0，JDK 用 8 或 11，MySQL 用 5.7 或 8.0。这里有个选型理由：Tomcat 9 对应 Servlet 4.0，Tomcat 8.5 对应 Servlet 3.1，这套项目的web.xml版本和 Filter 写法在两者上都能跑，但如果你用 Tomcat 10，包名从javax.servlet变成jakarta.servlet，所有 Servlet 和 Filter 的 import 都会报错，这是第一个大坑。所以别追新，Tomcat 9 是稳妥线。

MySQL 这边，项目里大概率有一张user表、一张file表、可能还有follow表。你需要先建库，字符集用utf8mb4，排序规则utf8mb4_general_ci，否则中文文件名会乱码。数据库连接信息通常在src下的db.properties或某个DBUtil类里，改之前先全局搜jdbc:mysql。

2.2 导入 IDEA 并配置 Artifact 的实操步骤

把压缩包解压后，目录结构一般是src、WebContent（或web）、WebContent/WEB-INF/lib。用 IDEA 导入时选「Existing Sources」或直接 Open 项目根目录，然后手动配置 Facet。

# 先确认 JDK 和 Tomcat 版本 java -version # 输出应为 1.8.x 或 11.x # 查看 Tomcat 目录下的 lib 是否有 servlet-api.jar ls $CATALINA_HOME/lib/servlet-api.jar

上面两条命令是动手前的自检：JDK 版本决定编译级别，servlet-api.jar存在说明 Tomcat 装完整了。接下来在 IDEA 里：

1. File → Project Structure → Modules，把src标记为 Sources，WebContent标记为 Web Resource Directory，WEB-INF/web.xml指向正确路径。
2. Libraries里添加WebContent/WEB-INF/lib下所有 jar，以及 Tomcat 的servlet-api.jar、jsp-api.jar。
3. Artifacts里新建Web Application: Exploded，输出目录默认即可。
4. Run → Edit Configurations，加一个 Tomcat Local，Deployment 选刚才的 Artifact，Application context 设成/netdisk或/。

参数说明：Application context 决定访问路径，如果设成/netdisk，浏览器就要访问http://localhost:8080/netdisk/login.jsp；设成/则直接http://localhost:8080/login.jsp。很多人导入后 404，九成是 Artifact 没配或 context 写错。

2.3 数据库初始化与连接池配置

项目里如果有c3p0-config.xml或druid.properties，说明用了连接池；如果只是DriverManager.getConnection，那就是直连。直连在并发上传时容易耗尽连接，常见做法是换成 Druid 或 HikariCP，但为了先跑通，直连也能用。

-- 建库建表的最小示例，字段名以项目实际为准 CREATE DATABASE netdisk DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE netdisk; CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE file ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, filename VARCHAR(255) NOT NULL, filepath VARCHAR(500) NOT NULL, upload_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES user(id) );

这段 SQL 的逻辑是：user表存账号，file表存文件元数据，filepath存服务器上的真实路径而不是文件内容本身，这是网盘系统的标准做法——数据库只记「谁在什么时候传了什么文件、放在哪」，文件实体落在磁盘目录。参数上注意filename用VARCHAR(255)是因为中文文件名按 utf8mb4 算，255 字符足够；filepath给 500 是防止深层目录拼接后超长。执行完把连接信息填回项目配置文件，启动 Tomcat，看到登录页就算环境通了。

3. Servlet 与 Filter 协作：登录、上传、下载的请求链路拆解

3.1 LoginFilter 与 DownloadFilter 的拦截顺序

这套项目里有两个 Filter 特别关键：LoginFilter和DownloadFilter。LoginFilter拦的是「没登录不能看文件列表」，DownloadFilter拦的是「没权限不能下载别人的文件」。Filter 的执行顺序由web.xml里<filter-mapping>的声明顺序决定，或者用@WebFilter时按类名排序，这点很玄学，建议在web.xml里显式写死。

<!-- web.xml 中 Filter 声明顺序决定执行顺序 --> <filter> <filter-name>LoginFilter</filter-name> <filter-class>com.netdisk.filter.LoginFilter</filter-class> </filter> <filter-mapping> <filter-name>LoginFilter</filter-name> <url-pattern>/user/*</url-pattern> <url-pattern>/file/*</url-pattern> </filter-mapping> <filter> <filter-name>DownloadFilter</filter-name> <filter-class>com.netdisk.filter.DownloadFilter</filter-class> </filter> <filter-mapping> <filter-name>DownloadFilter</filter-name> <url-pattern>/download</url-pattern> </filter-mapping>

逻辑说明：LoginFilter映射到/user/*和/file/*，意味着访问用户中心和文件操作前先检查 session 里有没有user对象；DownloadFilter只映射/download，在下载前多一层「这个文件是不是你的或你有没有关注分享者」的判断。参数上<url-pattern>的粒度要控制好，映射太宽会把登录页也拦了，导致死循环重定向。常见做法是放行/login、/register、静态资源。

3.2 UploadServlet 的文件落盘与重名处理

UploadServlet是这套系统的核心写入点。它接收multipart/form-data，解析出文件名和字节流，然后写到服务器某个目录，再把路径写进file表。

// UploadServlet 核心逻辑示意 @WebServlet("/upload") public class UploadServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 1. 获取上传目录，通常配置在 web.xml 或常量类 String saveDir = getServletContext().getRealPath("/uploads"); File dir = new File(saveDir); if (!dir.exists()) dir.mkdirs(); // 2. 解析文件名，处理重名 String originalName = req.getParameter("filename"); String ext = originalName.substring(originalName.lastIndexOf(".")); String storedName = UUID.randomUUID().toString() + ext; // 3. 写文件 Part part = req.getPart("file"); part.write(saveDir + File.separator + storedName); // 4. 写数据库 User user = (User) req.getSession().getAttribute("user"); new UserFileDao().insert(user.getId(), originalName, storedName); } }

逻辑说明：第 1 步用getRealPath拿到的是部署目录下的路径，重启 Tomcat 后如果重新部署，这个目录可能被清空，所以生产环境要配外部目录。第 2 步用 UUID 重命名是为了避免同名文件互相覆盖，原始文件名单独存数据库用于展示。第 3 步part.write是 Servlet 3.0 的 API，前提是@MultipartConfig注解或web.xml里配了multipart-config，否则getPart返回 null。参数上UUID.randomUUID()碰撞概率极低，但如果你要保留扩展名，注意lastIndexOf(".")在文件名没有点时返回 -1，会抛异常，加个判断。

3.3 DownloadServlet 的流式输出与断点续传边界

DownloadServlet负责把文件从磁盘读出来写回响应流。最简版本是设置Content-Disposition和Content-Type，然后Files.copy。

@WebServlet("/download") public class DownloadServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String fileId = req.getParameter("id"); UserFile uf = new UserFileDao().findById(Integer.parseInt(fileId)); if (uf == null) { resp.sendError(404); return; } File file = new File(getServletContext().getRealPath("/uploads"), uf.getStoredName()); resp.setContentType("application/octet-stream"); resp.setHeader("Content-Disposition", "attachment; filename=" + URLEncoder.encode(uf.getFilename(), "UTF-8")); resp.setContentLengthLong(file.length()); try (InputStream in = new FileInputStream(file); OutputStream out = resp.getOutputStream()) { byte[] buf = new byte[8192]; int len; while ((len = in.read(buf)) != -1) { out.write(buf, 0, len); } } } }

逻辑说明：Content-Disposition里的文件名必须 URL 编码，否则中文名在浏览器下载时会变成乱码或截断。setContentLengthLong告诉浏览器文件大小，这样下载进度条才准。缓冲区 8192 字节是常见值，太小频繁 IO，太大占内存。断点续传这套代码没实现，如果客户端发Range头，服务器会忽略并返回完整文件，大文件下载体验差，但作为课程设计够用。想加断点续传，需要解析Range头、设置206 Partial Content、用RandomAccessFile定位，这是进阶方向。

4. 避坑与排查：从 404 到中文乱码的五个血泪现场

4.1 启动后 404，日志里连 Servlet 都没加载

现象：Tomcat 启动无报错，访问login.jsp能开，但提交表单后 404。原因：web.xml里servlet-mapping的url-pattern和表单action不一致，或者@WebServlet注解没生效（web.xml的metadata-complete="true"会忽略注解）。解决：先看 Tomcat 启动日志有没有Servlet [xxx] initialized，没有就是没注册；再核对action路径，注意 context path 是否重复。

4.2 上传大文件报FileSizeLimitExceededException

现象：传小文件正常，传几十 MB 就抛异常。原因：@MultipartConfig默认maxFileSize是 -1（不限），但如果你在web.xml里配了<multipart-config>且设了max-file-size，就会触发。另外 Tomcat 的maxSwallowSize和连接器maxPostSize也会限制。解决：在@MultipartConfig(maxFileSize = 104857600)显式设大，同时检查server.xml的 Connector 有没有maxPostSize="0"（0 表示不限）。

4.3 中文文件名下载后变成%E4%B8%AD%E6%96%87

现象：下载下来的文件名是一串百分号编码。原因：Content-Disposition里直接放了未编码的中文，或者用了URLEncoder.encode但浏览器不认。解决：用URLEncoder.encode(filename, "UTF-8").replace("+", "%20")，或者按 RFC 5987 写filename*=UTF-8''格式。不同浏览器行为不一致，这是经典玄学，建议两种都带上。

4.4 MySQL 连接报Public Key Retrieval is not allowed

现象：MySQL 8.0 下连接失败，提示公钥检索不允许。原因：MySQL 8 默认用caching_sha2_password认证插件，旧版 JDBC 驱动不兼容。解决：连接串加allowPublicKeyRetrieval=true&useSSL=false，或者把用户认证插件改成mysql_native_password。注意useSSL=false只是本地开发图省事，生产环境要配证书。

4.5 Filter 里重定向后请求又被拦一次

现象：未登录访问受保护页面，LoginFilter重定向到login.jsp，结果login.jsp也被拦，无限重定向。原因：url-pattern映射了/*或包含了登录页路径。解决：在 Filter 里判断请求 URI，如果是login.jsp、login、register、静态资源后缀，直接chain.doFilter放行。这个判断要写在重定向之前。

5. 进阶技巧：用 UserFollowDao 做文件分享与权限校验的闭环

UserFollowDao这个类名透露了一个信息：这套网盘不只是「自己传自己下」，还有「关注」关系，可能是关注某个用户后能看他的分享文件。这就把权限模型从「文件属于谁」扩展到了「谁关注了谁」。我一般会这样设计校验逻辑：下载请求进来，先查文件归属，如果file.user_id == session.user.id，直接放行；否则查follow表，看当前用户有没有关注文件所有者，且文件是否标记为「公开分享」。两个条件都满足才允许下载，否则返回 403。

// DownloadFilter 中的权限判断片段 int fileOwnerId = userFile.getUserId(); int currentUserId = ((User) req.getSession().getAttribute("user")).getId(); if (fileOwnerId != currentUserId) { boolean isFollowing = new UserFollowDao() .exists(currentUserId, fileOwnerId); boolean isShared = userFile.getIsShared() == 1; if (!isFollowing || !isShared) { resp.sendError(HttpServletResponse.SC_FORBIDDEN); return; } } chain.doFilter(req, resp);

逻辑说明：exists方法查follow表里有没有(follower_id, followee_id)这条记录，isShared是file表的一个标志位。参数上注意isShared用tinyint(1)存，Java 里映射成int或boolean都行，但 JDBC 读出来可能是0/1，别直接当boolean用。这个闭环做完，你的网盘就从「单用户文件柜」变成了「带社交属性的分享系统」，毕设答辩时这是加分项。

验证方法：注册两个账号 A 和 B，A 上传文件并设为分享，B 不关注 A 时下载应 403；B 关注 A 后再下载应成功；A 取消分享后 B 再下载又变 403。这三步走通，说明 Filter 链和 DAO 查询都对上了。

从那以后我每次拿到这种传统 JavaWeb 项目，都强制先跑一遍「注册→登录→上传→列表→下载→越权下载」这条主链路，再去看代码。因为环境问题和权限漏洞，永远是在跑通之后才会暴露。希望帮到你。

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