尧图网页设计 
简介这是一套基于Java构建的开源文档管理/企业网盘系统源码面向需要私有化部署或二次开发的企业团队、Java开发者及运维人员。平台以瀚为云文档协作平台为原型支持企业文件与个人文件分库管理提供收藏夹、最近打开、回收站等分区并具备统一存储、共享协作、权限控制、文件上传/重命名/移动/复制/标签/锁定/预览及动态跟踪等完整功能适合用于搭建内部文档中心或学习企业级文件管理架构。资源包共793个文件约11.79MB主要包含254个Java源文件、168个BCMap字体映射文件、109个PNG图片、103个JavaScript文件、45个HTML页面及19个Less样式文件等Java与前端资源占比均衡便于阅读核心逻辑与界面实现。已有459人浏览学习。解压后可直接导入开发工具查看代码结构适合需要参考完整网盘设计思路、进行功能扩展或技术选型评估的开发者。1. 基于Java的开源文档管理平台缺的不是功能而是骨架在企业内部搜“开源网盘”最先跳出来的往往是 Nextcloud、Seafile 这类 PHP/C 系产品真正以 Java 为主栈的成熟开源文档管理平台反而少。而我们实际接手内部系统时要的又不是一个装完即用的黑盒而是一套能嵌进现有权限体系、能改存储策略、能接 OnlyOffice 在线编辑的工程骨架。这就是“设计源码”在题目里的真正分量它指向一个围绕 Java、Spring Boot、对象存储和分片上传协议构建的可二次开发的文档管理平台方案。这篇文章按我平时搭这类系统的顺序来讲先做技术选型和存储抽象再把上传链路秒传、分片、断点续传落地然后补上权限、预览、检索这些企业网盘的必备能力最后给一个上线前必须做的一致性核对技巧。全程可以照着写代码、调参数。2. 先用 Java 把工程骨架搭起来选型、存储抽象、表结构2.1 为什么选 Spring Boot而不是 SSM 那套老架构网上搜“Java 文档管理平台源码”确实还能翻到不少 SSM JSP 的旧项目甚至还有“基于 SSM 的学生信息管理系统”之类同批次的毕设代码。它们能跑通演示但真要拿来做企业网盘我会直接把 SSM 方案否掉。网盘的核心操作是文件上传下载和高并发读写Spring Boot 的自动配置、spring-boot-starter-data-redis、spring-boot-starter-security 能在一小时内把骨架搭到“能存文件、能传分片”的状态而 SSM 时代的 XML 配置和 JSP 渲染在前后端分离的项目里反而成了负担。工程结构上用多模块 Maven 项目至少拆出api控制器和 DTO、core业务逻辑和接口定义、storage存储适配三个模块。这样做的理由在于文件上传接口之后大概率会适配不同的存储后端本地磁盘、MinIO、阿里云 OSS把存储抽象独立成模块后面切换底层只改依赖不碰业务代码。2.2 存储层设计成接口底下一半是本地磁盘、一半是 MinIO企业网盘的存储选型我一般会给一个两级策略开发环境用本地磁盘生产环境用 MinIO 这类 S3 兼容对象存储。两者的操作语义可以收敛到一个StorageService接口里。先说为什么不是 MongoDB GridFS——GridFS 在千兆内网存小文件还行但大文件的分片读写和对象存储的 S3 协议生态完全是两回事MinIO 的 presigned URL 能直接让浏览器直传GridFS 做不到这种解耦。public interface StorageService { String put(InputStream input, String objectName, long contentLength) throws IOException; InputStream get(String objectName) throws IOException; void delete(String objectName) throws IOException; ListString listAllObjects(); String presignedPutUrl(String objectName, int expirySeconds); String presignedGetUrl(String objectName, int expirySeconds); }put方法接收输入流和文件长度presignedPutUrl是给前端直传用的。本地实现直接往配置好的根目录写文件MinIO 实现则用 AmazonS3Client 封装。参数上注意三点MinIO 的region在单机部署时填us-east-1也能跑通但建议统一配置presignedPutUrl的过期时间我一般给 300 秒太短会导致大分片传不完太长又会把 bucket 的写权限暴露给外部太久contentLength在上传接口里用于预分配对象大小不要填 0 或省略否则对象存储端的分片合并策略可能走默认小对象路径。2.3 文档表和分片表怎么设计别把文件二进制放进数据库文件本体放对象存储数据库只放元数据这是网盘和普通附件系统的根本区别。下面这套表结构我沿用了几次字段不多但覆盖了秒传判断、分片追踪、用户归属三个核心诉求CREATE TABLE file_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, file_identifier CHAR(40) NOT NULL COMMENT 前端计算的文件指纹(SHA-1), file_name VARCHAR(255) NOT NULL, file_size BIGINT NOT NULL, chunk_size INT NOT NULL DEFAULT 5242880 COMMENT 默认分片大小 5MB, total_chunks INT NOT NULL, storage_path VARCHAR(512), uploader_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0:待上传 1:上传中 2:合并中 3:可用 4:已删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_identifier (file_identifier) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;file_identifier是全链路的关键字段前端把整个文件的哈希算出来后先发预检请求服务端查这张表已存在且状态为 3直接返回“秒传成功文件已有引用”不存在则新建一条状态为 1 的记录并把storage_path预留出来。status字段要好好维护合并完成后置为 3删除时置为 4 而不是真的立刻删数据方便后续审计追溯。分片追踪不建表用 Redis 的 Set 更合适下一章会讲。3. 企业网盘上传链路把秒传、断点续传和分片合并一次说清3.1 先想清楚上传状态机这在 Java 面试里都是常客大文件上传这套题在 Java 面试八股文里出现频率很高很多答案只停留在“前端 slice、后端接 chunk、最后合并”的粗粒度上真正落地要拆成四个状态预检查询文件指纹、上传分片并行传多个 chunk、合并服务端按序拼文件、回执更新元数据状态。这四个状态对应接口就是POST /api/file/precheck、POST /api/file/chunk、POST /api/file/merge。预检接口的返回要包含三件事该文件是否已存在、已存在时直接返回文件 ID、未存在时返回分片大小和总分片数。前端拿到分片大小后再决定每个 chunk 怎么切。分片大小不能拍脑袋定我一般按网络环境来内网给 10MB公网给 2MB 到 5MB。分片设得过大单片上传失败重试成本高设得过小对象数量膨胀合并时打开文件的次数也会线性上升。3.2 文件指纹要在浏览器端算别把 hash 压力丢给服务端秒传的前提是拿到整个文件的哈希。如果把这个计算放到服务端用户传完整个文件服务端才能给出指纹秒传就形同虚设了。前端的标准做法是 Web Worker 里跑 SparkMD5分片读取文件逐段 append算完后再发预检请求。// web-worker.js self.onmessage function (e) { const file e.data.file; const chunkSize e.data.chunkSize || 5 * 1024 * 1024; const spark new SparkMD5.ArrayBuffer(); let current 0; const totalChunks Math.ceil(file.size / chunkSize); function next() { const start current * chunkSize; const end Math.min(file.size, start chunkSize); const reader new FileReader(); reader.onload (ev) { spark.append(ev.target.result); current; if (current totalChunks) { self.postMessage({ progress: current / totalChunks }); next(); } else { self.postMessage({ hash: spark.end() }); } }; reader.readAsArrayBuffer(file.slice(start, end)); } next(); };这段代码的逻辑是用file.slice切出每一片FileReader逐片读成 ArrayBuffer 并追加到 SparkMD5 实例里。参数上注意chunkSize要与服务端配置一致否则同一个文件在不同端算出的分片策略不一致后续断点续传的分片索引会错位。2GB 文件按 5MB 分片需要循环 400 次左右在 Worker 里跑不会阻塞主线程这是把 hash 计算放 Worker 的根本原因也是和直接在页面主线程里算的关键区别。3.3 服务端分片追踪Redis 里的 Set 比数据库行更划算分片上传接口每收到一个 chunk就要记录“这个文件已经传到了第几片”。用数据库行记录不是不行但每片一次 UPDATE 会让数据库成为并发瓶颈。我用 Redis 的 Set 结构存已收到的分片序号Set 天然去重重复上传同一片只是幂等覆盖不会产生脏数据。PostMapping(/chunk) public Result uploadChunk(RequestParam String fileIdentifier, RequestParam Integer chunkIndex, RequestParam MultipartFile chunk) { String key upload:chunks: fileIdentifier; storageService.put(chunk.getInputStream(), fileIdentifier / chunkIndex, chunk.getSize()); redisTemplate.opsForSet().add(key, chunkIndex); redisTemplate.expire(key, Duration.ofHours(24)); Long uploaded redisTemplate.opsForSet().size(key); Integer totalChunks fileInfoService.getTotalChunks(fileIdentifier); MapString, Object data new HashMap(); data.put(uploadedChunks, uploaded); data.put(totalChunks, totalChunks); data.put(canMerge, uploaded totalChunks); return Result.success(data); }chunkIndex是前端切分时从 0 开始的递增序号服务端把它作为 Set 的元素同时用这个序号拼出对象存储里的对象名文件指纹/序号保证同一个文件的各个分片在对象存储里也是结构化存放。Redis 的expire参数给 24 小时但要注意现在的写法在每次收到分片时都会续期也就是说只要用户还在持续上传key 就不会消失如果希望“超过 24 小时没有新分片自动清掉”改成只在第一次 add 时设置过期时间即可。canMerge作为一个尽早通知的字段返回给前端实际合并请求仍由前端在最后一片传完后显式发起。3.4 并发分片不保证有序合并时要补两道校验分片上传的并发是前端用多个请求同时发的服务端收到分片的顺序毫无保证。合并时如果按“先到先写”的方式落到同一个文件结果一定错乱。正确做法是确认 Redis 中分片数量等于totalChunks后按序号顺序写入目标文件。用 Java 的 FileChannel 做零拷贝式合并不把整块数据读进 JVM 内存这是大文件合并避免 OOM 的关键。PostMapping(/merge) public Result merge(RequestParam String fileIdentifier) { Integer totalChunks fileInfoService.getTotalChunks(fileIdentifier); String key upload:chunks: fileIdentifier; if (redisTemplate.opsForSet().size(key) totalChunks) { return Result.error(分片不全无法合并); } Path targetPath Paths.get(config.getMergeDir(), fileIdentifier .file); try (FileChannel out FileChannel.open(targetPath, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) { for (int i 0; i totalChunks; i) { Path partPath Paths.get(config.getChunkDir(), fileIdentifier, String.valueOf(i)); try (FileChannel in FileChannel.open(partPath, StandardOpenOption.READ)) { long offset (long) i * config.getChunkSize(); long written 0; while (written in.size()) { written out.transferFrom(in, offset written, in.size() - written); } } } } // 对合并结果做 MD5 校验与前端指纹记录比对 String mergedMd5 DigestUtils.md5Hex(Files.newInputStream(targetPath)); if (!mergedMd5.equalsIgnoreCase(expectedMd5)) { return Result.error(合并结果校验失败); } fileInfoService.updateStatus(fileIdentifier, 3, targetPath.toString()); return Result.success(合并完成); }这段合并代码的三个参数要解释清楚。config.getChunkSize()必须与 Redis 里记录的分片大小一致它决定每个分片在最终文件里的起始偏移量offset如果这个值中途被改过文件就会中间出现空洞或重叠。transferFrom是 FileChannel 的零拷贝传输方法不需要手动申请 byte[]分片大小是 10MB 时单循环内存占用几乎可以忽略。合并后的 MD5 校验是第二道安全网它把合并产物与前端算出的file_identifier做比对防止前端把同一个文件的某个分片传错比如同名不同内容导致静默数据损坏。服务端如果走异步合并可以用CompletableFuture.allOf等待所有分片落盘完成再触发 merge 流程注意给allOf加超时时间避免某个分片永远不出现导致的线程悬挂。4. 文档管理平台的权限、预览和检索企业网盘和普通网盘的区别4.1 用 RBAC 加资源级 ACL 做权限模型企业网盘不能像个人网盘一样“登录就能看全部文件”。权限模型我用两层第一层是基于角色的 RBAC控制用户能进入哪些功能模块比如“上传”“删除”“管理用户”第二层是基于资源的 ACL控制某个具体文档能被谁下载、谁能预览。ACL 这张表的权限位用整数按位存储1表示可预览2表示可下载4表示可编辑8表示可管理。CREATE TABLE document_acl ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_id BIGINT NOT NULL, subject_type VARCHAR(16) NOT NULL COMMENT USER 或 DEPT, subject_id BIGINT NOT NULL, permission INT NOT NULL DEFAULT 1, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_doc (doc_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;Spring Security 里我用PreAuthorize(docAuthService.check(#docId, download))这样的注解切到方法级别比在 Controller 里手写 if-else 判断要干净得多。check方法先加载当前用户的角色集合再查document_acl最后用(permission 2) ! 0判断是否有下载权限。这个按位与的设计在权限叠加时比较省心比如某部门有“预览下载”permission 存 3后面若要追加编辑权限ACL 更新时做一次permission | 4不需要重写整行。4.2 接入 OnlyOffice 让 Office 文档在线可编辑企业网盘和普通网盘的分水岭是文档能不能在线预览和协作编辑。开源方案里 OnlyOffice 和 KkFileView 是两条路线KkFileView 偏预览把 docx、xlsx 转成 PDF 后给浏览器渲染集成简单OnlyOffice 偏编辑能直接在线改 docx。热词里“java 进行 onlyoffice 在线编辑文书”问的就是 OnlyOffice 的 Java 集成这里给出关键配置。{ document: { fileType: docx, key: file_identifier_md5, title: 季度报告.docx, permissions: { edit: true, download: true }, url: http://your-server:8080/api/preview/raw/1001, callbackUrl: http://your-server:8080/api/onlyoffice/callback }, documentType: word }url是 OnlyOffice 服务器去拉取文档原文件的地址注意这里必须是服务端能访问到的地址不能是前端浏览器地址callbackUrl是 OnlyOffice 在用户编辑保存后回调业务系统的接口用来把新版本写回对象存储。两者都需要做 JWT 签名校验只在 OnlyOffice 服务端和业务服务端之间共享密钥否则任何人拼一个回调 URL 就能把任意内容写进你的网盘。部署 OnlyOffice DocumentServer 时注意要能访问外网做许可证验证离线环境下要提前准备好 license 文件否则在线编辑功能会每隔一段时间就断开。4.3 全文检索轻量方案先上 MySQL规模大了再上 ES文档管理平台的搜索通常分两层文件名搜索和文件内容搜索。文件名搜索用 MySQL 就够了加个普通索引就好。文件内容搜索看规模和预算我实践下来的选择还比较明确方案适合规模部署成本中文分词实时性MySQL LIKE万级文件内零无即时MySQL 全文索引 ngram十万级文件低原生 ngram秒级Elasticsearch百万级以上高IK 分词秒级内容搜索的前提是能把 docx、pdf 抽成纯文本。Java 生态的 Apache Tika 是常见选择它能解析上百种格式。抽取出的文本存一份到file_content表或直接进 ES搜索时优先查文件名再加一个文件内容的加权字段。{ query: { bool: { must: [ { term: { ownerId: 1001 } } ], should: [ { match: { fileName: { query: 季度报告, boost: 3 } } }, { match: { contentText: { query: 季度报告, boost: 1 } } } ] } } }搜索权限不能漏ES 查询里ownerId这个 term 必须动态拼入当前用户及其可见部门不能只查文件内容不查权限。这个是我能讲的坑很多网盘系统做全文检索时只把索引里的数据展示出来结果用户搜到了别人的机密文件。4.4 审计日志和下载水印要用异步写别拖慢文件下载企业网盘上线后审计需求一定会有谁在什么时间下载了哪个文件。审计日志如果用同步写数据库每下载一次就多一次 DB 事务文件稍大时下载响应时间会被明显拉长。我的方案是 Spring AOP 切下载接口把审计事件丢进线程池异步落库。4.4.1 用注解加 SpEL 表达式捞出操作对象定义AuditLog(action DOWNLOAD, resource #docId)注解切面里用 SpEL 解析#docId参数得到文档 ID再结合 SecurityContext 里的用户信息和时间戳拼成一条审计记录。时间戳统一用 UTC 存展示时按用户时区转换这里有个典型的坑如果审计记录直接存本地时间跨时区的团队查日志时看到的时间戳会像代码签入 SCM 里的时区乱码一样错位排查纠纷时很头疼。4.4.2 下载响应动态打水印敏感文档建议在下载或预览时动静脉注入水印水印内容一般取当前用户名加时间例如“张工 2025-03-18 14:30”渲染在 PDF 每一页底部。Java 侧用 PDFBox 打开文档流叠加水印文字后再输出文件名保持原样但内容已带追踪信息。5. 用一致性核对脚本给设计源码做数据面体检5.1 网盘里最容易被忽略的“孤儿文件”分片上传有各种中断路径用户传到一半关掉页面Redis 里的分片记录过期但对象存储里的分片文件还在合并完成后合并目录下的分片文件没清干净更麻烦的是“断链”即file_info表里状态是 3可用但对象存储里的实际文件已经被误删或过期。这两类问题在演示项目里不影响跑通流程一旦上了生产会变成存储成本黑洞和权限追溯的盲区。所以源码里光有上传下载还不够必须有一个“元数据表与对象存储的定期对账”机制。5.2 用 Spring 定时任务几十行做个对账下面的核对 Job 会枚举对象存储里的全部对象和数据库里的storage_path集合做差集输出孤儿文件和断链文件两份清单。Component public class StorageReconcileJob { Scheduled(cron 0 30 2 * * ?) public void reconcile() { SetString dbPaths fileInfoMapper.selectAllStoragePaths(); ListString objectKeys storageService.listAllObjects(); ListString orphanFiles objectKeys.stream() .filter(key - !dbPaths.contains(key)) .collect(Collectors.toList()); ListString brokenReferences dbPaths.stream() .filter(path - !objectKeys.contains(path)) .collect(Collectors.toList()); reconcileLogService.save(orphanFiles, brokenReferences); } }cron表达式是每天凌晨 2:30 执行选凌晨是因为这时的上传操作最少扫描对 IO 影响小。selectAllStoragePaths把数据库侧全部路径拉出来注意当文件数量超过十万时全量listAllObjects不再合适应该按日期前缀比如上传月份分批枚举每批单独对账避免一次加载几十万对象到内存。orphanFiles对应对象存储有但数据库没有的对象brokenReferences对应数据库有但存储文件缺失的记录。前者需要下架后者需要告警和人工恢复两类异常的处理方式必须分开。5.3 把异常清单当成上线前的验收标准对账 Job 写完不是摆设我一般把它纳入发版检查项。单测里可以构造一个假分片对象再手动调用 reconcile断言orphanFiles长度变化集成测试里则用测试 MinIO 桶先塞一个无元数据的对象再验证 Job 能识别出来。上线后的第一个月每天看一眼清单数量变化趋势如果孤儿文件数量持续下降说明删除接口工作正常如果断链记录反复出现基本可以断定对象存储的某个生命周期规则误配了比如 MinIO 的过期删除策略把未更新的对象吞掉了。把这些数据接进监控告警比用户报“我的文件打不开”早一步发现问题。本文还有配套的精品资源点击获取 基于Java的企业网盘系统：分片上传与权限设计实践
简介这是一套基于Java构建的开源文档管理/企业网盘系统源码面向需要私有化部署或二次开发的企业团队、Java开发者及运维人员。平台以瀚为云文档协作平台为原型支持企业文件与个人文件分库管理提供收藏夹、最近打开、回收站等分区并具备统一存储、共享协作、权限控制、文件上传/重命名/移动/复制/标签/锁定/预览及动态跟踪等完整功能适合用于搭建内部文档中心或学习企业级文件管理架构。资源包共793个文件约11.79MB主要包含254个Java源文件、168个BCMap字体映射文件、109个PNG图片、103个JavaScript文件、45个HTML页面及19个Less样式文件等Java与前端资源占比均衡便于阅读核心逻辑与界面实现。已有459人浏览学习。解压后可直接导入开发工具查看代码结构适合需要参考完整网盘设计思路、进行功能扩展或技术选型评估的开发者。1. 基于Java的开源文档管理平台缺的不是功能而是骨架在企业内部搜“开源网盘”最先跳出来的往往是 Nextcloud、Seafile 这类 PHP/C 系产品真正以 Java 为主栈的成熟开源文档管理平台反而少。而我们实际接手内部系统时要的又不是一个装完即用的黑盒而是一套能嵌进现有权限体系、能改存储策略、能接 OnlyOffice 在线编辑的工程骨架。这就是“设计源码”在题目里的真正分量它指向一个围绕 Java、Spring Boot、对象存储和分片上传协议构建的可二次开发的文档管理平台方案。这篇文章按我平时搭这类系统的顺序来讲先做技术选型和存储抽象再把上传链路秒传、分片、断点续传落地然后补上权限、预览、检索这些企业网盘的必备能力最后给一个上线前必须做的一致性核对技巧。全程可以照着写代码、调参数。2. 先用 Java 把工程骨架搭起来选型、存储抽象、表结构2.1 为什么选 Spring Boot而不是 SSM 那套老架构网上搜“Java 文档管理平台源码”确实还能翻到不少 SSM JSP 的旧项目甚至还有“基于 SSM 的学生信息管理系统”之类同批次的毕设代码。它们能跑通演示但真要拿来做企业网盘我会直接把 SSM 方案否掉。网盘的核心操作是文件上传下载和高并发读写Spring Boot 的自动配置、spring-boot-starter-data-redis、spring-boot-starter-security 能在一小时内把骨架搭到“能存文件、能传分片”的状态而 SSM 时代的 XML 配置和 JSP 渲染在前后端分离的项目里反而成了负担。工程结构上用多模块 Maven 项目至少拆出api控制器和 DTO、core业务逻辑和接口定义、storage存储适配三个模块。这样做的理由在于文件上传接口之后大概率会适配不同的存储后端本地磁盘、MinIO、阿里云 OSS把存储抽象独立成模块后面切换底层只改依赖不碰业务代码。2.2 存储层设计成接口底下一半是本地磁盘、一半是 MinIO企业网盘的存储选型我一般会给一个两级策略开发环境用本地磁盘生产环境用 MinIO 这类 S3 兼容对象存储。两者的操作语义可以收敛到一个StorageService接口里。先说为什么不是 MongoDB GridFS——GridFS 在千兆内网存小文件还行但大文件的分片读写和对象存储的 S3 协议生态完全是两回事MinIO 的 presigned URL 能直接让浏览器直传GridFS 做不到这种解耦。public interface StorageService { String put(InputStream input, String objectName, long contentLength) throws IOException; InputStream get(String objectName) throws IOException; void delete(String objectName) throws IOException; ListString listAllObjects(); String presignedPutUrl(String objectName, int expirySeconds); String presignedGetUrl(String objectName, int expirySeconds); }put方法接收输入流和文件长度presignedPutUrl是给前端直传用的。本地实现直接往配置好的根目录写文件MinIO 实现则用 AmazonS3Client 封装。参数上注意三点MinIO 的region在单机部署时填us-east-1也能跑通但建议统一配置presignedPutUrl的过期时间我一般给 300 秒太短会导致大分片传不完太长又会把 bucket 的写权限暴露给外部太久contentLength在上传接口里用于预分配对象大小不要填 0 或省略否则对象存储端的分片合并策略可能走默认小对象路径。2.3 文档表和分片表怎么设计别把文件二进制放进数据库文件本体放对象存储数据库只放元数据这是网盘和普通附件系统的根本区别。下面这套表结构我沿用了几次字段不多但覆盖了秒传判断、分片追踪、用户归属三个核心诉求CREATE TABLE file_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, file_identifier CHAR(40) NOT NULL COMMENT 前端计算的文件指纹(SHA-1), file_name VARCHAR(255) NOT NULL, file_size BIGINT NOT NULL, chunk_size INT NOT NULL DEFAULT 5242880 COMMENT 默认分片大小 5MB, total_chunks INT NOT NULL, storage_path VARCHAR(512), uploader_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0:待上传 1:上传中 2:合并中 3:可用 4:已删除, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_identifier (file_identifier) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;file_identifier是全链路的关键字段前端把整个文件的哈希算出来后先发预检请求服务端查这张表已存在且状态为 3直接返回“秒传成功文件已有引用”不存在则新建一条状态为 1 的记录并把storage_path预留出来。status字段要好好维护合并完成后置为 3删除时置为 4 而不是真的立刻删数据方便后续审计追溯。分片追踪不建表用 Redis 的 Set 更合适下一章会讲。3. 企业网盘上传链路把秒传、断点续传和分片合并一次说清3.1 先想清楚上传状态机这在 Java 面试里都是常客大文件上传这套题在 Java 面试八股文里出现频率很高很多答案只停留在“前端 slice、后端接 chunk、最后合并”的粗粒度上真正落地要拆成四个状态预检查询文件指纹、上传分片并行传多个 chunk、合并服务端按序拼文件、回执更新元数据状态。这四个状态对应接口就是POST /api/file/precheck、POST /api/file/chunk、POST /api/file/merge。预检接口的返回要包含三件事该文件是否已存在、已存在时直接返回文件 ID、未存在时返回分片大小和总分片数。前端拿到分片大小后再决定每个 chunk 怎么切。分片大小不能拍脑袋定我一般按网络环境来内网给 10MB公网给 2MB 到 5MB。分片设得过大单片上传失败重试成本高设得过小对象数量膨胀合并时打开文件的次数也会线性上升。3.2 文件指纹要在浏览器端算别把 hash 压力丢给服务端秒传的前提是拿到整个文件的哈希。如果把这个计算放到服务端用户传完整个文件服务端才能给出指纹秒传就形同虚设了。前端的标准做法是 Web Worker 里跑 SparkMD5分片读取文件逐段 append算完后再发预检请求。// web-worker.js self.onmessage function (e) { const file e.data.file; const chunkSize e.data.chunkSize || 5 * 1024 * 1024; const spark new SparkMD5.ArrayBuffer(); let current 0; const totalChunks Math.ceil(file.size / chunkSize); function next() { const start current * chunkSize; const end Math.min(file.size, start chunkSize); const reader new FileReader(); reader.onload (ev) { spark.append(ev.target.result); current; if (current totalChunks) { self.postMessage({ progress: current / totalChunks }); next(); } else { self.postMessage({ hash: spark.end() }); } }; reader.readAsArrayBuffer(file.slice(start, end)); } next(); };这段代码的逻辑是用file.slice切出每一片FileReader逐片读成 ArrayBuffer 并追加到 SparkMD5 实例里。参数上注意chunkSize要与服务端配置一致否则同一个文件在不同端算出的分片策略不一致后续断点续传的分片索引会错位。2GB 文件按 5MB 分片需要循环 400 次左右在 Worker 里跑不会阻塞主线程这是把 hash 计算放 Worker 的根本原因也是和直接在页面主线程里算的关键区别。3.3 服务端分片追踪Redis 里的 Set 比数据库行更划算分片上传接口每收到一个 chunk就要记录“这个文件已经传到了第几片”。用数据库行记录不是不行但每片一次 UPDATE 会让数据库成为并发瓶颈。我用 Redis 的 Set 结构存已收到的分片序号Set 天然去重重复上传同一片只是幂等覆盖不会产生脏数据。PostMapping(/chunk) public Result uploadChunk(RequestParam String fileIdentifier, RequestParam Integer chunkIndex, RequestParam MultipartFile chunk) { String key upload:chunks: fileIdentifier; storageService.put(chunk.getInputStream(), fileIdentifier / chunkIndex, chunk.getSize()); redisTemplate.opsForSet().add(key, chunkIndex); redisTemplate.expire(key, Duration.ofHours(24)); Long uploaded redisTemplate.opsForSet().size(key); Integer totalChunks fileInfoService.getTotalChunks(fileIdentifier); MapString, Object data new HashMap(); data.put(uploadedChunks, uploaded); data.put(totalChunks, totalChunks); data.put(canMerge, uploaded totalChunks); return Result.success(data); }chunkIndex是前端切分时从 0 开始的递增序号服务端把它作为 Set 的元素同时用这个序号拼出对象存储里的对象名文件指纹/序号保证同一个文件的各个分片在对象存储里也是结构化存放。Redis 的expire参数给 24 小时但要注意现在的写法在每次收到分片时都会续期也就是说只要用户还在持续上传key 就不会消失如果希望“超过 24 小时没有新分片自动清掉”改成只在第一次 add 时设置过期时间即可。canMerge作为一个尽早通知的字段返回给前端实际合并请求仍由前端在最后一片传完后显式发起。3.4 并发分片不保证有序合并时要补两道校验分片上传的并发是前端用多个请求同时发的服务端收到分片的顺序毫无保证。合并时如果按“先到先写”的方式落到同一个文件结果一定错乱。正确做法是确认 Redis 中分片数量等于totalChunks后按序号顺序写入目标文件。用 Java 的 FileChannel 做零拷贝式合并不把整块数据读进 JVM 内存这是大文件合并避免 OOM 的关键。PostMapping(/merge) public Result merge(RequestParam String fileIdentifier) { Integer totalChunks fileInfoService.getTotalChunks(fileIdentifier); String key upload:chunks: fileIdentifier; if (redisTemplate.opsForSet().size(key) totalChunks) { return Result.error(分片不全无法合并); } Path targetPath Paths.get(config.getMergeDir(), fileIdentifier .file); try (FileChannel out FileChannel.open(targetPath, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) { for (int i 0; i totalChunks; i) { Path partPath Paths.get(config.getChunkDir(), fileIdentifier, String.valueOf(i)); try (FileChannel in FileChannel.open(partPath, StandardOpenOption.READ)) { long offset (long) i * config.getChunkSize(); long written 0; while (written in.size()) { written out.transferFrom(in, offset written, in.size() - written); } } } } // 对合并结果做 MD5 校验与前端指纹记录比对 String mergedMd5 DigestUtils.md5Hex(Files.newInputStream(targetPath)); if (!mergedMd5.equalsIgnoreCase(expectedMd5)) { return Result.error(合并结果校验失败); } fileInfoService.updateStatus(fileIdentifier, 3, targetPath.toString()); return Result.success(合并完成); }这段合并代码的三个参数要解释清楚。config.getChunkSize()必须与 Redis 里记录的分片大小一致它决定每个分片在最终文件里的起始偏移量offset如果这个值中途被改过文件就会中间出现空洞或重叠。transferFrom是 FileChannel 的零拷贝传输方法不需要手动申请 byte[]分片大小是 10MB 时单循环内存占用几乎可以忽略。合并后的 MD5 校验是第二道安全网它把合并产物与前端算出的file_identifier做比对防止前端把同一个文件的某个分片传错比如同名不同内容导致静默数据损坏。服务端如果走异步合并可以用CompletableFuture.allOf等待所有分片落盘完成再触发 merge 流程注意给allOf加超时时间避免某个分片永远不出现导致的线程悬挂。4. 文档管理平台的权限、预览和检索企业网盘和普通网盘的区别4.1 用 RBAC 加资源级 ACL 做权限模型企业网盘不能像个人网盘一样“登录就能看全部文件”。权限模型我用两层第一层是基于角色的 RBAC控制用户能进入哪些功能模块比如“上传”“删除”“管理用户”第二层是基于资源的 ACL控制某个具体文档能被谁下载、谁能预览。ACL 这张表的权限位用整数按位存储1表示可预览2表示可下载4表示可编辑8表示可管理。CREATE TABLE document_acl ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_id BIGINT NOT NULL, subject_type VARCHAR(16) NOT NULL COMMENT USER 或 DEPT, subject_id BIGINT NOT NULL, permission INT NOT NULL DEFAULT 1, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_doc (doc_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;Spring Security 里我用PreAuthorize(docAuthService.check(#docId, download))这样的注解切到方法级别比在 Controller 里手写 if-else 判断要干净得多。check方法先加载当前用户的角色集合再查document_acl最后用(permission 2) ! 0判断是否有下载权限。这个按位与的设计在权限叠加时比较省心比如某部门有“预览下载”permission 存 3后面若要追加编辑权限ACL 更新时做一次permission | 4不需要重写整行。4.2 接入 OnlyOffice 让 Office 文档在线可编辑企业网盘和普通网盘的分水岭是文档能不能在线预览和协作编辑。开源方案里 OnlyOffice 和 KkFileView 是两条路线KkFileView 偏预览把 docx、xlsx 转成 PDF 后给浏览器渲染集成简单OnlyOffice 偏编辑能直接在线改 docx。热词里“java 进行 onlyoffice 在线编辑文书”问的就是 OnlyOffice 的 Java 集成这里给出关键配置。{ document: { fileType: docx, key: file_identifier_md5, title: 季度报告.docx, permissions: { edit: true, download: true }, url: http://your-server:8080/api/preview/raw/1001, callbackUrl: http://your-server:8080/api/onlyoffice/callback }, documentType: word }url是 OnlyOffice 服务器去拉取文档原文件的地址注意这里必须是服务端能访问到的地址不能是前端浏览器地址callbackUrl是 OnlyOffice 在用户编辑保存后回调业务系统的接口用来把新版本写回对象存储。两者都需要做 JWT 签名校验只在 OnlyOffice 服务端和业务服务端之间共享密钥否则任何人拼一个回调 URL 就能把任意内容写进你的网盘。部署 OnlyOffice DocumentServer 时注意要能访问外网做许可证验证离线环境下要提前准备好 license 文件否则在线编辑功能会每隔一段时间就断开。4.3 全文检索轻量方案先上 MySQL规模大了再上 ES文档管理平台的搜索通常分两层文件名搜索和文件内容搜索。文件名搜索用 MySQL 就够了加个普通索引就好。文件内容搜索看规模和预算我实践下来的选择还比较明确方案适合规模部署成本中文分词实时性MySQL LIKE万级文件内零无即时MySQL 全文索引 ngram十万级文件低原生 ngram秒级Elasticsearch百万级以上高IK 分词秒级内容搜索的前提是能把 docx、pdf 抽成纯文本。Java 生态的 Apache Tika 是常见选择它能解析上百种格式。抽取出的文本存一份到file_content表或直接进 ES搜索时优先查文件名再加一个文件内容的加权字段。{ query: { bool: { must: [ { term: { ownerId: 1001 } } ], should: [ { match: { fileName: { query: 季度报告, boost: 3 } } }, { match: { contentText: { query: 季度报告, boost: 1 } } } ] } } }搜索权限不能漏ES 查询里ownerId这个 term 必须动态拼入当前用户及其可见部门不能只查文件内容不查权限。这个是我能讲的坑很多网盘系统做全文检索时只把索引里的数据展示出来结果用户搜到了别人的机密文件。4.4 审计日志和下载水印要用异步写别拖慢文件下载企业网盘上线后审计需求一定会有谁在什么时间下载了哪个文件。审计日志如果用同步写数据库每下载一次就多一次 DB 事务文件稍大时下载响应时间会被明显拉长。我的方案是 Spring AOP 切下载接口把审计事件丢进线程池异步落库。4.4.1 用注解加 SpEL 表达式捞出操作对象定义AuditLog(action DOWNLOAD, resource #docId)注解切面里用 SpEL 解析#docId参数得到文档 ID再结合 SecurityContext 里的用户信息和时间戳拼成一条审计记录。时间戳统一用 UTC 存展示时按用户时区转换这里有个典型的坑如果审计记录直接存本地时间跨时区的团队查日志时看到的时间戳会像代码签入 SCM 里的时区乱码一样错位排查纠纷时很头疼。4.4.2 下载响应动态打水印敏感文档建议在下载或预览时动静脉注入水印水印内容一般取当前用户名加时间例如“张工 2025-03-18 14:30”渲染在 PDF 每一页底部。Java 侧用 PDFBox 打开文档流叠加水印文字后再输出文件名保持原样但内容已带追踪信息。5. 用一致性核对脚本给设计源码做数据面体检5.1 网盘里最容易被忽略的“孤儿文件”分片上传有各种中断路径用户传到一半关掉页面Redis 里的分片记录过期但对象存储里的分片文件还在合并完成后合并目录下的分片文件没清干净更麻烦的是“断链”即file_info表里状态是 3可用但对象存储里的实际文件已经被误删或过期。这两类问题在演示项目里不影响跑通流程一旦上了生产会变成存储成本黑洞和权限追溯的盲区。所以源码里光有上传下载还不够必须有一个“元数据表与对象存储的定期对账”机制。5.2 用 Spring 定时任务几十行做个对账下面的核对 Job 会枚举对象存储里的全部对象和数据库里的storage_path集合做差集输出孤儿文件和断链文件两份清单。Component public class StorageReconcileJob { Scheduled(cron 0 30 2 * * ?) public void reconcile() { SetString dbPaths fileInfoMapper.selectAllStoragePaths(); ListString objectKeys storageService.listAllObjects(); ListString orphanFiles objectKeys.stream() .filter(key - !dbPaths.contains(key)) .collect(Collectors.toList()); ListString brokenReferences dbPaths.stream() .filter(path - !objectKeys.contains(path)) .collect(Collectors.toList()); reconcileLogService.save(orphanFiles, brokenReferences); } }cron表达式是每天凌晨 2:30 执行选凌晨是因为这时的上传操作最少扫描对 IO 影响小。selectAllStoragePaths把数据库侧全部路径拉出来注意当文件数量超过十万时全量listAllObjects不再合适应该按日期前缀比如上传月份分批枚举每批单独对账避免一次加载几十万对象到内存。orphanFiles对应对象存储有但数据库没有的对象brokenReferences对应数据库有但存储文件缺失的记录。前者需要下架后者需要告警和人工恢复两类异常的处理方式必须分开。5.3 把异常清单当成上线前的验收标准对账 Job 写完不是摆设我一般把它纳入发版检查项。单测里可以构造一个假分片对象再手动调用 reconcile断言orphanFiles长度变化集成测试里则用测试 MinIO 桶先塞一个无元数据的对象再验证 Job 能识别出来。上线后的第一个月每天看一眼清单数量变化趋势如果孤儿文件数量持续下降说明删除接口工作正常如果断链记录反复出现基本可以断定对象存储的某个生命周期规则误配了比如 MinIO 的过期删除策略把未更新的对象吞掉了。把这些数据接进监控告警比用户报“我的文件打不开”早一步发现问题。本文还有配套的精品资源点击获取