常见的JavaScript日常问题

在众多的编程语言中， JavaScript 给大部分的人的第一印象是人畜无害，看起来就简单的，对稍微有点儿开发经验的人来说，在网页中写个JavaScript功能也相当简单。但是当你真的得了解了JavaScript之后就会发现，它比我们想象中强大复杂的多。

也是因为 JavaScript 的复杂和细致让他很容易就出问题。我们就今天就准备讨论一下，在前端开发中的10个常见的问题。

时至今日JavaScript 几乎成为了所有现代 Web 应用的核心。而把JavaScript研究明白，找到JavaScript出问题的原因也就成了一名合格前端的首要任务。

基于 JavaScript 的强大库和框架，用于单页应用程序（SPA）开发、图形和动画、以及服务器端 JavaScript 平台，这些并不是什么新鲜事儿。JavaScript 已经成为 Web 应用程序开发领域中无处不在的语言，因此掌握 JavaScript 成为了一个日益重要的技能。

一、不正确的引用this

随着JavaScript的日益发展，编码技术和设计模式越来越复杂，回调和闭包中的自引用作用域也相应增加。在我们日常开发中一定的会遇到"this/that 混乱 "的问题。

考虑下面代码：

Game.prototype.restart = function () {    this.clearLocalStorage();    this.timer = setTimeout(function() {    this.clearBoard();    // What is "this"?    }, 0);};

执行上述代码会出现以下错误:

Uncaught TypeError: undefined is not a function

上述错误的原因是，当调用 setTimeout()时，实际上是在调用 window.setTimeout()。因此，传递给setTimeout()的匿名函数是在window对象的上下文中定义的，它没有clearBoard()方法。

传统的、符合老式浏览器的解决方案是将 this 引用保存在一个变量中，然后可以被闭包继承，如下所示：​​​​​​​

Game.prototype.restart = function () {    this.clearLocalStorage();    var self = this;   // Save reference to 'this', while it's still this!    this.timer = setTimeout(function(){    self.clearBoard();    // Oh OK, I do know who 'self' is!    }, 0);};

另外，在较新的浏览器中，可以使用bind()方法来传入适当的引用：

​​​​​​​

Game.prototype.restart = function () {    this.clearLocalStorage();    this.timer = setTimeout(this.reset.bind(this), 0);  // Bind to 'this'};
Game.prototype.reset = function(){    this.clearBoard();    // Ahhh, back in the context of the right 'this'!};

二：认为存在块级作用域

JavaScript开发者中常见的混乱来源（也是常见的错误来源）是假设JavaScript为每个代码块创建一个新的作用域。尽管这在许多其他语言中是对的，但在JavaScript中却不是。

考虑一下下面的代码：

​​​​​​​

for (var i = 0; i < 10; i++) {    /* ... */}console.log(i);  // 输出什么？

如果你猜测console.log()的调用会输出 undefined 或者抛出一个错误，那你就猜错了。答案是输出10。为什么呢？

在大多数其他语言中，上面的代码会导致一个错误，因为变量i的 "生命"（即使作用域）会被限制在for块中。但在JavaScript中，情况并非如此，即使在for循环完成后，变量i仍然在作用域内，在退出循环后仍保留其最后的值。(顺便说一下，这种行为被称为变量提升（variable hoisting）。

JavaScript中对块级作用域的支持是通过let关键字实现的。Let关键字已经被浏览器和Node.js等后端JavaScript引擎广泛支持了多年。

三：创建内存泄漏

如果没有有意识地编写代码来避免内存泄漏，那么内存泄漏几乎是不可避免的JavaScript问题。它们的发生方式有很多种，所以我们只重点介绍几种比较常见的情况。

内存泄漏实例:对不存在的对象的悬空引用

考虑以下代码:

​​​​​​​

var theThing = null;var replaceThing = function () {  var priorThing = theThing;   var unused = function () {     // 'unused'是'priorThing'被引用的唯一地方。    // 但'unused'从未被调用过    if (priorThing) {      console.log("hi");    }  };  theThing = {    longStr: new Array(1000000).join('*'),  // 创建一个1MB的对象    someMethod: function () {      console.log(someMessage);    }  };};setInterval(replaceThing, 1000);    // 每秒钟调用一次 "replaceThing"。

如果你运行上述代码并监测内存使用情况，你会发现你有一个明显的内存泄漏，每秒泄漏整整一兆字节！而即使是手动垃圾收集器（GC）也无济于事。因此，看起来我们每次调用 replaceThing 都会泄漏 longStr。但是为什么呢？

每个theThing对象包含它自己的1MB longStr对象。每一秒钟，当我们调用 replaceThing 时，它都会在 priorThing 中保持对先前 theThing 对象的引用。

但是我们仍然认为这不会是一个问题，因为每次通过，先前引用的priorThing将被取消引用（当priorThing通过priorThing = theThing;被重置时）。而且，只在 replaceThing 的主体和unused的函数中被引用，而事实上，从未被使用。

因此，我们又一次想知道为什么这里会有内存泄漏。

为了理解发生了什么，我们需要更好地理解JavaScript的内部工作。实现闭包的典型方式是，每个函数对象都有一个链接到代表其词法作用域的字典式对象。如果在replaceThing里面定义的两个函数实际上都使用了priorThing，那么它们都得到了相同的对象就很重要，即使priorThing被反复赋值，所以两个函数都共享相同的词法环境。但是一旦一个变量被任何闭包使用，它就会在该作用域内所有闭包共享的词法环境中结束。而这个小小的细微差别正是导致这个可怕的内存泄露的原因。

避免内存泄漏:要点

JavaScript的内存管理（尤其是垃圾回收）主要是基于对象可达性的概念。

以下对象被认为是可达的，被称为 "根":

● 从当前调用堆栈的任何地方引用的对象（即当前被调用的函数中的所有局部变量和参数，以及闭包作用域内的所有变量）

● 所有全局变量

只要对象可以通过引用或引用链从任何一个根部访问，它们就会被保留在内存中。

浏览器中有一个垃圾收集器，它可以清理被无法到达的对象所占用的内存；换句话说，当且仅当GC认为对象无法到达时，才会将其从内存中删除。不幸的是，很容易出现不再使用的 "僵尸 "对象，但GC仍然认为它们是 "可达的"。

四：双等号的困惑

JavaScript 的一个便利之处在于，它会自动将布尔上下文中引用的任何值强制为布尔值。但在有些情况下，这可能会让人困惑，因为它很方便。例如，下面的一些情况对许多JavaScript开发者来说是很麻烦的。

​​​​​​​

// 下面结果都是 'true'console.log(false == '0');console.log(null == undefined);console.log(" \t\r\n" == 0);console.log('' == 0);
// 下面也都成立if ({}) // ...if ([]) // ...

关于最后两个，尽管是空的（大家可能会觉得他们是 false），{}和[]实际上都是对象，任何对象在JavaScript中都会被强制为布尔值 "true"，这与ECMA-262规范一致。

正如这些例子所表明的，类型强制的规则有时非常清楚。因此，除非明确需要类型强制，否则最好使用===和!==（而不是==和!=），以避免强制类型转换的带来非预期的副作用。(== 和 != 会自动进行类型转换，而 === 和 !== 则相反)

另外需要注意的是：将NaN与任何东西（甚至是NaN）进行比较时结果都是 false。因此，不能使用双等运算符（==, ==, !=, !==）来确定一个值是否是NaN。如果需要，可以使用内置的全局 isNaN()函数。

​​​​​​​

console.log(NaN == NaN);    // Falseconsole.log(NaN === NaN);   // Falseconsole.log(isNaN(NaN));    // True

五：低效的DOM操作

使用 JavaScript 操作DOM（即添加、修改和删除元素）是相对容易，但操作效率却不怎么样。

比如，每次添加一系列DOM元素。添加一个DOM元素是一个昂贵的操作。连续添加多个DOM元素的代码是低效的。

当需要添加多个DOM元素时，一个有效的替代方法是使用 document fragments来代替，从而提高效率和性能。

​​​​​​​

var div = document.getElementsByTagName("my_div");
var fragment = document.createDocumentFragment();
for (var e = 0; e < elems.length; e++) {  // elems previously set to list of elements    fragment.appendChild(elems[e]);}div.appendChild(fragment.cloneNode(true));

除了这种方法固有的效率提高外，创建附加的DOM元素是很昂贵的，而在分离的情况下创建和修改它们，然后再将它们附加上，就会产生更好的性能。

六：在循环内错误使用函数定义

考虑下面代码：

​​​​​​​

var elements = document.getElementsByTagName('input');var n = elements.length;    // Assume we have 10 elements for this examplefor (var i = 0; i < n; i++) {    elements[i].onclick = function() {        console.log("This is element #" + i);    };}

根据上面的代码，如果有10个 input 元素，点击任何一个都会显示 "This is element #10"。这是因为，当任何一个元素的onclick被调用时，上面的for循环已经结束，i的值已经是10了（对于所有的元素）。

我们可以像下面这样来解决这个问题：

​​​​​​​

var elements = document.getElementsByTagName('input');var n = elements.length;   var makeHandler = function(num) {      return function() {           console.log("This is element #" + num);     };};for (var i = 0; i < n; i++) {    elements[i].onclick = makeHandler(i+1);}

makeHandler 是一个外部函数，并返回一个内部函数，这样就会形成一个闭包，num 就会调用时传进来的的当时值，这样在点击元素时，就能显示正确的序号。

七：未能正确利用原型继承

考虑下面代码：

​​​​​​​

BaseObject = function(name) {    if (typeof name !== "undefined") {        this.name = name;    } else {        this.name = 'default'    }};

上面代码比较简单，就是提供了一个名字，就使用它，否则返回 default:

​​​​​​​

var firstObj = new BaseObject();var secondObj = new BaseObject('unique');
console.log(firstObj.name);  // -> 'default'console.log(secondObj.name); // -> 'unique'

但是，如果这么做呢:

delete secondObj.name;

会得到：

console.log(secondObj.name); // 'undefined'

当使用 delete 删除该属性时，就会返回一个 undefined，那么如果我们也想返回 default 要怎么做呢？利用原型继承，如下所示:​​​​​​​

BaseObject = function (name) {    if(typeof name !== "undefined") {        this.name = name;    }};
BaseObject.prototype.name = 'default';

BaseObject 从它的原型对象中继承了name 属性，值为 default。因此，如果构造函数在没有 name 的情况下被调用，name 将默认为 default。同样，如果 name 属性从BaseObject的一个实例中被移除，那么会找到原型链的 name，，其值仍然是default。所以​​​​​​​

var thirdObj = new BaseObject('unique');console.log(thirdObj.name);  // -> Results in 'unique'
delete thirdObj.name;console.log(thirdObj.name);  // -> Results in 'default'

八：为实例方法创建错误的引用

考虑下面代码：​​​​​​​

var MyObject = function() {}
MyObject.prototype.whoAmI = function() {    console.log(this === window ? "window" : "MyObj");};
var obj = new MyObject();

现在，为了操作方便，我们创建一个对whoAmI方法的引用，这样通过whoAmI()而不是更长的obj.whoAmI()来调用。

var whoAmI = obj.whoAmI;

为了确保没有问题，我们把 whoAmI 打印出来看一下：

console.log(whoAmI);

为了确保没有问题，我们把 whoAmI 打印出来看一下：

console.log(whoAmI);

输出：

​​​​​​​

function () {    console.log(this === window ? "window" : "MyObj");}

看起来没啥问题。

接着，看看当我们调用obj.whoAmI() 和 whoAmI() 的区别。

​​​​​​​

obj.whoAmI();  // Outputs "MyObj" (as expected)whoAmI();      // Outputs "window" (uh-oh!)

什么地方出错了？当我们进行赋值时 var whoAmI = obj.whoAmI,新的变量whoAmI被定义在全局命名空间。结果，this的值是 window，而不是 MyObject 的 obj 实例!

因此，如果我们真的需要为一个对象的现有方法创建一个引用，我们需要确保在该对象的名字空间内进行，以保留 this值。一种方法是这样做:

​​​​​​​

var MyObject = function() {}
MyObject.prototype.whoAmI = function() {    console.log(this === window ? "window" : "MyObj");};
var obj = new MyObject();obj.w = obj.whoAmI;   // Still in the obj namespace
obj.whoAmI();  // Outputs "MyObj" (as expected)obj.w();       // Outputs "MyObj" (as expected)

九：为 setTimeout 或 setInterval 提供一个字符串作为第一个参数

首先，需要知道的是为 setTimeout 或 setInterval 提供一个字符串作为第一个参数，这本身并不是一个错误。它是完全合法的JavaScript代码。这里的问题更多的是性能和效率的问题。很少有人解释的是，如果你把字符串作为setTimeout或setInterval的第一个参数，它将被传递给函数构造器，被转换成一个新函数。这个过程可能很慢，效率也很低，而且很少有必要。

将一个字符串作为这些方法的第一个参数的替代方法是传入一个函数​​​​​​​

setInterval("logTime()", 1000);setTimeout("logMessage('" + msgValue + "')", 1000);

更好的选择是传入一个函数作为初始参数:

​​​​​​​​​​​​​​

setInterval(logTime, 1000); 
setTimeout(function() {          logMessage(msgValue);     }, 1000);

十：未使用 "严格模式"

"严格模式"（即在JavaScript源文件的开头包括 "use strict"；）是一种自愿在运行时对JavaScript代码执行更严格的解析和错误处理的方式，同时也使它更安全。

但是，不使用严格模式本身并不是一个 "错误"，但它的使用越来越受到鼓励，不使用也越来越被认为是不好的形式。

以下是严格模式的一些主要好处：

● 使得调试更容易。原本会被忽略或无感知的代码错误，现在会产生错误或抛出异常，提醒我们更快地发现代码库中的JavaScript问题，并引导更快地找到其来源。

● 防止意外的全局变量。在没有严格模式的情况下，给一个未声明的变量赋值会自动创建一个具有该名称的全局变量。这是最常见的JavaScript错误之一。在严格模式下，试图这样做会产生一个错误。

● 消除this 强迫性。在没有严格模式的情况下，对 null 或 undefined 的 this 值的引用会自动被强制到全局。在严格模式下，引用null或undefined的this值会产生错误。

● 不允许重复的属性名或参数值。严格模式在检测到一个对象中的重复命名的属性（例如，var object = {foo: "bar", foo: "baz"};）或一个函数的重复命名的参数（例如，function foo(val1, val2, val1){}）时抛出一个错误，从而捕捉到你的代码中几乎肯定是一个错误，否则你可能会浪费很多时间去追踪。

● 使得eval()更加安全。eval()在严格模式和非严格模式下的行为方式有一些不同。最重要的是，在严格模式下，在eval()语句中声明的变量和函数不会在包含的范围内创建。(在非严格模式下，它们是在包含域中创建的，这也可能是JavaScript问题的一个常见来源)。

● 在无效使用delete的情况下抛出错误。delete 操作符（用于从对象中删除属性）不能用于对象的非可配置属性。当试图删除一个不可配置的属性时，非严格的代码将无声地失败，而严格模式在这种情况下将抛出一个错误。

代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具。