Function构造函数本身是风险源而非风险评估工具；需检查输入来源可信性、作用域隔离性、运行时防护措施及错误可观测性。
Function 构造函数本身不是风险评估工具，而是风险源——它直接触发动态代码生成，因此“利用它做安全风险评估”这个说法存在根本性误解。真正要做的是：**识别它在哪里被使用、判断输入是否可控、确认执行上下文是否隔离、验证是否绕过CSP或静态分析**。下面从实操角度拆解关键检查点。
看输入来源是否可信
Function 构造函数的函数体字符串（最后一个参数）和参数名列表（前面的字符串）一旦来自以下任意渠道，即属高风险：
- 用户提交的表单字段、URL 查询参数、localStorage 数据
- DOM 中读取的 innerHTML、dataset、attribute 值
- 后端 API 返回的 JSON 字段（如
config.script）、模板变量渲染结果 - 第三方 SDK 注入的配置对象、低代码平台导出的表达式字符串
只要其中任一环节未做白名单校验或 AST 级解析，就可能被注入 fetch('/steal?c='+document.cookie) 或 eval(atob('...')) 类恶意载荷。
查作用域与依赖传递方式
Function 创建的函数没有闭包，所有变量必须显式传入。若代码中出现未声明变量（如直接写 api.send(data)），说明它隐式依赖全局对象——这会绕过模块隔离，也意味着 CSP 的 'unsafe-eval' 策略可能失效。
典型危险信号包括：
- 函数体里调用
document、XMLHttpRequest、localStorage等浏览器 API，但参数列表未包含对应代理对象 - 用
this且未绑定上下文，导致实际指向window或globalThis - 参数名含非法标识符（如
'user.id'或'data[0]'），构造时直接报SyntaxError，说明开发阶段已缺乏基础校验
验执行环境与防护措施
即使输入可控，也要确认是否具备运行时防护：
- 是否在 iframe 沙箱中执行？沙箱属性是否含
allow-scripts但缺失allow-same-origin？ - 是否通过 Web Worker 隔离？Worker 内是否禁用了
eval和Function？ - Node.js 环境下是否启用
vm2或isolated-vm？是否限制了require、process、global访问？ - 前端构建流程中是否启用 ESLint 规则
no-new-func？CI 阶段是否拦截该语法？
没有上述任一防护，仅靠“这段代码只跑内部系统”或“用户没技术能力”等主观判断，不构成有效风控。
测错误反馈与可观测性
Function 构造失败（语法错误）或执行失败（ReferenceError）时，堆栈不指向原始源码位置。这意味着：
- 线上监控无法定位是哪个配置项/表达式出错
- 错误日志中看不到函数体原文，仅显示
Uncaught SyntaxError: Unexpected token - 开发者调试需手动还原字符串拼接过程，效率极低
若项目中大量使用 Function 且无配套日志透出机制（如记录构造时的 functionBody 哈希值），就等于主动放弃问题溯源能力。
