一、起源：Node.js 之父的「遗憾清单」

2018 年 6 月，JSConf EU 上发生了一件让整个 JavaScript 社区记忆深刻的事情：Node.js 的创造者 Ryan Dahl 站上讲台，做了一场名为「10 Things I Regret About Node.js」的演讲。

一个框架的作者公开批判自己的作品——这在技术圈不常见。但 Ryan 说的不是客气话，他列出了一系列他认为在 Node.js 设计中犯下的根本性错误：

1. 没有坚持 Promise。2009 年 Node 就有了 Promise 支持，但 2010 年又删掉了。如果当初坚持，也许 async/await 的标准化会来得更早。
2. 安全模型缺失。Node 程序天然拥有文件系统、网络、环境变量的全部权限——一个 npm install 就可能让恶意脚本为所欲为。
3. 构建系统的历史包袱。GYP 这个 Chrome 都已经抛弃的构建工具，成了 Node 原生模块的唯一选择。
4. package.json 的膨胀。它从一个简单的元数据文件，逐渐变成了承载依赖管理、脚本运行、入口配置等各种职责的超级文件。
5. node_modules 的设计。嵌套的依赖结构变成了人尽皆知的「黑洞」，磁盘占用和解析复杂度都远超合理水平。
6. require() 的隐式解析。省略扩展名、自动查找 index.js——方便了开发者，却让模块解析逻辑变得极度复杂。
7. 与浏览器标准的割裂。Node 发明了自己的一套 API（fs、path、http），与浏览器的 Web API 体系渐行渐远。

这场演讲不只是反思。Ryan 在结尾亮出了他的答案：Deno——一个用 Rust（后期）和 V8 构建的全新 JavaScript/TypeScript 运行时。

Deno 不是 Node 的升级版，而是 Ryan 对「如果重来一次，JS 运行时该怎么设计」这个问题的回答。

二、名字彩蛋与技术选型

2.1 名字的由来

Deno 是 Node 的字母重排（anagram）：No-De → De-No。这本身就是一种态度——它不是继承，而是重构。

2.2 早期技术选型

Deno 最初的原型用 Go 编写，但 Ryan 很快意识到两件事：

• Go 自带的垃圾回收与 V8 的 GC 会产生冲突；
• 需要更底层的控制能力来实现安全沙盒。

于是 Deno 转向了 Rust，利用 Rust 的内存安全性和 Tokio 异步运行时来构建底层。这个决定奠定了 Deno 的技术基调：安全、高性能、现代化。

三、关键版本时间线

3.1 Deno 1.0（2020 年 5 月）

经过两年多的开发，Deno 1.0 正式发布。它带着一套相当理想化的设计理念亮相：

• 默认安全：脚本默认没有文件、网络、环境变量等任何权限，需要通过 --allow-read、--allow-net 等标志显式授权。
• TypeScript 开箱即用：不需要 tsconfig.json、ts-node、ts-loader 等任何额外配置，deno run main.ts 直接运行。
• URL 导入模块：抛弃 node_modules，通过 URL 直接引入依赖，首次运行时下载并缓存到全局目录。
• 内建工具链：deno fmt、deno lint、deno test、deno doc 全部自带。
• 拥抱 Web 标准：fetch()、WebSocket、TextEncoder 等浏览器 API 原生可用。

// Deno 1.0 风格的代码
import { serve } from 'https://deno.land/[email protected]/http/server.ts'
 
const server = serve({ port: 8000 })
console.log('Server running on http://localhost:8000')
 
for await (const req of server) {
  req.respond({ body: 'Hello from Deno!\n' })
}

1.0 时代的 Deno 非常纯粹，但也因此面临一个尴尬的现实：NPM 生态太大了，完全绕开它不现实。

3.2 Deno 1.x 持续演进（2020–2024）

1.x 阶段是 Deno 从理想走向务实的过程：

• 1.13（2021）：引入 --unstable 标志下的 FFI（外部函数接口），允许调用原生库。
• 1.25（2022）：实验性支持 npm: 前缀，可以直接引入 NPM 包——这是一个重大妥协，也是一个务实的转折。
• 1.28（2022）：deno.json 配置文件逐渐成熟，支持 import map、编译选项等。
• 1.31（2023）：package.json 自动检测——Deno 开始能够直接运行包含 package.json 的项目。

这个阶段的核心矛盾是：Deno 想保持「干净世界」的设计哲学，但又不得不向 NPM 生态伸出橄榄枝。

3.3 Deno 2.0（2024 年 10 月）

Deno 2.0 是一个标志性版本，它正式宣告了 Deno 的务实路线：

• 完整的 Node.js/NPM 兼容：不再是实验性支持，而是一等公民级别的兼容。npm: 前缀开箱即用，node_modules 可选生成。
• deno.json 作为统一配置中心：替代了过去散落各处的配置方式。
• LTS（长期支持）版本策略：从 2.1 开始引入 LTS 机制，给企业和生产环境吃了一颗定心丸。
• JSR（JavaScript Registry）：推出全新的模块注册表，原生支持 TypeScript，与 deno.land/x 共存。
• 工作区（Workspaces）支持：适配 monorepo 工程实践。

// Deno 2.0 风格：可以直接用 NPM 包
import express from 'npm:express@4'
 
const app = express()
app.get('/', (req, res) => {
  res.send('Hello from Deno 2.0!')
})
 
app.listen(3000)

3.4 Deno 2.5–2.6（2025 下半年至今）

到了 2025–2026 年，Deno 的迭代进入了一个「完善期」：

• Deno 2.5：成为首个 LTS 版本之一，稳定性和 Node 兼容性进一步提升。
• Deno 2.6（2025 年 12 月）：
  • dx 命令：等价于 npx，可以直接运行 npm/JSR 包中的二进制命令。
  • 更细粒度的权限：安全模型进一步完善。
  • deno audit：内建安全审计工具，检查依赖中的已知漏洞。
  • tsgo 实验性支持：基于 Go 重写的 TypeScript 类型检查器，显著加速类型检查。
  • 内建 bundler：不再需要 esbuild 或 Rollup。
• Deno Deploy GA（2026 年 2 月）：Deno 的边缘部署平台正式全面可用。
• Deno Sandbox（2026 年 2 月）：基于 Linux microVM 的代码沙箱，专为运行不可信代码设计——对 AI Agent 场景尤其有价值。

四、核心设计哲学

抛开版本号，Deno 有几条贯穿始终的设计原则：

4.1 安全优先

# 不给任何权限，脚本无法做任何 I/O
deno run script.ts
 
# 只允许读取当前目录，只允许访问特定域名
deno run --allow-read=. --allow-net=api.example.com script.ts
 
# 允许所有权限（开发时的偷懒用法）
deno run -A script.ts

Node.js 的默认权限模型是「全部允许」，Deno 反过来：默认全部拒绝。这在安全意识日益增强的今天显得尤为重要——尤其是在供应链攻击频发的 NPM 生态中。

4.2 Web 标准优先

Deno 尽可能与浏览器保持一致：

• fetch() 而不是 http.request()
• Request / Response 对象而不是 req / res
• URL、URLSearchParams、TextEncoder、TextDecoder 全部原生支持
• ES Modules 而不是 CommonJS

这意味着你在 Deno 中写的代码，很多可以几乎不修改地运行在浏览器或 Cloudflare Workers 等边缘环境中。

4.3 TypeScript 一等公民

// 不需要任何配置，直接运行
// deno run greet.ts
 
function greet(name: string): string {
  return `Hello, ${name}!`
}
 
console.log(greet('Deno'))

没有 ts-node、没有 tsx、没有 tsconfig.json 的必要配置。TypeScript 在 Deno 中就是默认语言。

4.4 内建一切（Batteries Included）

五、实战：2026 年用 Deno 写一个 API 服务

说了这么多背景，来看一个实际的例子。用 Deno 2.6 写一个简单的 REST API：

5.1 初始化项目

# 创建项目目录
mkdir my-api && cd my-api
 
# 初始化 deno.json
deno init

生成的 deno.json：

{
  "tasks": {
    "dev": "deno run --watch -A main.ts"
  }
}

5.2 编写服务

// main.ts
const kv = await Deno.openKv() // Deno KV：内建的键值存储
 
// 使用标准库的 Web 标准 HTTP 服务器
Deno.serve({ port: 8000 }, async (req: Request): Promise<Response> => {
  const url = new URL(req.url)
 
  if (url.pathname === '/api/notes' && req.method === 'GET') {
    const notes: { id: string; text: string }[] = []
    for await (const entry of kv.list({ prefix: ['notes'] })) {
      notes.push(entry.value as { id: string; text: string })
    }
    return Response.json(notes)
  }
 
  if (url.pathname === '/api/notes' && req.method === 'POST') {
    const body = await req.json()
    const id = crypto.randomUUID()
    const note = { id, text: body.text }
    await kv.set(['notes', id], note)
    return Response.json(note, { status: 201 })
  }
 
  return new Response('Not Found', { status: 404 })
})
 
console.log('Server running on http://localhost:8000')

注意几个亮点：

• Deno.serve() 基于 Web 标准的 Request / Response，与 Cloudflare Workers 的 API 几乎一致。
• Deno.openKv() 是 Deno 内建的键值存储，本地开发时使用 SQLite，部署到 Deno Deploy 时自动切换为分布式数据库。
• crypto.randomUUID() 是 Web 标准 API，不需要导入任何库。

5.3 运行与测试

# 开发模式（带文件监听）
deno task dev
 
# 指定权限运行
deno run --allow-net --allow-read --allow-write main.ts

5.4 编写测试

// main_test.ts
import { assertEquals } from 'jsr:@std/assert'
 
Deno.test('GET /api/notes returns array', async () => {
  const res = await fetch('http://localhost:8000/api/notes')
  const data = await res.json()
  assertEquals(Array.isArray(data), true)
})
 
Deno.test('POST /api/notes creates a note', async () => {
  const res = await fetch('http://localhost:8000/api/notes', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: '测试笔记' }),
  })
  const data = await res.json()
  assertEquals(res.status, 201)
  assertEquals(data.text, '测试笔记')
})

deno test --allow-net

5.5 部署到 Deno Deploy

# 安装 deployctl CLI
deno install -gArf jsr:@deno/deployctl
 
# 部署
deployctl deploy

从编写到部署，没有 webpack、没有 tsconfig.json、没有 node_modules、没有 Docker——这就是 Deno 追求的开发体验。

六、Deno 适合什么场景？

经过这几年的观察和实践，我认为 Deno 在以下场景中表现尤为出色：

适合用 Deno 的场景

• API 服务 / 微服务：Web 标准 API + 内建 KV + Deno Deploy 的组合非常丝滑。
• CLI 工具和脚本：权限沙盒 + 单文件分发 + TypeScript 开箱即用，写 CLI 很舒服。
• 边缘计算 / Serverless：Deno Deploy 是为此而生的平台。
• AI Agent 的代码沙箱：Deno Sandbox（2026 年 2 月发布）提供了 microVM 级别的隔离，天然适合运行 LLM 生成的不可信代码。
• 教学和原型验证：零配置 + 安全默认 = 学生和新手的理想环境。

暂时不适合的场景

• 已有大型 Node.js 项目的整体迁移：虽然兼容性越来越好，但仍有边角坑。
• 深度依赖 Node 原生 C++ addon 的项目：FFI 支持在进步，但与 Node 的 N-API 生态仍有差距。
• 团队全员对 Node 范式根深蒂固的情况：切换心智模型需要时间和意愿。

七、Deno 与 Node.js / Bun 的关系

到了 2026 年，JavaScript 运行时的格局已经很清晰了：

• Node.js 是基石——庞大的生态、海量的生产验证、无数的现存项目。它不会消失，但也不再是唯一选项。
• Bun 是加速器——用极致的性能和 all-in-one 的工具链，解决「Node 太慢太碎」的日常痛点。
• Deno 是重新设计者——从安全模型到模块系统，从工具链到部署平台，它试图回答「JS 运行时的正确形态是什么」。

有意思的是，这三者正在相互影响：

• Node.js 22+ 引入了实验性的权限模型（--experimental-permission），这显然是 Deno 的影响。
• Node.js 也在推进原生 TypeScript 支持（--experimental-strip-types）。
• Bun 的 all-in-one 理念，与 Deno 的内建工具链不谋而合。

竞争的结果是所有人受益。无论你最终选择哪个运行时，Deno 的存在都在推动整个 JavaScript 生态变得更安全、更标准、更现代。

八、总结

Deno 的故事是一个关于「技术反思」的故事。

Ryan Dahl 没有选择在 Node.js 上修修补补——他选择了重来一次。从 2018 年的那场演讲到 2026 年的今天，Deno 走过了八年。它不再是那个「只有理想主义者才用」的实验品，而是一个拥有 LTS 版本、生产级部署平台、完善 NPM 兼容的成熟运行时。

如果你还没有尝试过 Deno，现在正是一个好时机。不需要迁移你的所有项目，不需要放弃你的 Node 知识——只需要：

curl -fsSL https://deno.land/install.sh | sh
deno run https://examples.deno.land/hello-world.ts

然后，体验一下「如果 JavaScript 运行时重来一次」会是什么感觉。