Deno 基础

Deno 是基于 V8 与 Rust 的 JavaScript/TypeScript 运行时，由 Node.js 原作者 Ryan Dahl 发起。官方文档：docs.deno.com。与 Node、Bun 的对比见运行时对比。

学习路径

顺序	主题	文档
1	概念与选型	本文
2	安装与版本	安装
3	命令与 `deno.json`	初始化
4	权限（核心差异）	权限
5	依赖（JSR / npm / URL）	包管理
6	工具链	内置工具
7	HTTP	HTTP 服务
8	环境变量与调试	其他

设计目标

目标	说明
安全默认	无 `--allow-*` 时，运行中的代码不能随意读写文件、访问网络、读环境变量等（见 Security）
原生 TypeScript	可直接 `deno run app.ts`，无需单独编译步骤
Web 标准 API	内置 `fetch`、`Request`/`Response` 等
工具内置	`deno fmt`、`deno lint`、`deno test`、`deno doc`
现代模块	ESM 为主；通过 `npm:`、`jsr:` 与 `deno.json` 的 `imports` 管理依赖

与 Node.js 的主要区别

	Deno	Node.js
权限	默认拒绝，需 `--allow-read` 等显式授权	进程级默认可访问多数 I/O
项目配置	以 `deno.json` / `deno.jsonc` 为主；也可配合 `package.json`（Node 兼容场景）	`package.json` + `node_modules`
依赖来源	URL、`jsr:`、`npm:` 等，由 Deno 缓存	npm 注册表
顶层 await	模块顶层支持	ESM 模块顶层支持

何时考虑 Deno

场景	说明
脚本/CLI、安全沙箱	权限模型便于限制第三方代码
新项目、少配置	内置 fmt/lint/test
需要 npm 生态	Deno 2 起支持 `npm:` 与 Node API 兼容（以官方兼容说明为准）
已有大量 Node 原生 addon	迁移前需在目标 Deno 版本下验证依赖

快速示例

typescript

// hello.ts
console.log("Hello Deno!");
// deno run hello.ts

typescript

// fetch.ts — 需要网络权限
const res = await fetch("https://api.github.com/repos/denoland/deno");
console.log((await res.json()).full_name);
// deno run --allow-net=deno.land,api.github.com fetch.ts

内置命令速览

bash

deno --version
deno init
deno run main.ts
deno fmt && deno lint && deno test

版本发布与稳定性

概念	说明
稳定版（stable）	常规发布渠道，`deno --version` 显示的默认版本
LTS	Deno 也提供长期支持渠道，追求生产环境的稳定性可优先选择
Canary	每日构建，包含最新特性但可能不稳定，仅用于尝鲜或验证修复
不稳定 API	部分新 API 需要 `--unstable-*` 标志才能使用，代表尚未定稿，升级需关注变更日志

版本切换可用 deno upgrade --version <x.y.z>，详见安装与环境。

编辑器支持

VS Code：安装官方 Deno 扩展，并在项目根目录创建 .vscode/settings.json：

json

{
  "deno.enable": true,
  "deno.lint": true,
  "deno.unstable": false
}

混合项目（同一工作区既有 Deno 又有 Node 子项目）可通过 "deno.enablePaths" 限定生效范围，避免两套类型系统互相干扰。

部署选择

Deno 代码本质上是标准 Web/TS 代码，常见部署方式包括：

方式	适用场景
自托管（VM / Docker，官方镜像 `denoland/deno`）	需要完全掌控运行环境、已有容器编排体系
Deno Deploy（官方边缘平台）	追求零配置部署、边缘就近访问，以官方文档为准
传统云服务器 + systemd/PM2 类进程管理	与现有 Node 部署习惯保持一致

常见坑

把 -A/--allow-all 当作默认写法：开发阶段图方便全开权限，上线前务必收紧为具体的 --allow-read=./data 等最小授权。
混用 npm: 包时期望与 Node 100% 一致：Deno 的 Node 兼容层覆盖了大部分常见 API，但少数依赖 Node 内部实现细节或原生二进制的包可能行为不同，升级前应在目标 Deno 版本下跑一遍测试。
忽略 deno.json 与 package.json 同时存在的优先级：两者都存在时，依赖解析规则可能出乎意料，尽量在一个项目里只以一种为主。
标准库 URL 不锁版本：https://deno.land/std/...（不带 @version）会跟随最新版本，破坏可复现性，务必固定版本号。

最佳实践

新脚本/工具优先用 Deno 原生方式编写（fetch、Web Streams、Deno.* API），只在确实需要 npm 生态时才引入 npm:。
团队协作项目统一提交 deno.json/deno.jsonc，并在 CI 中运行 deno fmt --check、deno lint、deno test。
生产部署前用 deno info 检查依赖树，确认没有意外引入的大体积或不受信任的远程模块。
权限标志写入启动脚本或 Dockerfile，而不是让每个开发者本地各自记忆一长串 --allow-*。

参考文献

以下链接在编写时均可正常访问：

资料	说明
Deno 手册	官方
Security	权限模型
npm 与 Node 兼容	`npm:` 与 Node API
运行时对比	Bun / Deno / Node