如何通过 Function 构造函数实现动态代码生成的安全评估与性能开销分析-js教程-PHP中文网

Function构造函数是高风险原语，非安全方案：其安全性取决于字符串内容是否可信，存在RCE、CSP绕过等风险，且性能开销大、调试困难；应默认禁用，仅在输入可控、逻辑静态、通过AST扫描、有性能验证时例外启用。

如何通过 function 构造函数实现动态代码生成的安全评估与性能开销分析

Function 构造函数确实能实现动态代码生成，但它本身不是“安全方案”，而是一个高风险原语——安全评估与性能开销必须前置判断，而非事后补救。

Function 构造函数的安全性不取决于语法形式，而完全由传入的字符串内容决定：

函数体（最后一个参数）必须100%可信：若来自用户输入、URL、API响应、DOM文本或日志字段，就等同于开放远程代码执行（RCE）入口。攻击者可注入alert(document.cookie)、fetch('/admin/delete')等任意逻辑。
参数名列表也需校验：不能含非法标识符（如'user.name'、'x;alert(1)'），否则构造阶段直接抛SyntaxError，暴露服务端解析行为。
无作用域隔离能力：它创建的函数运行在全局作用域，可自由访问window、document、localStorage等敏感对象，无法通过with或Proxy自然限制——所谓“隔离”需额外构建沙箱环境（如vm2或iframe），Function仅是其中一环。
CSP绕过风险真实存在：若页面启用了script-src 'self'但未显式禁止'unsafe-eval'，Function 构造函数仍可执行，成为CSP策略的盲区。

引擎对 Function 字符串的处理远重于普通函数：

无法被V8等引擎优化或内联：字符串需重新词法分析、语法解析、生成AST、编译为字节码，整个流程无法复用缓存，且跳过JIT热路径。
内存持续增长：每调用一次new Function，就生成一个新函数对象；若绑定到长生命周期对象（如事件监听器、模块导出），GC无法及时回收，易引发内存泄漏。
调试成本陡增：错误堆栈指向eval code或function code，不包含原始文件名与行号，Source Map基本失效。
压缩工具失效：UglifyJS、Terser 等无法解析字符串内的代码，导致上线后逻辑裸露、体积膨胀、tree-shaking 失效。

绝大多数所谓“动态需求”，其实可通过更可控的数据驱动方式满足：

表达式求值场景：用acorn或esprima解析AST，白名单校验节点类型（只允许BinaryExpression、Literal、Identifier），再递归求值——不执行代码，只计算结构。
规则引擎场景：定义JSON Schema描述条件（如{"op": "gt", "left": {"ref": "age"}, "right": 18}），用固定解释器执行，杜绝任意JS。
模板渲染场景：预编译模板为纯函数（如const fn = (data) => `${data.name} `），避免运行时拼接+Function。
插件扩展场景：采用dynamic import()加载独立模块，利用ESM天然的隔离性与权限控制，比Function更轻量、更安全。