你以为 Deno 权限只能靠 -A 全开？今天它把权限管理彻底搬进了配置文件

配 Deno 的人都踩过这个坑——本地开发图方便习惯敲 deno run -A，团队协作时新成员一上来就炸，生产环境到底配了哪些权限全靠回忆。这件事在 Deno 2.5 彻底变了：权限从命令行参数搬进了 deno.json，变成了声明式配置。

旧方式的三个坑

Deno 1.x 时代，权限全靠 CLI 标志：–allow-read、–allow-net、–allow-env 每个标志独立叠加。问题在于：① 本地开发开的权限，生产部署时往往直接复制粘贴；② 团队成员不知道哪些权限是必需的；③ 审核代码时看不清这个脚本到底能访问什么。

deno.json 权限配置化

Deno 2.5 将权限管理从命令行参数迁移至 deno.json 配置文件，引入权限集合（Permission Sets）概念：

{
  "permissions": {
    "process-data": {
      "read": ["./data"],
      "write": ["./data"]
    },
    "default": {
      "read": ["deno.json"],
      "env": true,
      "run": { "allow": ["git"] }
    }
  },
  "tasks": {
    "dev": "deno run -P=process-data main.ts"
  }
}

用 -P 或 –permission-set 标志引用预定义的权限集合。tasks.dev 运行时只读写 ./data，不会意外访问项目外资源。

按子命令隔离权限

这是最关键的改进：权限策略可以按子命令独立定义。运行 deno test 时，如果配置文件中有测试专属权限而未使用 -P 标志，Deno 会主动提示并拒绝执行。这种”显式优于隐式”的安全哲学，有效避免了权限过度授予。

审计日志：谁在什么时候用了什么权限

DENO_AUDIT_PERMISSIONS 环境变量开启后，会生成 JSONL 格式的权限使用审计日志，记录每次权限请求的时间、来源和结果。团队可以建立完整的权限使用追踪体系，满足合规场景下的可观测性要求。

落地步骤

第一步：在项目根目录 deno.json 中为不同任务定义权限集合；第二步：用 -P 标志引用权限集合，用 git hooks 或 CI 检查是否使用了 -P 而非 -A；第三步：设置 DENO_AUDIT_PERMISSIONS，开启审计日志并定期review异常权限请求。

Deno 2.5 这次把安全策略从运行时的一次性行为，变成了代码仓库中可review、可版本控制的声明——这件事本质上是一次权限管理的范式转变。