本文介绍一种无需读取文件内容、仅依赖浏览器提供的 file 对象元数据（如 size、type、name）进行轻量级重复文件识别的方法，适用于表单中多个 `` 场景，兼顾实用性与性能。
在 Web 表单中处理多文件上传时，用户可能从不同路径选择同名文件（如 report.pdf），甚至重复选择同一物理文件。由于浏览器出于安全限制，File API 不暴露文件路径、inode、UUID 或内容哈希，也无法直接获取唯一标识符（如 SHA-256），因此无法 100% 精确判定两个 File 对象是否指向同一底层文件。
但实践中，我们可通过组合多个高区分度的只读属性进行概率性去重判断：size（字节大小）、type（MIME 类型）、name（文件名）三者联合匹配，可显著降低误判率。虽然理论上存在不同文件恰好 size/type/name 完全一致的极端情况（碰撞概率极低，尤其当 size > 0 且 type 非空时），但在多数业务场景（如文档上传、图片管理）中已足够可靠。
以下是一个完整、可运行的示例，实现跨多个 元素的文件列表合并与重复检测：
? 关键说明与注意事项：
- ✅ 推荐组合判断：size + type 是最实用的双因子；添加 name 可提升用户体验（例如避免 invoice.pdf 与 scan.jpg 因巧合同 size/type 被误标），但不应作为唯一依据（同名不同内容很常见）。
- ⚠️ lastModified 不可靠：用户可能手动修改时间戳，或不同设备同步导致不一致，不建议用于去重逻辑。
- ⚠️ webkitRelativePath 仅限目录上传：需设置 webkitdirectory 属性，且非标准、兼容性有限，不适用于普通文件选择。
- ? 进阶优化方向：若需更高精度，可在用户确认后对疑似重复文件使用 FileReader.readAsArrayBuffer() 计算前 N KB 的快速哈希（如 xxHash），但会带来额外内存与 CPU 开销，需权衡。
- ? 服务端兜底：前端去重仅为体验优化，服务端仍必须做最终校验（如接收后计算内容哈希并查重），确保数据一致性。
综上，该方案以零内容加载为前提，在浏览器能力边界内实现了高效、可维护的重复文件识别，是现代文件上传流程中值得采纳的务实策略。
