仅靠文件名或大小无法准确判断重复，因文件名可随意修改、不同文件可能大小相同、lastModified易被重置；安全去重需计算SHA-256哈希，但须控制并发、分批处理大文件并按类型差异化策略。
HTML 文件拖拽本身不提供重复文件过滤能力，必须靠 JavaScript 主动比对文件内容（如 SHA-256）或元数据（name + size + lastModified），否则仅靠 name 或 size 判断极易误判。
为什么不能只靠文件名或大小判断重复
用户可能把同一张图另存为不同名字（IMG_001.jpg 和 photo.jpeg），或修改时间戳；两个不同文件也可能偶然大小一致。浏览器拖放拿到的 File 对象里，name、size、lastModified 都可被伪造或覆盖，不具备唯一性。
-
File.name仅是用户保存时输入的名称，和实际内容无关 -
File.size相同 ≠ 内容相同（比如两个 1.2MB 的 PDF 可能完全不同） -
File.lastModified在复制/解压/上传后常被重置，不可信
拖拽后怎么安全提取并去重文件
在 drop 事件中拿到 e.dataTransfer.files 后，需立即做两层过滤：先筛掉无效项（Safari 文件夹伪文件、空文件），再对剩余文件计算指纹。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 必须先用
Array.from(e.dataTransfer.files)转成真数组，FileList不支持filter等方法 - 逐个检查
file.size > 0，且排除 Safari 文件夹（file.size === 68 && !/\.[a-z0-9]+$/i.test(file.name)） - 对保留文件调用
new FileReader().readAsArrayBuffer(file)，再用 Web Crypto API 计算SHA-256哈希值 - 用
Set或对象键存储哈希值，发现重复则跳过或标记
大文件或批量拖拽时的性能陷阱
直接对 10 个 50MB 的视频文件同时读取 ArrayBuffer，会瞬间吃光内存并卡死页面。真实项目中必须控制并发和降级策略。
立即学习“前端免费学习笔记（深入）”；
- 单次拖拽超过 5 个文件，建议分批处理（例如每次最多 3 个）
- 单个
file.size > 10 * 1024 * 1024（10MB）时，跳过哈希计算，改用name + size + lastModified粗略去重（标注“可能重复，请手动确认”） - 不要用
readAsDataURL()——它生成 base64 字符串，体积膨胀 33%，且无法用于哈希 - 计算完哈希后立刻释放
ArrayBuffer引用，避免 GC 延迟
真正难的不是算哈希，而是决定哪些文件值得算：用户拖进 200 张截图，你却给每张都跑一遍 SHA-256，体验反而更差。优先按 file.type.startsWith('image/') 分类，图片走哈希，文档走 name 模糊匹配，视频直接跳过——规则得根据你的业务场景定，没有银弹。
