摘要：五总结和应对方案安全性分析是否安全主要由数据源决定，如果数据源不安全，只是提供了一种攻击方法而已。方案严格管控数据源。方案低频使用时影响不大，不要高频使用，建议寻找替代方案。方案了解直接调用和间接调用的区别，遇到问题时不要懵逼即可。
为什么要少用eval?
eval是 js 中一个强大的方法。都说eval == evil等于true，这篇文章将研讨eval的几个缺点和使用注意事项。
目录一、安全性
二、运行效率
三、作用域
四、内存▲
五、总结和应对方案
一、安全性太明显了，暂不讨论
二、运行效率都知道 eval 比较慢，到底慢多少，自己测测看，下面是代码（对比运行 1万次 eval("sum++") 和 500万次 sum++ 所需要的时间）
var getTime = function(){
// return Date.now();
return new Date().getTime() //兼容ie8
}
var sum;
// 测试 1万次 eval("sum++")
sum = 0;
var startEval = getTime();
for(var i = 0;i<10000;i++){
eval("sum++");
}
var durEval = getTime() - startEval;
console.log("durEval = ",durEval,"ms");
// 测试 500万次 sum++
sum = 0;
var startCode = getTime();
for(var i = 0;i<5000000;i++){
sum++;
}
var durCode = getTime() - startCode;
console.log("durCode = ",durCode,"ms");
//输出结果
console.log("直接运行 sum++ 的速度约是 运行 eval("sum++") 的",(durEval * 500 / durCode).toFixed(0),"倍");
测试结果
在同一台PC上，测试3款浏览器和nodejs环境，结果如下：
Chrome 73
durEval = 236 ms
durCode = 14 ms
直接运行 sum++ 的速度约是 运行 eval("sum++") 的 8429 倍
Firefox 65
durEval = 766 ms
durCode = 167 ms
直接运行 sum++ 的速度约是 运行 eval("sum++") 的 2293 倍
IE8
durEval = 417ms
durCode = 572ms
直接运行 sum++ 的速度约是 运行 eval("sum++") 的365倍
Nodejs 10.15.0
durEval = 5 ms
durCode = 14 ms
直接运行 sum++ 的速度约是 运行 eval("sum++") 的 179 倍
Chrome 的 V8 果然是王者，Firefox 在运行eval的PK上输给了古董IE8，node环境中eval的表现最好（只慢100多倍）
三、作用域在作用域方面，eval 的表现让人费解。直接调用时：当前作用域；间接调用时：全局作用域。
3.1 直接调用eval被直接调用并且调用函数就是eval本身时，作用域为当前作用域，function中的foo被修改了，全局的foo没被修改。
var foo = 1;
function test() {
var foo = 2;
eval("foo = 3");
return foo;
}
console.log(test()); // 3
console.log(foo); // 1
3.2间接调用
间接调用eval时 执行的作用域为全局作用域，两个function中的foo都没有被修改，全局的foo被修改了。
var foo = 1;
(function(){
var foo = 1;
function test() {
var foo = 2;
var bar = eval;
bar("foo = 3");
return foo;
}
console.log(test()); // 2
console.log(foo); // 1
})();
console.log(foo); // 3
四、内存 ▲
使用eval会导致内存的浪费，这是本文要讨论的重点。
下面用测试结果来对比，使用eval 和 不使用eval 的情况下，以下代码内存的消耗情况。
var f1 = function(){ // 创建一个f1方法
var data = {
name:"data",
data: (new Array(50000)).fill("data 111 data")
}; // 创建一个不会被使用到的变量
var f = function(){ // 创建f方法然后返回
console.log("code:hello world");
};
return f;
};
var F1 = f1();
测试结果
在Chrome上查看内存使用情况，开发者工具->Momery->Profiles->Take snapshot，给内存拍个快照。
为了便于查找，在过滤器中输入window，查看当前域的window：
可以看到，window占用了68612，2%的内存。然后在其中找F1变量：
F1占用了32，0%的内存。
这似乎说明不了什么。没有对比就没有伤害，下面我们来伤害一下eval。
4.2 使用eval的情况修改上面的代码，把 console.log 修改为 eval 运行：
- console.log("code:hello world");
+ eval("console.log("eval:hello world");");
测试结果
方法同上。在Chrome上查看内存使用情况，开发者工具->Momery->Profiles->Take snapshot。
window占用了251048，4%的内存，其中F1占用了200140，相当于总量的3%的内存，F1.context.data，占用了200044，约等于F1的占用量，可见这些额外的内存开销都是来自于F1.context.data。
4.3 分析使用eval时：F1占用了200140，3%的内存；
不用eval时：F1占用了32，0%的内存；
这样的差别来自于javascript引擎的优化。在方法f1运行时创建了data，接着创建了一个方法f，f中可以访问到data，但它没有使用data，然后f被返回赋值给变量F1，经过javascript引擎优化，这时data不会被加入到闭包中，同时也没有其他指针指向data，data的内存就会被回收。然而在f中使用了eval后，情况就不同了，eval太过强大，导致javascript引擎无法分辨f会不会使用到data，从而只能将全部的环境变量（包括data），一起加入到闭包中，这样F1就间接引用了data，data的内存就不会被回收。从而导致了额外的内存开销。
我们可以进一步测试，这时在开发者工具->Console 中输入：
F1 = "Hello" //重设F1,这样就没什么引用到data了
然后用同样的方法查看内存，可以发现 window占用的内存，从200000+下降到了60000+。
说到这里，再回头看eval奇怪的作用域。直接调用时：当前作用域；间接调用时：全局作用域，也就可以理解了。当间接调用时，javascript引擎不知道它是eval，优化时就会移除不需要的变量，如果eval中用到了那些变量，就会发生意想不到的事情。这违背了闭包的原则，变得难以理解。索性把间接调用的作用域设置为了全局。
五、总结和应对方案 安全性分析：eval是否安全主要由数据源决定，如果数据源不安全，eval只是提供了一种攻击方法而已。
方案：严格管控数据源。
分析：eval比直接运行慢很多倍，但主要的消耗在于编译代码过程，简单项目中，不会这样高频率的运行eval。
方案：低频使用时影响不大，不要高频使用，建议寻找替代方案。
分析：实际项目中直接调用都很少，间接调用更是少之又少。
方案：了解直接调用和间接调用的区别，遇到问题时不要懵逼即可。
分析：实际应用中很常见，却很少有人会注意到内存管理，大项目中被重复使用会浪费较多的内存。
方案：优化编码规范，使用eval时注意那些没有被用到局部变量。
源码链接：github
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/103428.html
摘要：当中的是一个用于指向当前上下文对象的关键字。创建实例时的构造函数中的，永远指向那个实例后对象，不是外部环境使用来调用函数时，先改变其上下文环境，在对其构造函数进行调用。 javascript 当中的 this是一个用于指向当前上下文对象的关键字。在面向对象编程及日常开发当中我们经常与其打交道，初学javscript的朋友非常容易误入歧途从而理解错误。 上下文对象概念 在我的深入贯彻闭包...
摘要：每个专业的开发者都知道用户上传的文件都是极其危险的。如何防止引入用户上传的文件重命名文件名可以吗不，办不到解析器不关心文件的后缀名。服务器通常被设置成执行文件并将执行结果回复输出。如何进行检查这很简单。用户可以上传文件到该站点。 showImg(https://segmentfault.com/img/remote/1460000017893665?w=1200&h=627); 每个专...
摘要：写在前面对于一个前端开发者，应该没有不知道作用域的。欺骗词法作用域有两个机制可以欺骗词法作用域和。关于你不知道的的第一部分作用域和闭包已经结束了，但是，更新不会就此止住未完待续 这是《你不知道的JavaScript》的第一部分。 本系列持续更新中，Github 地址请查阅这里。 写在前面 对于一个前端开发者，应该没有不知道作用域的。它是一个既简单有复杂的概念，简单到每行代码都有它的影子...
摘要：词法作用域定义在词法阶段的作用域由你在写代码时将变量和块作用域写在哪来决定的，因此当词法分析器处理代码时会保持作用域不变。欺骗词法作用域在词法分析器处理过后依然可以修改作用域。 你不知道的JS(上卷)笔记 你不知道的 JavaScript JavaScript 既是一门充满吸引力、简单易用的语言，又是一门具有许多复杂微妙技术的语言，即使是经验丰富的 JavaScript 开发者，如果没...
摘要：作用域有两种主要工作模型词法作用域和动态作用域。可能会有一些同学认为是，那就是没有搞清楚词法作用域的概念。在严格模式下，在运行时有自己的词法作用域，意味着其中的声明无法修改所在的作用域。 1. 两种作用域 作用域我们知道是一套规则，用来管理引擎如何在当前作用域以及嵌套的子作用域中根据标识符名称进行变量查找。 作用域有两种主要工作模型：词法作用域和动态作用域。 大多数语言采用的都是词法作...
阅读 2269·2021-11-17 09:33
阅读 825·2021-10-13 09:40
阅读 547·2019-08-30 15:54
阅读 757·2019-08-29 15:38
阅读 2396·2019-08-28 18:15
阅读 2461·2019-08-26 13:38
阅读 1815·2019-08-26 13:36
阅读 2109·2019-08-26 11:36
