关键是在drop事件中获取FileList并手动校验video类型，用file.type.startsWith('video/')初筛再辅以后缀检查，仅取首个视频文件；video.src须设为URL.createObjectURL(file)，并监听loadedmetadata后操作。
拖拽区域怎么监听文件并过滤视频类型
关键不是靠 dragover 做“允许拖入”，而是用 drop 事件拿到 FileList，再手动判断 file.type 或后缀。浏览器不会自动拦截非视频文件，必须自己筛——否则用户拖个 PDF 进来，URL.createObjectURL() 虽不报错，但后续 video 元素会静默失败。
实操建议：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 在
drop回调里遍历e.dataTransfer.files，用file.type.startsWith('video/')初筛，再补一层后缀检查（如.mov在某些系统可能返回空 type） - 只取第一个视频文件（多文件拖入时，预览通常只需一个），忽略其余
- 务必调用
e.preventDefault()，否则 Chrome/Safari 会直接导航到该文件
video 元素怎么加载本地 File 对象
video.src 不能直接赋值 File 对象，必须用 URL.createObjectURL(file) 创建临时内存 URL。这个 URL 生命周期绑定到当前文档，页面刷新即失效，不用手动释放（除非你频繁拖入大量大视频，才需在切换前调用 URL.revokeObjectURL()）。
常见错误现象：赋值后视频黑屏、无 controls、duration 为 NaN——大概率是没等 loadedmetadata 就读取了元信息，或 src 赋值后没调用 load()。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 设置
video.src = URL.createObjectURL(file)后，立刻监听loadedmetadata事件再操作播放控制 - 避免在
canplay或canplaythrough里做预览逻辑，它们触发时机不稳定；loadedmetadata才保证宽高、时长可用 - 若需自动播放，注意浏览器策略：必须用户手势触发后才能调用
play()，所以得把play()放在drop的同步回调里（而非异步的loadedmetadata）
为什么拖完没反应？检查这三处硬性限制
不是代码写错，而是浏览器策略卡住：HTTPS 环境下部分 API 不可用、移动端不支持 drag/drop、video 元素未插入 DOM 就赋值 src —— 这些都会导致静默失败。
使用场景差异：
- 本地开发用
file://协议时，Chrome 会禁用createObjectURL（报SecurityError），必须起一个本地服务（如npx serve） - 移动端 Safari 完全不支持
dragstart/drop，只能退化为点击<input type="file" accept="video/*"> -
video元素如果display: none或未 append 到 body，某些版本 Firefox 无法加载元数据
预览卡顿或内存暴涨？别让 createObjectURL 积压
每次拖新视频都调 createObjectURL，旧 URL 若没被回收，大视频（比如 500MB MP4）会在内存里存两份——一份是 File 对象，一份是 URL 指向的内存块。用户反复拖拽几次，页面就卡死。
性能影响明显：
- 首次拖入：创建 URL → 触发加载 → 正常预览
- 第二次拖入：创建新 URL，但旧 URL 还挂着，浏览器不敢释放对应内存
- 解决办法：在新
src赋值前，先记下旧src，然后调用URL.revokeObjectURL(oldSrc) - 注意：不能在
loadedmetadata里 revoke，否则视频可能刚播几帧就断流；应在新src设置成功后、旧视频彻底不用时立即 revoke
真正难的不是拖拽或播放，是边界情况处理：HTTP 策略、移动端降级、内存生命周期、type 判定不准——这些不写进代码里，光靠“能跑”根本撑不住真实用户乱拖。
