Deno 与 Node.js 在原生异步 API 设计上有什么核心区别？

Deno 采用全局命名空间配合显式权限控制，原生异步 API 基于 Promise 且更贴近 Web 标准；Node.js 依赖模块导入，历史包袱导致回调与 Promise 并存，默认拥有完整系统权限。

先说结论：两者底层异步模型相似（事件驱动），但 Deno 在 API 暴露方式、权限管控和标准对齐上更激进，Node.js 更注重向后兼容。

适合：需要评估运行时选型或进行代码迁移的团队
重点看：权限标志、模块导入方式、全局对象差异、错误处理机制
别忽略：Node.js 的回调遗留问题与 Deno 的权限拒绝风险

核心异步 API 设计差异

Node.js 早期受限于 JavaScript 标准，大量 IO API 采用回调函数（Callback）风格，后续虽引入 Promise 但保留了旧模式。Deno 诞生时 ES6 已普及，所有原生异步 API 均基于 Promise，强制使用 async/await 或 .then()，避免了回调地狱。

错误处理机制对比：

Node.js 回调风格需手动检查第一个参数 error，而 Promise 风格（Node.js 与 Deno）均通过 reject 抛出异常，需使用 try/catch 捕获。

// Node.js 回调风格 (旧) const fs = require("fs");
fs.readFile("./data.txt", (err, data) => {
  if (err) throw err; // 手动检查错误
  console.log(data);
});

// Node.js Promise 风格 (fs/promises)
const fs = require("fs/promises");
try {
  const data = await fs.readFile("./data.txt");
} catch (err) {
  console.error(err); // 捕获 reject
}

// Deno 原生 Promise 风格
try {
  const data = await Deno.readFile("./data.txt");
} catch (err) {
  if (err instanceof Deno.errors.PermissionDenied) {
    // 特定权限错误处理
  }
  console.error(err);
}

API 签名与返回值对比

虽然功能相似，但具体 API 的参数顺序、返回值类型存在差异。Node.js 传统 API 常返回 Buffer，而 Deno 更倾向于 Uint8Array 以贴近 Web 标准。

功能	Node.js (fs/promises)	Deno (原生)
读取文件	`fs.readFile(path[, options])` 返回：`Buffer` 或 `string`	`Deno.readFile(path)` 返回：`Uint8Array`
HTTP 请求	`fetch()` (全局需 Node 18+)	`fetch()` (全局原生支持)
环境变量	`process.env` (同步对象)	`Deno.env.get()` (需权限)
错误类型	标准 Error 对象	Deno.errors 命名空间 (如 PermissionDenied)

运行时权限对异步 IO 的影响

这是两者最显著的工程差异。Node.js 默认拥有完整系统权限，异步 IO 失败通常源于文件系统错误或网络问题。Deno 默认沙箱隔离，未授权的文件或网络访问会在 Promise 初始化阶段直接 reject，抛出权限错误。

验证权限错误：

# Deno 未授权运行
$ deno run app.js
# 报错：Uncaught PermissionDenied: read access to "./data.txt", run again with the `--allow-read` flag

# Node.js 无权限概念
$ node app.js
# 除非 OS 层面限制，否则直接执行

在迁移代码时，需特别注意 Deno 的权限标志会导致异步操作在启动阶段或调用阶段立即失败，而非等待 IO 完成。

事件循环底层差异

Node.js 基于 C++ 和 libuv 库，Deno 基于 Rust 和 Tokio 异步运行时。虽然对开发者而言都是事件驱动，但 Tokio 的无锁调度机制使得 Deno 在高并发异步任务下的微任务（Microtask）执行一致性更好。

在实际工程中，这意味着 Deno 的 Promise 解析顺序可能更贴近浏览器标准，而 Node.js 在旧版本中可能存在细微的 tick 差异。对于大多数业务逻辑无影响，但在编写底层库或测试框架时需留意。

验证与常见坑

1. 验证异步行为

在 REPL 环境中输入 Deno 回车。Deno 会输出包含 readFile、writeFile 等方法的全局对象信息；Node.js 中则没有该全局对象，需导入模块后才能访问对应方法。

2. 常见坑：权限遗漏导致运行失败

从 Node.js 迁移到 Deno 时，最容易忽略的是权限标志。代码逻辑没问题，但启动时缺少 `--allow-read` 会导致文件操作直接报错。建议在开发阶段就建立明确的权限清单。

3. 常见坑：数据类型转换

Node.js 的 Buffer 是 Uint8Array 的子类，但 Deno 直接使用 Uint8Array。如果代码依赖 Buffer 特有方法（如 .toString("hex")），在 Deno 中可能需要使用 new TextDecoder() 或标准库方法进行转换。

4. 常见坑：模块路径解析不同

Node.js 依赖 node_modules 和 package.json 解析模块路径。Deno 默认通过 URL 导入依赖，不使用 node_modules。如果代码中混用了相对路径导入第三方库，可能在 Deno 中无法解析，需改为 URL 或使用 import map。