未使用 “严格模式“（js的问题）

"严格模式"（即在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监控工具 Fundebug。

来源：www.toptal.com/javascript/…