permissiondenied 是 deno 默认安全模型的正常表现，非配置错误；必须显式添加 --allow-net、--allow-read 等命令行权限标志才能运行成功，vscode 插件不干预运行时权限控制。
deno run 报 PermissionDenied 是正常现象，不是配置错误
VSCode 本身不运行代码，只调起终端执行 deno run。Deno 的权限模型在运行时强制校验，编辑器里写 fetch("https://") 不报错，不代表能跑通——这是设计使然，不是漏配或插件失效。
常见错误信息如：error: Uncaught (in promise) PermissionDenied: network access to "https://httpbin.org/json"，它明确告诉你缺的是 --allow-net，而不是路径、插件或语言服务问题。
- 所有权限必须显式声明：网络、文件读写、环境变量、插件加载、进程执行等操作，无一例外
- VSCode 插件（包括官方
vscode-deno）不参与运行时权限控制，也不提供“自动加 flag”功能 - 权限标志只对当前命令生效，
deno run --allow-net main.ts和deno run --allow-read main.ts是两个独立的授权行为
如何在 VSCode 中安全地传入权限参数
不能靠改设置或插件开关绕过，必须把权限 flag 带进实际执行命令。有三种可靠方式：
- 直接在集成终端（
Ctrl+`）手动运行：deno run --allow-net --allow-read --allow-env main.ts - 用
Code Runner插件时，在用户或工作区设置中修改："code-runner.executorMap": {"typescript": "deno run --allow-net --allow-read $fullFileName"} - 调试时靠
.vscode/launch.json控制：确保args字段包含所需 flag，例如"args": ["--allow-net", "--allow-read", "main.ts"]；注意cwd必须指向项目根目录，否则 import 路径或import_map.json可能失效
为什么不能全局加 -A（all permissions）
-A 看似省事，但会彻底破坏 Deno 的安全沙箱意义，尤其在协作或 CI 场景下风险极高：
- 本地开发时，
-A让恶意依赖可任意读取~/.ssh/或写入系统临时目录 - CI 流水线若用
-A运行测试，攻击者可通过污染第三方模块窃取构建密钥 - VSCode 的“Run Test”按钮默认不带任何 flag，点它等于用最小权限运行；若你依赖
-A才能过测试，说明测试本身已越权 - Deno 官方工具链（如
deno task）会读取deno.json中的permissions字段，但该字段仅用于文档和提示，不替代命令行 flag
权限配置容易被忽略的细节
权限不是开了就完事，几个关键点常被跳过导致失败：
-
--allow-read默认只允许当前目录及子目录；要读/etc/hosts，得写成--allow-read=/etc或--allow-read=/etc/hosts -
--allow-env不带参数时只放行空列表；需指定键名，如--allow-env=NODE_ENV,API_URL，否则Deno.env.get("API_URL")仍抛错 - 使用
import_map.json时，若 map 中 URL 指向本地文件（如"utils": "./lib/utils.ts"），则--allow-read必须覆盖./lib/路径 - Windows 上路径分隔符不影响 flag 解析，但
--allow-read=C: oo和--allow-read=C:/foo效果一致；别用双反斜杠，C:\foo会被 shell 当作转义处理
权限模型是 Deno 的基石，不是障碍。每次加 flag 都该问一句：这段代码真的需要这个能力吗？漏掉的往往不是配置项，而是对行为边界的确认。
