JavaScript 中应彻底避免使用 eval() 及同类高危操作（如 new Function、setTimeout(string) 等），因其易导致代码注入与 XSS；须改用 JSON.parse、方括号属性访问、白名单函数映射等安全替代方案，并对用户输出按上下文进行敏感编码。
JavaScript 中 eval() 是最危险的内置函数之一，它直接在当前作用域执行字符串代码，极易引发代码注入、XSS 和权限失控。防范核心不是“怎么安全用 eval”，而是“彻底避免使用它”，并用更可控、可审计的方式替代动态逻辑。
立即停用 eval 及同类高危操作
eval、new Function()、setTimeout(string, ...)、setInterval(string, ...)、document.write()、innerHTML = ...（含未转义插入）都属于同级风险操作。它们共同特点是：将不可信字符串当作代码或 HTML 解析执行。
- 哪怕输入来自“内部配置”，只要该配置可能被篡改（如通过构建脚本注入、API 返回、localStorage 持久化），就不再可信
- CSP 策略中若启用
'unsafe-eval'，等于主动关闭浏览器最后一道防线 - 严格模式（
"use strict"）不能阻止 eval 访问或修改外层变量，仅限制部分副作用（如隐式全局）
按场景选择安全替代方案
绝大多数 eval 使用场景都有语义清晰、类型安全、引擎可优化的替代方式：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
解析 JSON 数据：一律用
JSON.parse(str)，它只接受标准 JSON，拒绝执行任意代码；比 eval 快 10 倍以上，且自动校验格式 -
动态读取对象属性：用方括号语法
obj[key]或Reflect.get(obj, key)，避免拼接字符串再 eval -
执行预定义逻辑分支：建立白名单映射表，如
const handlers = { save: doSave, delete: doDelete }，再通过handlers[action]?.(data)调用 -
渲染用户内容：优先用框架（React/Vue）的默认插值（自动转义）；若需插入 HTML，必须先经
DOMPurify.sanitize()过滤，而非依赖手工正则 -
运行沙箱表达式（极少数必要场景）：使用专用沙箱库（如
vm2），而非裸 eval；确保无全局访问、无原型链污染、有超时与内存限制
输出时必须做上下文敏感编码
即使不用 eval，只要把用户数据插入到 HTML、JS 字符串、URL 或 CSS 中，仍可能触发注入。编码不是“统一转义”，而是按目标上下文选择对应方式：
立即学习“Java免费学习笔记（深入）”；
- 插入 HTML 标签之间 → 使用 HTML 实体编码（如
<替代），推荐 <code>textContent或框架自动机制 - 插入 JavaScript 字符串字面量 → 对引号、反斜杠、换行符等进行 JS 字符串转义（可用
JSON.stringify()生成安全字符串） - 拼接到 URL 查询参数 → 使用
encodeURIComponent()，不可用encodeURI() - 插入内联事件（如
onclick="..."）→ 完全禁止；改用事件委托 + data 属性 + 函数调用
加固执行环境与开发流程
技术手段之外，需从工程层面切断风险路径：
- 在 CI 流程中加入静态扫描（如 ESLint 规则
no-eval、no-new-func），禁止提交含 eval 的代码 - HTTP 响应头强制启用 CSP：
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'; - 所有用户输入字段（表单、URL 参数、API 响应）在进入任何渲染或执行环节前，必须经过类型校验 + 长度限制 + 特殊字符过滤（非简单黑名单）
- 前端日志、错误上报中避免打印原始用户输入，防止攻击者利用调试信息构造 payload
