浏览器禁止JavaScript获取文件真实本地路径是硬性安全限制，file.path始终为空，仅file.name可靠；预览应优先用URL.createObjectURL而非readAsDataURL，拖拽需完整处理dragenter/dragover/drop并正确preventDefault。
浏览器根本不允许 JavaScript 获取文件的真实本地路径，这是硬性安全限制，不是兼容性或写法问题。你看到的 file.name 是文件名，file.path 在所有现代浏览器中都是 undefined 或空字符串。
为什么 file.path 总是空？
这是浏览器主动屏蔽的行为，防止网页通过路径推测用户目录结构、隐私文件位置等。Chrome、Firefox、Safari、Edge 全部一致执行该策略，且没有开关或绕过方式。
-
file.name可靠，始终返回用户选择的原始文件名（不含路径） -
file.webkitRelativePath仅在拖拽整个文件夹时可能有值（如"photos/cat.jpg"），但需用户启用「包含子文件夹」选项，且仅 Chrome/Edge 支持 -
input.value在部分旧版 IE 中曾返回路径，但早已废弃，现代浏览器统一返回假路径（如C:\fakepath\xxx.jpg），不可用于读取或上传
dataTransfer.items 和 dataTransfer.files 有什么区别？
两者都提供文件访问入口，但行为和可靠性不同：
-
dataTransfer.files是类数组，直接暴露File对象，但某些场景（如跨窗口拖拽、快速连续 drop）可能为空或延迟就绪 -
dataTransfer.items是DataTransferItem列表，更底层；用item.getAsFile()才能拿到File，且支持判断是否为文件夹（item.kind === 'file'或'directory'） - 稳妥做法：优先遍历
items，对每个item调用getAsFile()；若返回null，再 fallback 到files[i]
想预览或上传，该用 readAsDataURL 还是 createObjectURL？
除非你要提取文本内容（如读取 JSON 或日志），否则别用 FileReader.readAsDataURL 做图片预览——它把整个文件转成 base64 字符串，内存占用翻倍，大文件极易卡死。
立即学习“前端免费学习笔记（深入）”；
- 预览图片/视频/音频：用
URL.createObjectURL(file)，生成一个指向内存中二进制数据的临时 URL，轻量且同步 - 记得在不需要时调用
URL.revokeObjectURL(url)，否则对象长期驻留内存，反复拖拽会堆积泄漏 - 上传时直接把
File对象 append 进FormData即可，无需读取——浏览器自动处理二进制流
拖拽后文件“没反应”，常见卡点在哪？
最常被忽略的是事件监听不完整。只绑 dragover 不够，必须同时处理 dragenter：
-
dragover阻止默认行为（e.preventDefault()），让 drop 可触发 -
dragenter也必须preventDefault()，否则 Safari 和部分 Edge 版本压根不进入 drop 流程 - 别给
document或body绑，只绑定到明确的容器（如document.getElementById('drop-area')），避免干扰其他拖拽逻辑 - drop 事件里别直接解构
e.dataTransfer.files就开干，先检查长度：if (!files.length) return
真正难的不是拿到文件，而是让「用户松手那一刻」和「JS 真拿到可用 File 对象」之间不掉链子——中间任何一环漏掉 preventDefault 或顺序错乱，都会静默失败。
