Bun 完全兼容 Node.js 的 fs 等核心模块，import fs from 'fs' 与 import fs from 'node:fs' 在功能、性能和行为上完全等价；二者指向同一模块实例，无需强制迁移，但推荐统一使用 fs（更简洁、更符合 Bun 原生风格）。
bun 完全兼容 node.js 的 `fs` 等核心模块，`import fs from 'fs'` 与 `import fs from 'node:fs'` 在功能、性能和行为上完全等价；二者指向同一模块实例，无需强制迁移，但推荐统一使用 `fs`（更简洁、更符合 bun 原生风格）。
在 Bun 中，fs 是开箱即用的内置核心模块——你无需安装任何包，也无需额外配置，直接导入即可使用：
// ✅ 推荐：简洁、直观、Bun 官方示例普遍采用
import * as fs from "fs";
// 或 ES 模块风格
import { readFileSync } from "fs";
// ✅ 合法且等效：语义上强调“Node.js 内部模块”，但非必需
import * as fs from "node:fs";
// ✅ 验证二者是否为同一对象（实测结果为 true）
import fs1 from "fs";
import fs2 from "node:fs";
console.log(fs1 === fs2); // true
为什么没有性能差异？
Bun 的模块解析器在底层已将 fs 和 node:fs 统一映射至同一原生实现（基于 JavaScriptCore 封装的高效文件系统接口），不存在运行时重定向或代理开销。这与 Node.js 的设计逻辑一致——node: 协议仅是一种命名约定（用于显式区分内置模块与第三方包），并非独立加载路径。
迁移建议与最佳实践：
- ✅ 保持现有 fs 导入不变：若项目已广泛使用 import fs from 'fs'，无需修改；Bun 100% 兼容，且语义更自然；
- ⚠️ 避免混用：同一项目中不建议部分文件用 fs、部分用 node:fs，易造成维护混乱；建议通过 ESLint 规则（如 node/no-restricted-imports）统一约束；
- ? 不要盲目替换为 node: 前缀：Bun 并未要求或鼓励此写法；相反，其官方文档、CLI 脚手架及 bun init 生成的模板均默认使用无前缀形式（如 import { serve } from "http"）；
- ? 注意真正需调整的场景：相比导入路径，更需关注 Bun 不兼容的 API 行为差异，例如：
- __dirname 和 __filename 不可用 → 改用 import.meta.dir / import.meta.url；
- require() 仅限 CommonJS 模块（Bun 默认启用 ESM）→ 优先使用 import；
- 某些 node: 子模块（如 node:crypto) 的部分方法尚未完全对齐（如 randomFillSync 的参数校验），建议查阅 Bun v1.3+ 兼容性表。
总结：fs 与 node:fs 在 Bun 中是功能、性能、行为完全一致的同义导入，选择取决于代码风格一致性而非技术必要性。拥抱 Bun 的“极简哲学”——用最直白的方式写最高效的代码：就用 fs。
