VSCode 真正支持 Deno 必须设 deno.enable: true 并确保 deno 命令在 PATH 中可调用，否则类型提示、跳转等功能全部失效；该设置默认关闭是为避免干扰非 Deno 项目，且需配置在工作区而非全局设置。
VSCode 要真正支持 Deno，光装扩展远远不够——deno.enable 必须设为 true，且 VSCode 启动时得能调到系统 PATH 里的 deno 命令，否则类型提示、跳转、报错全失效。
deno.enable 为什么必须手动打开
插件默认不激活语言服务，这是刻意设计：避免在普通 Node.js 或前端项目里误触发 Deno 类型检查，导致全局 API（如 Deno.cwd()、fetch()）被错误识别或覆盖 TypeScript 内置类型。
-
deno.enable是开关，不是可选项；没它，deno.json和权限配置都白搭 - 推荐写在工作区
.vscode/settings.json里，而不是用户全局设置，防止污染其他项目 - 如果已安装 Deno 但 VSCode 报 “Deno not found”，先在终端运行
deno --version，再确认 VSCode 是从 shell 启动的（macOS 上别双击图标，用code .启动）
deno.path 配置失败的常见原因
当 deno --version 在终端能跑，但 VSCode 仍提示找不到 Deno，大概率是 deno.path 指向了错误路径，或 VSCode 没读取到 shell 的 PATH。
- 执行
which deno（macOS/Linux）或where deno（Windows PowerShell）拿到真实路径，例如/opt/homebrew/bin/deno - 在工作区
.vscode/settings.json中写死："deno.path": "/opt/homebrew/bin/deno"，不要用~或环境变量 - Homebrew 安装的 Deno，路径可能含空格或符号链接，
which输出的是最终解析后的路径，直接复制最稳
deno.json 不只是“有就行”
空的 deno.json 文件只能让插件启用基础支持；要获得 lint、fmt、test 集成，必须显式声明字段，否则 VSCode 不会加载对应功能。
-
"lint": { "rules": { "tags": ["recommended"] } }才能触发编辑器内联 lint 提示（比如禁止any类型） -
"fmt": { "useTabs": false, "lineWidth": 100 }才能让保存时自动格式化，且和 CLI 的deno fmt行为一致 - 如果项目用到了导入映射（
import_map.json），必须在deno.json里通过"importMap": "./import_map.json"声明，否则跳转定义会失败
权限报错不能靠 VSCode 绕过
写完 fetch("https://...") 后编辑器不报错，不代表能运行成功——Deno 的权限模型在运行时强制校验，VSCode 只负责类型提示，不参与执行。
- 右键 Run 或调试前，务必确认命令是否带权限标志，比如
deno run --allow-net --allow-read main.ts - 在
deno.json的"tasks"里预定义带权限的脚本，比每次手敲更可靠 - 调试时如果断点进不去、变量显示
undefined，先检查 launch.json 里有没有"runtimeArgs": ["--allow-net", "--allow-read"]
最容易被忽略的是：VSCode 的 Deno 支持完全依赖 deno CLI 的输出结果。哪怕 deno.json 写对了，只要 deno lsp 启动失败（比如版本太旧、PATH 错乱、磁盘空间满），整个语言服务就静默降级为普通 TS 编辑器——此时没有任何提示，只有类型跳转和补全突然失灵。
