为何大厂内部都禁用了这个JavaScript特性？

别再随手用eval了：大厂把它列入黑名单的真相，你的项目可能因此慢十倍、被注入、还难排查

前几天我朋友小李半夜发来消息，说他的产品突然被人篡改了页面广告位，排查了好久才发现罪魁祸首是一处用eval拼接的模板字符串。说实话，当时我也以为那只是懒人写法，没想到早已成了打开后门的万能钥匙。别小看一行代码，它真能悄悄把你的用户数据、性能和心情一起拖垮。

eval到底干了什么？它能把普通字符串当作JavaScript代码来执行，所以表面上看很方便，能动态计算、拼装逻辑、加载配置。但是它的“可执行字符串”特性就是双刃剑。用户能控制的字符串一旦被执行，就等于把执行权交给了外部世界，任何恶意拼接都可能变成活生生的注入代码，后果不是报错那么简单，而是权限被窃取或页面被劫持。

更严重的是性能问题，ChromeV8团队的内部测试显示，含有eval的函数在执行效率上可能慢至少十倍。缘由很直观：现代JavaScript引擎依赖静态分析和JIT优化来提高速度，但动态执行的代码破坏了这些假设，使得内联缓存、函数内联等优化失效，从而触发去优化（deopt），整个调用路径被拖慢。换句话说，eval不仅影响被调用的那一小段逻辑，它会污染引擎给你的全部性能红利。

另外，eval在当前作用域内运行，还会意外覆写变量。这种问题的可怕之处不在于错误本身，而在于错误的隐蔽性。你可能在某个模块里临时用eval做了一个动态计算，结果在其他模块重用同名变量时出现莫名其妙的行为，只在特定输入下才触发。这种类型的bug往往让团队熬夜几个版本去回滚修改，最后才发现根源是那句“方便”的eval。

大厂并非说说而已。Google的JavaScript风格指南明确表明不要使用eval，由于它使代码容易受到注入攻击并阻碍引擎优化；微软的安全编码准则也提议禁止使用eval和Function构造函数，除非经过严格审查。许多公司采取的做法，是在代码评审和Lint规则里直接把它列为不合格项，把风险在源头切断。你可以理解为这既是安全策略，也是工程效率的自我保护。

那能不能彻底摒弃这种“动态执行”的需求？大多数情况下是有替代方案的。对于解析数据，使用JSON.parse替代执行字符串是最直接的解法；对于需要动态访问属性，往往可以用对象映射或查表的方式替代字符串拼接；如果是要运行简单表达式，设计一个小型解析器或者采用安全的表达式库来评估会比直接执行字符串安全得多。说起来容易做起来难，实际迁移时可以先用静态分析工具把所有eval、newFunction以及带字符串参数的setTimeout、setInterval找出来，然后逐条评估场景，编写单元测试保证行为不变，再逐步替换并回测性能。

我同事张姐有一段真实经历。她负责的一块统计逻辑里最初用eval来处理用户自定义的计算规则，上线后性能波动大还频繁触发错误报警。她花了一个迭代重构成查表加小型表达式解析器，最后不仅稳定了，CPU占用也下降明显。反过来，我邻居公司由于某个第三方脚本里使用eval，结果被人注入广告链接，修复成本远高于当初避免使用的代价。这种正反对比告知我，短期的便利往往会在长期里以巨大的维护成本反噬回来。

实操上有几条容易落地的提议可以参考：先用ESLint之类的静态规则把危险用法标出来，把项目里的eval和Function构造器聚焦列成清单，再按优先级替换那些与外部输入相关的用法；对于的确 需要运行某种“表达式”的场景，优先思考把表达需求转成数据和规则，通过受控的解析器执行；最后，任何替换都要伴随足够的单元测试和性能基准，避免“去掉eval”反而引入更多隐蔽bug。说白了，这更像工程治理而不是简单的语法换填。

我不是要把eval妖魔化为一无是处，有极少数经过严格审计并且运行在完全受控环境中的场景，才可能合理使用它。但那种情况对团队的要求超级高：审计日志、输入白名单、最小权限运行和回滚计划缺一不可。对于绝大多数产品团队，按大厂的经验教训来做，避而远之是更稳妥的选择。

你有没有遇到过由于eval或者类似“动态执行”的写法而出问题的经历？说说你的场景和当时是怎么解决的，或者目前还在为替换痛苦挣扎的，来聊聊你的想法吧。

来源：Google JavaScript 风格指南；微软 安全编码准则；Chrome V8团队内部测试