Function构造函数不是eval的安全替代品，而是通过参数声明创建独立词法作用域，强制显式传入依赖变量，实现上下文隔离；它不共享调用处作用域，执行在全局编译、仅认自身参数，调试清晰但不可信输入仍危险。
Function 构造函数不是 eval 的“安全替代品”，但它是一种可控的、作用域明确的动态执行方式，适用于变量来源可信、需隔离局部作用域的场景。关键不在于“代替 eval”，而在于“用对方式”：它不共享调用处的词法环境，必须显式传入所有依赖变量。
Function 构造函数如何实现上下文隔离
它通过参数声明自动创建独立词法作用域，所有变量都必须作为参数名列出，并在调用时一一传入值。这天然避免了意外访问外层变量或污染全局对象。
- 正确写法：
new Function('a', 'b', 'return a + b')(1, 2)—— a 和 b 是函数内可访问的局部变量 - 错误写法：
new Function('return a + b')()—— a、b 未声明，运行时报ReferenceError - 即使外层有
const x = 100，Function 内也无法访问，除非你把它加进参数列表并传值
为什么它比 eval 更适合受控上下文
eval 总是在调用位置的作用域中执行，可能读写当前函数的局部变量、闭包甚至 this；而 Function 构造函数始终在全局作用域编译，执行时只认自己声明的参数——这种“强制清空”反而带来了确定性。
- eval 可能意外修改局部变量：
let count = 0; eval('count++');→ count 变为 1 - Function 不会：除非你把
count显式作为参数，否则它根本看不见 - 调试更清晰：错误堆栈指向生成的函数，而非模糊的 eval 调用点
安全使用的关键细节
Function 构造函数本身不防注入，输入不可信时依然危险。真正提升安全性的操作是结合上下文封装与防护逻辑。
- 永远启用严格模式：
new Function('"use strict"; return ' + expr)，防止静默失败和意外全局变量 - 禁止用户控制参数名：参数名应由系统固定（如
'data', 'utils', 'config'），避免通过 Object.keys 动态拼接不可信键名 - 对 script 字符串做基础校验：过滤
function、class、import、eval等关键词（仅作辅助，不能替代可信输入） - 如需支持变量注入，推荐封装成
evalWithContext(script, {x: 1, y: 2})形式，内部用 Function + 参数展开，而非暴露原始构造过程
它不适合哪些场景
别为了“不用 eval”而硬套 Function。当需求涉及访问当前作用域、依赖模块导入、或需要闭包行为时，它不仅不适用，还会引入隐蔽 bug。
- 不能访问 import 的模块：
import { api } from './lib'; new Function('api.do()')()→ 报错 - 不能隐式使用 this：
const obj = { val: 42 }; new Function('return this.val')()→ 返回 undefined（this 指向 globalThis） - 无法捕获 try/catch 外部异常：错误只能在 Function 执行时抛出，无法被外层统一拦截（除非你在函数体内手动包装）
