秒传核心是哈希比对而非传输速度：客户端用SHA-256分块计算文件完整字节哈希，服务端以哈希（及可选大小）为键索引已存文件，匹配则返回路径跳过上传，需保证哈希一致性、事务原子性与安全校验。
Java 实现文件秒传，核心在于客户端预先计算文件哈希值（如 SHA-256），上传前先向服务端发起哈希查询；服务端检查该哈希是否已存在对应文件，若存在则直接返回已有存储路径，跳过上传过程。关键不是“传输快”，而是“避免重复上传”。哈希比对是秒传的判断依据，必须保证一致性、抗碰撞、服务端可追溯。
客户端：稳定计算文件完整哈希值
不能用文件名或修改时间判断——易冲突、不可靠。必须读取全部字节计算强哈希（推荐 SHA-256）：
- 使用 java.security.MessageDigest + Files.newInputStream 分块读取（防大文件 OOM）
- 务必按字节流顺序完整读取，跳过缓冲区错位、编码转换等干扰（不要用 FileReader，它走字符流，会破坏二进制一致性）
- 示例关键逻辑：
MessageDigest md = MessageDigest.getInstance("SHA-256");
try (InputStream is = Files.newInputStream(path)) {
byte[] buf = new byte[8192];
int len;
while ((len = is.read(buf)) != -1) {
md.update(buf, 0, len);
}
}
byte[] digest = md.digest();
String hexHash = HexFormat.of().formatHex(digest); // Java 17+，或用 Apache Commons Codec
服务端：哈希索引与原子化校验
收到客户端传来的哈希值后，需快速判断该文件是否已存在：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 将哈希值（如 SHA-256 十六进制字符串）作为主键，存入数据库（如 MySQL 的 CHAR(64) UNIQUE）或 Redis（SET key_hash → file_id）
- 必须在保存真实文件的同时写入哈希索引，且二者需事务一致（例如：先入库哈希+元数据，再存文件；或用数据库 BLOB 存文件，哈希为索引字段）
- 接口设计建议：
POST /api/file/check?hash=xxx... → 返回 {"exists":true,"url":"/files/abc123.pdf"} 或 {"exists":false}
增强可靠性：哈希+大小双校验（可选但推荐）
极小概率下不同文件产生相同 SHA-256（理论存在，实践中罕见），但加文件大小可近乎消除误判：
立即学习“Java免费学习笔记（深入）”；
- 客户端上传哈希时一并提交 fileSize（Files.size(path)）
- 服务端查询时 WHERE hash = ? AND size = ?，双条件匹配才认定秒传成功
- 不增加显著开销，却大幅提升鲁棒性，尤其适用于用户可任意命名/修改的场景
注意边界情况与安全细节
秒传看似简单，实际落地需规避几个典型坑：
- 哈希必须基于原始文件字节：若前端做了压缩、加密、Base64 编码等预处理，服务端必须用同样方式还原后再算哈希，否则无法匹配
- 大文件分片上传场景下，秒传应作用于整个文件（非单个分片），即客户端仍需先合成完整哈希再请求检查
- 服务端需限制哈希查询频率（防暴力探测）、校验哈希格式（64 位十六进制）、拒绝空/超长哈希，避免注入或 DoS
- 哈希本身不加密，但若业务敏感，可考虑服务端对哈希加盐再存储（需确保客户端也能复现），不过通常没必要
