浏览器端文件去重需用FileReader读取二进制并调用crypto.subtle.digest(‘SHA-256’)生成内容哈希，禁用仅依赖文件名与大小的误判方式，注意https要求、大文件分块采样、input.value清空防事件丢失、服务端必须二次校验，兼容性问题需降级处理。
用 FileReader 计算文件哈希（如 SHA-256）做去重
浏览器端无法直接读取文件真实路径或 inode，唯一可靠方式是基于内容生成指纹。直接比对 file.name + file.size 极易误判——同名不同内容、或不同名但内容相同都会失败。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 上传前用
FileReader读取文件二进制数据，配合crypto.subtle.digest()计算SHA-256（注意：需 HTTPS 环境） - 对大文件慎用全量计算——可改用分块采样（如取前 64KB + 后 64KB + 总大小拼接后哈希），平衡精度与性能
- 哈希结果转为十六进制字符串后存入内存 map 或
Set，后续上传前先查重
const getFileHash = async (file) => { const arrayBuffer = await file.arrayBuffer(); const hashBuffer = await crypto.subtle.digest('SHA-256', arrayBuffer); const hashArray = Array.from(new Uint8Array(hashBuffer)); return hashArray.map(b => b.toString(16).padStart(2, '0')).join(''); };监听 input[type="file"] 的 change 事件并清空值
用户重复选择同一文件时，change 事件不会触发（因为 input.files 没变），导致逻辑跳过。更糟的是，若用户取消再选一次同名文件，部分浏览器仍不触发事件。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在处理完一次上传后，手动将
input的value设为空字符串：input.value = '' - 不要依赖
input.files.Length判断是否“有新文件”，而应以是否执行过哈希校验为准 - 若用
multiple属性，需遍历input.files每一项单独校验，不能只看总数
服务端必须二次校验，前端防重只是体验优化
前端哈希可被绕过（如禁用 js、篡改内存），且不同浏览器对 FileReader 和 crypto.subtle 支持度不一（safari 旧版不支持 digest）。任何生产系统都必须在服务端落地前校验内容一致性。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 前端传哈希值仅作提示用途（如“该文件已存在，是否跳过？”），不用于跳过上传流程
- 服务端收到文件后，仍要独立计算哈希并与数据库已有记录比对
- 避免仅靠文件名或数据库主键判断重复——用户可恶意上传同名不同内容文件
注意 Safari 和 IE 的兼容性断层
crypto.subtle.digest() 在 Safari 16.4+ 才完整支持，IE 完全不支持；FileReader.readAsArrayBuffer() 虽然兼容性好，但 IE10+ 才支持 ArrayBuffer 输出格式。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 降级方案：用纯 JS 实现的 SHA-256 库（如
sha256npm 包），但注意大文件会阻塞主线程 - 对老浏览器，退回到「名称+大小+最后修改时间」组合判断（不严谨但可防明显误操作）
- 永远在
try/catch中调用crypto.subtle.digest()，捕获NotSupportedError或SecurityError
前端防重复上传本质是「减少无效请求 + 提升用户感知」，不是安全边界。真正卡住重复的，永远是服务端落地那一刻的哈希比对和原子写入逻辑。