Deno TypeScript：Claude Code 实战指南

把权限当成架构的一部分

Deno 的重点不是“另一个 JavaScript 运行时”这么简单。它默认更谨慎：脚本访问文件、网络、环境变量或子进程时，需要明确权限。换句话说，Deno 在初始状态下把文件读取、文件写入、网络、环境变量、外部命令执行这些能力都关闭了。Deno 官方的 Security and permissions 也把“只显式授予必要的访问权限”作为基本理念。Claude Code 可以帮助你写 Deno API、CLI、自动化脚本和测试，但提示词必须包含权限边界，否则很容易生成过宽的 --allow-all。

先把几个术语统一一下。权限（permission）就是“允许这个程序触碰到哪一层”的一份许可清单；deno task 是写在 deno.json 里的具名命令；formatter 是整理代码格式的工具，linter 是检测容易出 bug 的写法的工具，test runner 则负责运行用 Deno.test() 写的测试。Deno 把这几样都内置了，所以一开始不用堆一大堆开发依赖，就能从小处起步。

建议搭配权限设置指南、API 开发和测试策略阅读。官方资料参考 Deno docs、Deno permissions、Deno.serve。

Claude Code 提示词

模糊的请求容易跑偏，先把 Deno 特有的约束写清楚，输出会稳定很多。

请用 Deno 写一个小型 HTTP API。
不要使用 --allow-all。
请列出需要的最小权限、deno.json task、测试、格式化和 lint 命令。
代码必须能复制运行，并说明部署前的 pitfall。

这条指示的关键在于同时指定四件事：要用的 API、不要用的库、权限范围、验证命令。Deno 的配置以官方的 deno.json and package.json 和 deno task 为准。

适用场景清单

小型 JSON API：用 Deno.serve 快速启动，权限只开放网络端口。
自动化脚本：读取指定目录、写入指定输出，避免读取整个磁盘。
webhook 接收器：验证签名、限制方法、记录错误。
团队工具：把 format、lint、test 写入 deno.json，让新人少记命令。

实现示例

先看 deno.json。dev 和 start 只开放必要的权限，check 把 format、lint、test 一次跑完。

{
  "tasks": {
    "dev": "deno run --allow-net=localhost:8000 src/server.ts",
    "test": "deno test --allow-net=localhost:8000",
    "check": "deno fmt --check && deno lint && deno test"
  }
}

deno fmt、deno lint、deno test 都是 Deno 内置的。个人开发只靠这三样，就能把质量明显抬上来。团队使用时，把 check 放进 CI，让“未格式化”“lint 违规”“测试失败”都从同一个入口被拦下，是更现实的做法。

接着是 API 本体。Deno.serve 接收标准的 Request、返回标准的 Response，写法很直接。

// src/server.ts
Deno.serve({ port: 8000 }, (request) => {
  const url = new URL(request.url);

  if (url.pathname !== "/health") {
    return new Response(JSON.stringify({ error: "not_found" }), { status: 404 });
  }

  return Response.json({ ok: true, runtime: "deno" });
});

在这个例子里，启动服务器需要网络权限。如果再加上读写 JSON 文件，就把范围收到 --allow-read=./data 和 --allow-write=./data，这样即便不小心混入了读取整个主目录的代码，Deno 也会把它拦下来。

写权限无关的单元测试

直接测试文件 I/O 会需要权限。所以让 API 处理逻辑依赖一个 store 接口，测试时塞入内存实现，这样只靠 deno test 就能跑起来。

// app_test.ts
import { assertEquals } from "@std/assert";

Deno.test("GET /health returns ok", async () => {
  const response = await fetch("http://localhost:8000/health");
  assertEquals(response.status, 200);
  assertEquals(await response.json(), { ok: true, runtime: "deno" });
});

按官方 deno test 的说明，Deno 的测试与运行时权限是同一套思路。把测试设计成“不需要多余权限就能跑”，那么当 Claude Code 之后偷偷加进危险的 I/O 时，你就更容易察觉。

陷阱清单

经常使用 --allow-all 的话，选择 Deno 的意义就被削弱了。即便是本地验证，也建议养成像 --allow-read=./data 这样缩小目标的习惯。
--allow-net 的 host 范围放得太宽，会增加外部通信的风险。
如果默认依赖面向 Node 的包，就需要额外确认兼容性；入门阶段先把 Deno.serve、deno fmt、deno lint、Deno.test() 试一遍，更能理解整体结构。
写文件时容易忘了先创建目录，记得事先把 data/items.json 之类的文件准备好。
注意部署环境和本地环境在环境变量、权限上的差异。
别直接粘旧示例。Deno 官方文档会更新，实现前先确认当前的写法。
Claude Code 生成的代码，一定要用 deno fmt、deno lint、deno test 来确认。

验证方法

deno task check
deno task dev
curl http://localhost:8000/health

确认能否以最小权限启动、有没有多余的文件读取、出错时是否以 JSON 返回。最后让 Claude Code 复查“还能把权限收得更窄的地方”。

商业化视角

Deno 的价值在于，能安全又快速地做出内部工具和小型 API。读 Deno 文章的读者，往往已经不满足于单纯的运行时对比，而是处在“想安全地、小步地把 AI 开发跑起来”的阶段。如果要在现有团队里推广，可以借助 Claude Code 培训与咨询，把权限设计、测试和评审流程一起梳理好。

权限矩阵模板

上线前让 Claude Code 生成权限矩阵。每一行写 task、需要的权限、范围、理由、替代方案。例如 API 只需要 --allow-net=localhost:8000，就不要给 --allow-read。如果脚本只读取 ./data，就不要允许读取整个项目目录。这个表格可以直接放进 PR description。

团队导入步骤

第一周只把 format、lint、test 放进 deno.json。第二周选择一个小型 webhook 或 health API。第三周再考虑自动化脚本。每一步都让 Claude Code 写测试和回滚方法。这样可以避免“新技术一次性替换全部工具”的风险。

运营中的判断标准

Deno 的优势不仅是速度，更是容易向他人解释的安全边界。从咨询表单、内部通知、广告报表汇总这类小处理入手，权限评审的效果就更容易看清楚。每次都让 Claude Code 检查：有没有多余的权限、哪些值不能写进日志、环境变量该如何处理。

实测记录

这个配置经过实测：不使用 --allow-all，只用 network 权限就能启动 health API。让 Claude Code 在实现之后再做一次权限复查，运维时也更容易向他人说明。如果你要亲手试一遍，建议先确认能否以最小权限启动，再把功能一点点加上去——优先排除 -A、收紧权限范围、让测试不依赖额外权限，比一次性堆功能更稳妥。