Trusted Types 本身不处理 eval，仅管控 DOM 层高危注入（如 innerHTML、script.src）；eval 属 JavaScript 引擎层动态执行，需通过静态分析、运行时拦截与重构专项治理，Trusted Types 仅作辅助验证。
Trusted Types 本身不处理 eval，它只管控 DOM 层的高危注入（如 innerHTML、script.src 等）。而 eval 是 JavaScript 引擎层的动态执行机制，属于完全不同的安全域。要彻底消除旧项目中遗留的 eval，必须结合静态分析、运行时拦截与重构策略，Trusted Types 只能作为辅助验证环节，不能替代对 eval 的专项治理。
识别所有 eval 及等效危险调用
先明确哪些代码模式等同于 eval 的风险等级：
-
eval()、Function()构造函数（传入字符串参数） -
setTimeout(string, ...)、setInterval(string, ...) -
new Function(...)（尤其带动态拼接参数的） - 第三方库中隐式使用
eval的模块（如某些老版本模板引擎、JSONP 工具）
建议用 ESLint 插件 @typescript-eslint/no-implied-eval 或自定义规则扫描全量 JS/TS 代码；也可借助 untrusted-types Chrome 扩展在运行时捕获实际触发点，定位真实调用上下文。
分阶段替换：从阻断到重构
直接删除 eval 往往导致功能断裂，需按风险和可控性分级处理：
- 高危且可替代：如 JSON 解析改用
JSON.parse()；模板渲染迁移到安全的编译型方案（如 Handlebars 预编译、Lit 模板） - 中危且需封装：将
Function构造逻辑收口到统一工厂函数，并加入白名单校验（例如只允许预设函数名 + 固定参数结构） - 低频但难删：对历史插件系统或配置驱动逻辑，引入沙箱环境（如
vm2在服务端，或iframe+postMessage在前端隔离执行）
禁止“用 eval 拼 HTML 再塞进 innerHTML”这类双重危险组合——Trusted Types 会拦住后半步，但前半步已造成代码执行风险。
用 CSP + Trusted Types 做兜底防护
即使完成 eval 清理，也需防止未来误引入。通过 CSP 强制约束：
- 添加
Content-Security-Policy: script-src 'self'; unsafe-eval→ 改为script-src 'self'（移除unsafe-eval） - 配合
require-trusted-types-for 'script'，使任何未走可信策略的 DOM 注入立即报错 - 开发期启用
Content-Security-Policy-Report-Only收集违规日志，确认无残留eval或绕过行为
注意：eval 被禁用后，浏览器控制台调试仍可用，但生产环境脚本将无法执行。
建立持续审计机制
防止 eval 回归的关键是自动化卡点：
- CI 流程中加入
grep -r "eval\|new Function\|setTimeout.*'" src/类文本扫描 - 构建工具（如 Webpack/Vite）配置
eslint-webpack-plugin或vite-plugin-checker实时告警 - 定期用
npm audit和yarn audit检查依赖项是否含eval（常见于老旧 polyfill 或工具包）
审计报告应明确标注位置、风险等级、推荐替换方案，而非仅提示“存在 eval”。
