三种动态代码执行方式对比：Async构造器、eval与vm.runInThisContext

1. 内存与上下文共享 #

eval #

• 完全共享当前执行上下文的所有变量、函数和作用域，比如示例里的obj这类外部变量能直接访问
• 内存完全共享，执行后的变量会留在当前作用域，极易污染现有环境
• 优点：无需额外处理就能访问外部资源，代码编写简单
• 缺点：上下文污染风险极高，容易引发变量冲突或安全问题

vm.runInThisContext #

• 仅共享全局对象（比如Node.js的global），不共享当前函数作用域的变量
• 示例里的obj无法直接访问，因为它属于局部作用域，直接运行会报错，需把obj挂载到全局才能访问
• 优点：隔离局部作用域，降低上下文污染风险
• 缺点：无法直接访问局部变量，需要手动传递全局资源，灵活性较低

Async函数构造器（Object.getPrototypeOf(async function(){}).constructor） #

• 创建的async函数在独立的函数作用域执行，但可通过闭包间接访问外部变量（示例里obj能被访问就是因为函数构造器的代码引用了外部变量形成闭包）
• 执行后的变量不会污染当前作用域，属于独立的函数上下文
• 优点：兼顾了一定灵活性（可访问外部变量）和作用域隔离性
• 缺点：闭包可能导致内存泄漏，且代码可读性差

2. 事件循环与微任务处理 #

eval #

• 同步执行代码，微任务（比如Promise.resolve）会加入当前事件循环的微任务队列，在当前同步代码执行完成后立即执行
• 不会阻塞事件循环的其他阶段，但如果执行大量同步代码，会阻塞后续任务
• 无特殊微任务模式控制

vm.runInThisContext #

• 在Node.js中，vm模块支持microtaskMode配置（比如afterEvaluate），能控制微任务的执行时机
• 默认微任务会在代码执行完成后立即执行；若设置microtaskMode: 'none'，则会延迟到下一个事件循环周期执行
• 优点：可灵活控制微任务执行时机，适合批量处理微任务的场景
• 缺点：仅Node.js支持该配置，浏览器环境不可用

Async函数构造器 #

• 代码在async函数中执行，await会自动处理微任务，将后续代码加入微任务队列
• 微任务执行遵循async函数的默认行为，和普通async函数一致
• 优点：原生支持异步流程处理，无需额外配置
• 缺点：无法自定义微任务执行时机，灵活性不如vm模块

3. 性能与阻塞情况 #

• eval：性能最差，引擎无法对其预编译优化，每次执行都要重新解析代码，大量使用会导致性能下降
• vm.runInThisContext：性能优于eval，引擎可进行一定预编译优化，且作用域隔离减少了上下文切换开销
• Async函数构造器：性能与普通async函数接近，但由于是动态创建函数，无法享受静态编译优化，性能略低于普通async函数

4. 安全性 #

• eval：安全性最低，执行的代码拥有当前上下文的全部权限，极易被注入恶意代码
• vm.runInThisContext：安全性较高，仅共享全局对象，还可通过vm.createContext等配置进一步限制权限
• Async函数构造器：安全性介于两者之间，虽有作用域隔离，但仍能通过闭包访问外部变量，存在一定安全风险

内容的提问来源于stack exchange，提问作者Jacob Morrison