vscode拖拽文件到编辑器区域默认插入路径而非打开文件，因其设计为调用editor.insertsnippet插入变量，须拖至标签页空白区或资源管理器底部空白处才能真正打开。
拖拽文件进编辑器区域，为什么只插入路径不打开文件？
VSCode 默认拖拽文件到编辑器区域（即中间代码区）会插入文件路径字符串，而不是打开文件——这是设计行为，不是 bug。它本质是调用 editor.insertSnippet 插入 ${fileBasename} 类变量，而非触发 workbench.action.files.openFile 命令。
常见错误是误以为“拖进去就该打开”，结果发现只是在当前光标位置写了一串路径。要真正打开文件，必须拖到两个地方之一：编辑器标签页空白区（非已有 tab 上），或 资源管理器底部空白处（滚动条下方灰色区域）。
- 拖到已打开的 tab 上 → 触发覆盖编辑，不是打开新文件
- 拖到搜索/调试/终端视图里 → 完全无响应，VSCode 不监听这些区域的 drop 事件
- 拖到 Explorer 的某个文件夹节点上 → 触发系统级复制，可能静默覆盖同名目录
如何用插件拦截并自定义拖拽行为？
VSCode 扩展 API 并未暴露底层 drag/drop 事件监听能力；插件无法直接捕获 dragover 或 drop DOM 事件，因为编辑器主区域由 webview 渲染且受沙箱限制。但可通过以下方式间接干预：
- 监听
workspace.onDidOpenTextDocument，在文件被拖拽打开后立即执行自定义逻辑（如自动格式化、跳转到特定行） - 注册命令（如
myExtension.openWithPreview），再通过keybindings.json绑定到drag-and-drop相关上下文键（editorTextFocus+!editorHasSelection） - 利用
vscode.window.registerWebviewViewProvider创建自定义面板，在其中实现完整 drag/drop UI（需手动解析DataTransferItem，支持text/plain和application/vnd.code.filename类型）
注意：application/vnd.code.filename 是 VSCode 内部使用的 MIME 类型，仅在拖拽本机文件时由编辑器注入，插件可读取但不可伪造。
拖拽多个文件时，插件怎么批量处理？
VSCode 原生不提供“一次拖入多个文件触发单次事件”的机制——每个文件都是独立触发 onDidOpenTextDocument。若需合并处理（如统一编码转换、生成 import 语句），必须自己缓存状态：
- 记录首次拖入时间戳，300ms 内后续打开视为同一批次（防抖）
- 检查
document.uri.scheme === 'file'且路径属于同一父目录，过滤掉临时文件或远程 URI - 避免在
onDidOpenTextDocument中直接调用vscode.window.showInformationMessage，否则每文件弹一次窗；改用vscode.window.setStatusBarMessage汇总提示
示例判断逻辑：if (Date.now() - lastDropTime u.fsPath.startsWith(baseDir)))
为什么插件里监听不到拖拽到资源管理器的行为？
资源管理器（Explorer）属于 VSCode 核心 UI，其拖拽逻辑完全由内部模块 explorerViewlet 控制，不对外暴露事件钩子。插件无法订阅“用户把文件拖到左侧空白处”这类动作——即使监听 workspace.onDidChangeWorkspaceFolders，也只在文件夹实际加载后才触发，且无法区分是拖拽、命令行还是菜单操作引入的。
可行替代方案只有两种：
- 在
activationEvent中声明"onCommand:vscode.openFolder"，然后监听vscode.commands.registerCommand被调用的时机（但无法获取原始拖拽路径） - 要求用户右键资源管理器空白处 → “Open Folder…” → 插件拦截该命令并注入自定义逻辑（需配合
vscode.workspace.getConfiguration('myExtension').get('enableDragHook')开关）
真正难啃的点在于：VSCode 把拖拽作为平台级交互封装在 Shell 层，插件层看到的永远是结果（文件打开、文件夹加载），而非过程。
