别再让 eval 给你的代码埋雷：前端安全避坑指南

很多时候，我们为了追求开发效率，会在代码里埋下一颗“定时炸弹”。比如遇到一段需要动态执行的逻辑，或者拿到一串类似代码的字符串，顺手就用上了 eval()。那一刻确实挺爽，代码少，逻辑通，但往往等到上线出了安全事故，才后悔没早看这条建议。

eval() 的本质是让引擎把字符串当成代码去执行。听起来很强大，但它缺乏边界。想象一下，如果这个字符串的来源不可控——哪怕是看似安全的用户输入，经过几层拼接后传入 eval，攻击者就能轻松注入恶意脚本。这不仅仅是变量污染的问题，更是直接的 远程代码执行（RCE）风险。

很多开发者觉得，“我用的时候是本地测试，不会有事”。这种侥幸心理最危险。在真实的生产环境里，前端接口数据可能被篡改，Cookie 中的 token 可能泄露，一旦 eval 拿到了这些数据里的内容，黑客就能在你的网页里悄悄插入挖矿脚本，或者直接窃取用户的登录凭证。它的作用域是当前上下文，这意味着它能访问你应用里所有的全局变量和闭包信息，相当于把自家钥匙交给了陌生人。

既然这么危险，为什么还有人用？通常是为了处理复杂的动态结构体，或者实现插件化加载。这时候，千万别硬刚 eval。如果是纯粹的 JSON 数据解析，请务必使用原生的 JSON.parse()。它不仅比 eval 快得多，而且严格遵循标准，根本不会去执行任何代码逻辑，这是最安全的替代方案。

对于必须动态生成函数逻辑的场景，可以考虑使用 new Function()。虽然它也有作用域泄漏的风险，但至少隔离了局部变量，比直接 eval 多了一层缓冲。不过要注意，它依然能访问全局对象，所以传入的参数必须经过严格校验。如果只是想实现模板渲染或简单的表达式计算，像 mathjs 或者专门的沙箱库会是更好的选择。它们内置了语法检查器，只允许合法的运算，拒绝非法指令。

在处理旧项目迁移时，经常会发现大段依赖 eval 的逻辑。这时候重构不必追求一次性全部替换，可以先从输入源头做白名单过滤。如果用户提交的参数只能是数字或特定字符，那就直接用正则锁死，不给恶意代码留缝隙。同时，开启浏览器的 CSP（内容安全策略），禁止内联脚本执行，能从浏览器层面阻断大部分注入尝试。

在后端 Node.js 环境中，情况稍微复杂些。Node 提供了 vm 模块，可以创建沙箱环境来运行隔离的代码。但这并不意味着绝对安全，历史上有过不少绕过沙箱的漏洞案例。除非你真的有极端特殊的动态代码需求，并且配备了完善的安全审计流程，否则尽量不要在生产环境启用动态执行功能。

回过头看，技术选型的核心在于权衡。eval 带来的那点便利，完全可以通过架构设计来解决。比如将配置项做成静态数据结构，通过预定义的映射关系去调用逻辑，而不是直接执行字符串。这样既保持了灵活性，又彻底切断了注入路径。

代码安全没有侥幸，尤其是面对那些看不见的字符串。当你下次准备敲下 eval() 时，不妨停下来想一想：有没有更稳妥的方式？毕竟，维护一个安全的系统，远比修复一次被黑的事件要简单得多。把控制权握在自己手里，别让一行偷懒的代码，成了整个项目的阿喀琉斯之踵。