Deno
默认支持 TypeScript 的安全 JavaScript、TypeScript 运行时。
项目概述
Deno 提供现代标准库、内置工具链、权限控制和 Web 标准 API，目标是让服务端 JavaScript 开发拥有更一致的体验。
Deno 由 Ryan Dahl 发起、Deno Land 团队维护并采用 MIT 许可证。它基于 V8、Rust 和 Tokio 构建，将 JavaScript 与 TypeScript 运行时、依赖管理、格式化、代码检查、测试和打包工具整合到一个可执行文件中。Deno 优先采用 Web 标准 API，同时持续增强 Node.js 与 npm 生态兼容性，适合希望减少工具拼装并明确控制程序权限的团队。
主要特点
Deno 将现代运行时、安全模型和日常开发工具组合成一致的 JavaScript / TypeScript 体验。
TypeScript 一等支持
无需额外安装编译器即可直接运行 .ts 和 .tsx 文件，并通过 deno check 在需要时执行严格类型检查。
默认安全的权限模型
文件、网络、环境变量、子进程和 FFI 等敏感能力默认不可用，可通过参数精确授权到目录、主机或变量。
内置完整工具链
单个 deno 命令提供格式化、Lint、测试、基准测试、文档、覆盖率、语言服务与独立可执行文件编译。
Web 标准 API
原生提供 fetch、Request、Response、Web Streams、WebSocket 和 Web Crypto 等熟悉的浏览器标准接口。
Node.js 与 npm 兼容
理解 package.json、npm 包和大量 Node.js 内置 API，便于运行既有项目或复用成熟 npm 依赖。
JSR 与标准库
可从 JSR 安装 TypeScript 原生包，并按需使用 @std 下经过审查、可跨运行时工作的标准库模块。
依赖与工作区管理
deno.json、锁文件、任务和 Workspaces 覆盖单包到 Monorepo 的配置，无需为新项目默认创建 node_modules。
适用场景
从轻量脚本到生产 API，Deno 适合看重 TypeScript、Web 标准和工具链一致性的项目。
TypeScript 后端与 API
Deno.serve、Web 标准请求响应对象和框架生态适合构建 REST API、Webhook 与轻量后端服务。
自动化与运维脚本
可直接运行 TypeScript，并用细粒度权限限制脚本能够读取的目录、环境变量和网络目标。
命令行工具
内置 deno compile 可将程序及依赖打包为独立可执行文件，方便分发不要求用户预装运行时的工具。
边缘与 Serverless 应用
Web 标准 API 和轻量启动模型适合部署到 Deno Deploy 及采用相似接口的边缘运行环境。
Node.js 项目渐进迁移
对 package.json、node_modules、npm 包和 Node API 的兼容能力，可用于评估和逐步迁移现有服务。
多包工作区
Workspaces、共享依赖版本和统一的 fmt、lint、test 命令适合管理应用、库和工具组成的 Monorepo。
优点与注意事项
技术选型不仅要看能力，也要理解它带来的团队成本。
主要优点
Deno 擅长的地方
- TypeScript 可直接执行，项目启动所需配置较少
- 格式化、Lint、测试和文档等工具由运行时统一提供
- 默认拒绝敏感 I/O，并支持细粒度权限范围
- Web 标准 API 降低浏览器、边缘与服务器之间的认知差异
- npm 和 Node.js 兼容能力让现有生态更容易复用
- 无需默认生成 node_modules，可通过全局缓存保持项目目录简洁
需要注意
采用前应考虑的问题
deno run 会移除类型后直接执行，不会自动阻止类型错误；应在开发和 CI 中显式运行 deno check。
依赖 Node.js 边缘行为、安装脚本、原生扩展或特定 node_modules 布局的 npm 包，可能需要额外配置或仍不兼容。
同一线程代码共享权限，--allow-run 和 --allow-ffi 等能力可绕过主要限制；执行不可信代码仍需要操作系统或虚拟机隔离。
相比 Node.js，Deno 的生产经验、托管选择、招聘人才和部分框架集成仍少一些，需要评估组织成本。
大量使用 Deno 命名空间、KV 或权限 API 会增加迁移到其他 JavaScript 运行时的工作量，可优先采用 Web 标准接口。
快速开始
使用内置初始化命令创建一个带测试的 TypeScript HTTP 服务。
bashdeno init hello-deno
cd hello-denotypescriptexport function greet(name: string): string {
return `Hello, ${name}!`;
}
if (import.meta.main) {
Deno.serve(
{ hostname: "127.0.0.1", port: 8000 },
(request) => {
const url = new URL(request.url);
const name = url.searchParams.get("name") ?? "Deno";
return Response.json({
message: greet(name),
runtime: "Deno",
});
},
);
}typescriptimport { assertEquals } from "jsr:@std/assert";
import { greet } from "./main.ts";
Deno.test("greet returns a friendly message", () => {
assertEquals(greet("Ada"), "Hello, Ada!");
});bashdeno check main.ts
deno fmt --check
deno lint
deno test
deno run --allow-net=127.0.0.1:8000 main.ts下一步：开发时把 deno check、deno fmt --check、deno lint 和 deno test 放入统一任务或 CI；生产运行时只授予服务实际需要的主机、文件和环境变量权限。
类似项目
这些运行时同样可以执行服务端 JavaScript，并提供不同程度的 TypeScript 与工具链支持。
Deno vs Node.js
Deno 和 Node.js 都使用 V8 执行服务端 JavaScript，但 Deno 更强调 Web 标准、默认权限隔离和一体化工具链，Node.js 则拥有更长的生产历史与更庞大的生态。
| 比较维度 | Deno | Node.js |
|---|---|---|
| TypeScript | 原生移除类型并执行，使用 deno check 检查 | 现代版本可直接运行部分可擦除语法，复杂场景常配合额外工具 |
| 安全权限 | 敏感 I/O 默认拒绝，可按资源显式授权 | 进程默认继承操作系统用户拥有的访问能力 |
| 工具链 | 内置 fmt、lint、test、bench、doc 与 compile | 核心能力稳定，常从 npm 生态组合第三方工具 |
| API 方向 | 优先 Web 标准，同时兼容 Node API | Node API 为核心，并持续增加 Web 标准支持 |
| 依赖管理 | 支持 JSR、npm、deno.json，可默认不使用 node_modules | 以 package.json、npm Registry 和 node_modules 为主 |
| 生态成熟度 | 生态增长较快，工具选择更集中 | 库、框架、托管、人才和生产案例更加丰富 |
| 更适合 | 新项目、脚本、边缘服务和偏好统一工具链的团队 | 复杂既有系统、依赖深厚 npm 生态和成熟运维体系的团队 |
新建 TypeScript 服务、自动化脚本或希望采用 Web 标准与最小权限的项目，可以优先评估 Deno；已有大型 Node.js 系统若依赖原生扩展、复杂构建和成熟运维平台，继续使用 Node.js 通常更稳妥，也可以先用单个工具或边缘服务试点 Deno。
资料核验
版本、维护信息与本页采用的官方资料来源。
本次核验覆盖 Deno 的核心定位、主要能力、官方入口与开源许可。项目版本持续更新，具体补丁版本、兼容性和迁移要求请在采用前继续核对官方发布记录。
官方仓库未归档，核验时最近可见的代码活动日期为 2026 年 7 月 24 日。该状态表示项目近期仍有公开维护活动，不代表固定发布频率或长期支持承诺。