加载失败
Wasmer（一个 WebAssembly 运行时/工具链项目）发布了 Edge.js，目标是让现有 Node.js 应用在 `--safe` 模式下跑进 WebAssembly sandbox，同时尽量保持对 Node.js 生态的兼容。评论区最关心的不是“能不能跑”，而是默认是否真的沙箱化、`fs`/网络/进程边界怎么限制，以及它与 WASIX（在 WebAssembly 上补充类 POSIX 系统能力的扩展）和传统容器、Firecracker（微虚拟机）相比的安全模型。维护者补充说，当前默认并不启用 sandbox，而是通过 `edge`、`node`、`npm` 之类的包装命令维持原有工作流，并宣称可插拔 JS 引擎（V8、QuickJS、SpiderMonkey、Hermes 等）和 Next.js 兼容性。讨论还延伸到浏览器、Electron、iOS 和 LLM/agent 代码执行等场景，核心问题是能否在低运维成本下安全运行不可信代码。
不少人被 `--safe` 是否默认开启搞糊涂了，因为标题看起来像是天然沙箱，但维护者说明当前默认是非 sandbox 的 native 模式，只有加 `--safe` 才切到 WebAssembly 路径。这样做的理由一是 native 路径快约 10–20%，二是先把 Wasm 集成打磨成熟再把它做成默认。关于 `fs`，评论里最实际的问题是“sandbox 里还能不能读磁盘”，答案是只暴露当前工作目录，方便本地开发，但不会任意访问全盘。`process.cwd()` 的行为差异也被拿来当成一个小实验，帮助理解安全边界到底在哪里。
讨论里有明显怀疑声：把隔离责任从 OS/container 转移到 runtime（WASIX + shims）是否真的更安全，尤其在 hostile workloads、native modules 和 `libuv` 参与时。有人直接把 Firecracker（微虚拟机）拿来对比，认为如果只是为了跑不可信代码，微虚拟机已经能支持任意语言，Node 专用方案到底为何更优并不明显。也有人提出更现实的需求是云端函数、个人电脑上缺少安装权限的用户、或 AI coding/agent 场景；在这些场景里，单个 Edge.js process 只服务一个 tenant 可能比多租户共享更可控。整体上，质疑焦点不是“能不能跑 JS”，而是能否在高并发、资源滥用、逃逸向量面前真正守住边界。
有一条很强的想象线是：把 Node 直接搬进浏览器，像 WebContainers 一样在前端跑完整应用，但用 in-memory `fs` 和禁用 fork 等方式接受浏览器限制。维护者明确表示这条路是可行的，而且会比其他方案更兼容；相关项目 BrowserPod（一个在浏览器里运行 Node/Python 的项目）也被拿来做对照。评论里还提到可以演示 `localhost:3000`、甚至配一个轻量 WASM database，让这种“浏览器里的 nodejs”更像真实开发环境。这个方向把 Edge.js 从服务器沙箱扩展成了一个可能的前端开发运行时。
不少评论在追问底层架构：Edge.js 说自己支持可插拔 JS engine，那到底是调用 Wasmer，还是把 V8/JSC 直接编译进 WebAssembly 再跑起来。维护者和其他回复暗示，核心思路更接近后者，而且可选 engine 包括 V8、SpiderMonkey、QuickJS、Hermes 等。兼容性也是卖点之一：它被描述为能通过非 VM 模块的 Node spec tests，并且对 Next.js 也是 fully compatible。`edge node`、`edge npm`、`edge pnpm` 这类例子则说明它不是要重做一套 package 体系，而是尽量让现有 `node` 工作流原样迁移。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
很多人把它看成 LLM-generated code 的安全执行层：在 Electron app 里跑模型生成的脚本，或者给 agent workload 单独开沙箱，都是高频场景。相关回复里提到，Edge.js 理论上可以借 Electron 自己的 V8 做一个“sandboxed within electron”的执行环境，而不是依赖更重的外部容器。另一种思路是每个 sandboxed call 单独起一个 Edge.js process，用进程隔离换取更稳的多租户边界。这个方向的吸引力在于，它更贴近 AI 工具链中“频繁执行不可信代码但又不能放开权限”的现实需求。
平台问题也被问到：是否能跑在 iOS、如何处理文件系统和 networking、以及能否挂上自定义 handler。维护者给出的答案是，iOS 上理论可行，可以考虑 JavascriptCore（Apple 的 JS 引擎）、V8 的 jitless 模式或 QuickJS；只是目前还没有现成原型。这个回答说明 Edge.js 目标不是绑定某个宿主环境，而是尽量把“JS 运行时 + host capability”拆开。对想在移动端或受限设备上嵌入 Node 生态的人来说，这一点很关键。
WebAssembly/WASM: 一种可移植的低级字节码格式，可在浏览器或其他运行时的沙箱中执行。
WASIX: 在 WASI 基础上扩展的接口层，提供更接近 POSIX 的文件、进程和网络能力。
V8: Google 的 JavaScript engine，广泛用于 Node.js 和 Chromium。
QuickJS: 轻量级、可嵌入的 JavaScript engine，适合受限环境。
Next.js: 基于 React 的全栈框架，常被用作 Node 生态兼容性测试对象。