在JavaScript中验证电子邮件地址通常涉及到检查该地址是否符合电子邮件地址的标准格式。这通常通过使用正则表达式（Regular Expressions）来完成，正则表达式是一种强大的模式匹配工具，可以用来检测字符串是否符合特定的格式。

以下是一个使用正则表达式来验证电子邮件地址的例子：

```javascript
function validateEmail(email) {
    var emailRegex = /^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,6}$/;
    return emailRegex.test(email);
}

// 使用示例
var email = "example@example.com";
if (validateEmail(email)) {
    console.log(email + " 是一个有效的电子邮件地址。");
} else {
    console.log(email + " 不是一个有效的电子邮件地址。");
}
```

这里的正则表达式解释如下：

1. `^` ：表示匹配字符串的开始。
2. `[a-zA-Z0-9._-]`：表示可以包含小写字母a-z、大写字母A-Z、数字0-9以及点号、下划线和破折号。
3. `+`：表示前面的字符或子表达式至少出现一次。
4. `@`：字面量@字符，电子邮件地址的一部分。
5. `[a-zA-Z0-9.-]`：表示域名部分可以包含小写字母a-z、大写字母A-Z、数字0-9以及点号和破折号。
6. `\.`：转义后的点号，表示域名的部分。
7. `[a-zA-Z]{2,6}`：表示顶级域名（TLD），可以是两到六个字母长。
8. `$`：表示匹配字符串的结尾。

这个正则表达式仅是一个基础版本，用于匹配大部分电子邮件地址的格式。然而，电子邮件地址的规范（例如RFC 5322）要复杂得多，包含许多特殊的规则和例外，这意味着创建一个完全符合规范的正则表达式非常复杂并且会很长。因此，上述正则表达式在实际应用中可能会因为太过简化而排除一些有效的电子邮件地址，或者可能会接受一些不合规范的电子邮件地址。

此外，即使一个电子邮件地址的格式正确，也无法保证该电子邮件地址是存在的或者可以接收邮件。要验证电子邮件地址是否真正有效，您可能还需要发送一封确认邮件并要求用户点击其中的链接以验证他们的地址。

为了提高用户体验，现代web应用程序通常会在前端使用类似的正则表达式来做初步验证，然后再在后端进行进一步的检查，也可能包括发送确认邮件来验证电子邮件地址的真实性。

使用[正则表达式](http://en.wikipedia.org/wiki/Regular_expression)可能是在 JavaScript 中验证电子邮件地址的最佳方法。查看来自[Chromium](https://cs.chromium.org/chromium/src/third_party/blink/web_tests/fast/forms/resources/ValidityState-typeMismatch-email.js?q=ValidityState-typeMismatch-email.js&sq=package:chromium&dr)[的 JSFiddle 测试](http://jsfiddle.net/ghvj4gy9/embedded/result.js)。[](https://cs.chromium.org/chromium/src/third_party/blink/web_tests/fast/forms/resources/ValidityState-typeMismatch-email.js?q=ValidityState-typeMismatch-email.js&sq=package:chromium&dr)

```
const validateEmail = (email) => {
 return String(email)
 .toLowerCase()
 .match(
 /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|.(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/
 );
};
```

以下是接受 unicode 的正则表达式示例。

```
const re =
 /^(([^<>()[\]\.,;:\s@\"]+(\.[^<>()[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i;
```

请记住，不应单独依赖 JavaScript 验证，因为 JavaScript 很容易被客户端禁用。此外，在服务器端进行验证也很重要。 

以下代码片段是在客户端验证电子邮件地址的 JavaScript 示例。

```
const validateEmail = (email) => {
 return email.match(
 /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/
 );
};

const validate = () => {
 const $result = $('#result');
 const email = $('#email').val();
 $result.text('');

 if(validateEmail(email)){
 $result.text(email + ' is valid.');
 $result.css('color', 'green');
 } else{
 $result.text(email + ' is invalid.');
 $result.css('color', 'red');
 }
 return false;
}

$('#email').on('input', validate);

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<label for="email">Enter email address</label>
<input id="email" type="email">


```


展开片段

I've slightly modified [Jaymon's answer](https://stackoverflow.com/a/48800/4832311) for people who want really simple validation in the form of:

    anystring@anystring.anystring
    

The regular expression:

    /^\S+@\S+\.\S+$/
    

To prevent matching multiple @ signs:

    /^[^\s@]+@[^\s@]+\.[^\s@]+$/
    

The above regexes match the whole string, remove the leading and `^` and trailing `$` if you want to match anywhere in the string. The example below matches _anywhere_ in the string.

If you do want to match the whole sring, you may want to `trim()` the string first.

Example JavaScript function:

    function validateEmail(email) {
      var re = /\S+@\S+\.\S+/;
      return re.test(email);
    }
        
    console.log(validateEmail('my email is anystring@anystring.any')); // true
        
    console.log(validateEmail('my email is anystring@anystring .any')); // false

Run code snippetHide results

Expand snippet

Just for completeness, [here you have another RFC 2822 compliant regex](http://www.regular-expressions.info/email.html)

> The official standard is known as [RFC 2822](https://www.rfc-editor.org/rfc/rfc2822#section-3.4.1). It describes the syntax that valid email addresses must adhere to. You can (**but you shouldn't** — [read on](http://www.regular-expressions.info/email.html)) implement it with this regular expression:
> 
> ``(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])``
> 
> (...) We get a more practical implementation of RFC 2822 if we omit the syntax using double quotes and square brackets. **It will still match 99.99% of all email addresses in actual use today.**
> 
> ``[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?``
> 
> A further change you could make is to allow any two-letter country code top level domain, and only specific generic top level domains. **This regex filters dummy email addresses like `asdf@adsf.adsf`**. You **will need to update it as new top-level domains are added**.
> 
> ``[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum)\b``
> 
> So even when following official standards, there are still trade-offs to be made. _**Don't blindly copy regular expressions from online libraries or discussion forums. Always test them on your own data and with your own applications.**_

Emphasis mine

Wow, there are lots of complexity here. If all you want to do is just catch the most obvious syntax errors, I would do something like this:

    ^\S+@\S+$
    

It usually catches the most obvious errors that the user makes and assures that the form is mostly right, which is what JavaScript validation is all about.

EDIT: We can also check for '.' in the email using

    /^\S+@\S+\.\S+$/

There's something you have to understand the second you decide to use a regular expression to validate emails: [It's probably not a good idea](http://ex-parrot.com/~pdw/Mail-RFC822-Address.html). Once you have come to terms with that, there are many implementations out there that can get you halfway there, [this article sums them up nicely.](http://www.regular-expressions.info/email.html)

In short, however, the only way to be absolutely, positively sure that what the user entered is in fact an email is to actually send an email and see what happens. Other than that it's all just guesses.

JS 如何验证电子邮件地址

在JavaScript中，将字符串的第一个字母变为大写通常有多种方式，以下是两种常见的方法：

### 方法1：使用字符串的 `charAt()` 和 `slice()` 方法

```javascript
function capitalizeFirstLetter(string) {
    // 如果字符串为空，则直接返回
    if(!string) return string;

    // 使用 charAt(0) 获取第一个字符，并将其转换为大写
    // 然后使用 slice(1) 获取第一个字符之后的所有字符
    // 最后将两部分组合起来
    return string.charAt(0).toUpperCase() + string.slice(1);
}

// 示例
const exampleString = "hello";
console.log(capitalizeFirstLetter(exampleString)); // 输出: "Hello"
```

### 方法2：使用正则表达式和 `replace()` 方法

```javascript
function capitalizeFirstLetter(string) {
    // 如果字符串为空，则直接返回
    if(!string) return string;

    // 使用正则表达式匹配字符串的第一个字母，并使用 replace() 替换它
    // 函数replace的第二个参数是一个函数，它的返回值将替换掉匹配到的内容
    return string.replace(/^\w/, c => c.toUpperCase());
}

// 示例
const exampleString = "hello";
console.log(capitalizeFirstLetter(exampleString)); // 输出: "Hello"
```

这两个函数都可以达到我们想要的效果，即将输入字符串的第一个字母转换为大写。您可以根据实际需求和代码风格选择适合的方法。

function capitalizeFirstLetter(string) {
        return string.charAt(0).toUpperCase() + string.slice(1);
    }
    

其他一些答案会修改`String.prototype`（这个答案也曾经如此），但由于可维护性，我现在建议不要这样做（很难找出该函数被添加到的位置，`prototype`并且如果其他代码使用相同的名称/浏览器，可能会导致冲突）将来添加具有相同名称的本机函数）。

一种面向对象的方法：

```
Object.defineProperty(String.prototype, 'capitalize', {
  value: function() {
    return this.charAt(0).toUpperCase() + this.slice(1);
  },
  enumerable: false
});
```

调用函数的方式如下：

```
"hello, world!".capitalize();
```

预期输出为：

```
"Hello, world!"
```

CSS 处理方式如下：

```
 p::first-letter {
    text-transform:capitalize;
}
```

Here is a shortened version of the popular answer that gets the first letter by treating the string as an array:

    function capitalize(s)
    {
        return s[0].toUpperCase() + s.slice(1);
    }
    

Update
------

According to the comments below this doesn't work in IE 7 or below.

Update 2:
---------

To avoid `undefined` for empty strings (see [@njzk2's comment below](https://stackoverflow.com/questions/1026069/capitalize-the-first-letter-of-string-in-javascript/7224605?noredirect=1#comment40995528_7224605)), you can check for an empty string:

    function capitalize(s)
    {
        return s && s[0].toUpperCase() + s.slice(1);
    }
    

### ES6 version

    const capitalize = s => s && s[0].toUpperCase() + s.slice(1)
    
    // to always return type string event when s may be falsy other than empty-string
    const capitalize = s => (s && s[0].toUpperCase() + s.slice(1)) || ""

### If you're interested in the performance of a few different methods posted:

Here are the fastest methods based on [this jsperf test](http://jsperf.com/capitalize-the-first-letter-of-string-in-javascript/2) (ordered from fastest to slowest).

As you can see, the first two methods are essentially comparable in terms of performance, whereas altering the `String.prototype` is by far the slowest in terms of performance.

    // 10,889,187 operations/sec
    function capitalizeFirstLetter(string) {
        return string[0].toUpperCase() + string.slice(1);
    }
    
    // 10,875,535 operations/sec
    function capitalizeFirstLetter(string) {
        return string.charAt(0).toUpperCase() + string.slice(1);
    }
    
    // 4,632,536 operations/sec
    function capitalizeFirstLetter(string) {
        return string.replace(/^./, string[0].toUpperCase());
    }
    
    // 1,977,828 operations/sec
    String.prototype.capitalizeFirstLetter = function() {
        return this.charAt(0).toUpperCase() + this.slice(1);
    }
    

[![enter image description here](https://i.stack.imgur.com/tNwKk.png)](https://i.stack.imgur.com/tNwKk.png)

**Edited to add this DISCLAIMER**: please read the comments to understand the risks of editing JS basic types.

* * *

Here's a more object-oriented approach:

    Object.defineProperty(String.prototype, 'capitalize', {
      value: function() {
        return this.charAt(0).toUpperCase() + this.slice(1);
      },
      enumerable: false
    });
    

You'd call the function, like this:

    "hello, world!".capitalize();
    

With the expected output being:

    "Hello, world!"

In CSS:

    p::first-letter {
        text-transform:capitalize;
    }

在 JavaScript 中，您可以使用以下方法将字符串的第一个字母变为大写：

```javascript
function capitalizeFirstLetter(string) {
    return string.charAt(0).toUpperCase() + string.slice(1);
}

const myString = "hello world";
const capitalized = capitalizeFirstLetter(myString);

console.log(capitalized); // 输出: Hello world
```

这个 `capitalizeFirstLetter` 函数通过以下步骤工作：

1. `string.charAt(0).toUpperCase()` 获取字符串的第一个字符并将其转换为大写字母。
2. `string.slice(1)` 获取除了第一个字符之外的所有字符，即从索引 1 开始到字符串的末尾。
3. 然后使用 `+` 操作符将得到的大写字母和剩余部分拼接在一起，形成新的字符串。

JS 如何使字符串的第一个字母变成大写？

# 在 JavaScript 中应该使用哪个等于运算符（== 与 ===）来做比较操作？

在 JavaScript 的世界里，比较运算符是我们日常编码中不可或缺的一部分。它们帮助我们理解和判断不同变量或表达式的值是否相等。当我们提到相等比较时，有两个非常相似但又截然不同的运算符：`==`（相等运算符）和 `===`（严格相等运算符）。了解它们的区别，对于写出可靠和高效的代码至关重要。

## `==` 相等运算符：类型强制转换的魔术师

`==` 运算符在 JavaScript 中被称为“宽松相等”或者“非严格相等”。当使用 `==` 比较两个值时，如果它们不是同一类型，JavaScript 会尝试类型转换，将它们转换成相同的类型后再做比较。这种类型转换通常被称为“类型强制转换”。

### 举个栗子 🌰

```javascript
0 == '0'; // true，因为字符串 '0' 被强制转换成了数字 0
'1' == 1; // true，同上
null == undefined; // true，null 和 undefined 在非严格相等的情况下被认为是相等的
```

`==` 运算符的这种行为可能会引起一些意想不到的结果，有时会导致难以发现的 bug。因此，它经常被认为是 JavaScript 中一种不那么可靠的比较方式。

## `===` 严格相等运算符：精确无误的严格管家

与 `==` 运算符不同，`===` 运算符在比较时不会进行类型转换。如果两个值的类型不同，它们就被认为是不相等的。因此，`===` 被称为“严格相等”运算符。

### 再举个栗子 🌰

```javascript
0 === '0'; // false，因为它们类型不同：一个是数字，一个是字符串
'1' === 1; // false，同上
null === undefined; // false，null 和 undefined 类型不同
```

使用 `===` 运算符可以让你的代码逻辑更加清晰、可预测，并且减少隐藏 bug 的风险。

## 那么，我们应该怎么选择？

在大多数情况下，推荐使用 `===` 严格相等运算符，因为它提供了类型安全的比较，能减少许多不必要的问题。当你明确需要进行类型转换时，才考虑使用 `==`。

### 最佳实践

假设你在处理一个 web 表单，用户输入的是数字字符串，而你需要将其与数字类型的值进行比较。

```javascript
const userInput = '123';
const targetValue = 123;

// 使用 ==，因为我们明确知道两边的值应该是相同的，即使类型不同
if (userInput == targetValue) {
    console.log('用户输入匹配！');
}
```

在这种情况下，你可能会选择使用 `==`，因为它简化了代码。然而，为了保持更好的代码质量和可维护性，你应该考虑显式地转换类型，然后使用 `===` 进行比较。

```javascript
const userInput = '123';
const targetValue = 123;

// 显式转换类型，然后使用 === 进行比较
if (Number(userInput) === targetValue) {
    console.log('用户输入匹配！');

严格相等运算符 ( `===`) 的行为与抽象相等运算符 ( `==`) 相同，只是不进行类型转换，并且类型必须相同才能被视为相等。

参考：[JavaScript 教程：比较运算符](https://www.c-point.com/javascript_tutorial/jsgrpComparison.htm)

_在进行任何必要的类型转换后，_该`==`运算符将比较是否相等。该运算符不会**进行**转换，因此如果两个值不同，类型将简单地返回。两者都同样快。`===``===``false`

引用 Douglas Crockford 的优秀[JavaScript: The Good Parts](https://rads.stackoverflow.com/amzn/click/com/0596517742)，

> JavaScript 有两组相等运算符：`===`and `!==`，以及它们的邪恶双胞胎`==`and `!=`。好的产品会按照您期望的方式工作。如果两个操作数类型相同且值相同，则`===`生成`true`并`!==`生成`false`。当操作数具有相同类型时，邪恶双胞胎会做正确的事情，但如果它们具有不同类型，它们会尝试强制这些值。他们这样做的规则既复杂又难以记住。以下是一些有趣的案例：

>     '' == '0'           // false
>     0 == ''             // true
>     0 == '0'            // true
>     

>     false == 'false'    // false
>     false == '0'        // true
>     

>     false == undefined  // false
>     false == null       // false
>     null == undefined   // true
>     

>     ' \t\r\n ' == 0     // true
>     

[![平等比较表](https://i.stack.imgur.com/yISob.png)](https://i.stack.imgur.com/yISob.png)

> 传递性的缺乏令人震惊。我的建议是永远不要使用邪恶的双胞胎。相反，请始终使用`===`和`!==`。刚刚显示的所有比较都`false`与`===`运算符有关。

* * *

### 更新

[@Casebash](https://stackoverflow.com/users/165495/casebash)在评论和[@Phillipe Laybaert 关于对象的](https://stackoverflow.com/users/113570/philippe-leybaert) [回答](https://stackoverflow.com/a/957602/1288)中提出了一个很好的观点。对于对象来说，彼此的`==`行为`===`一致（特殊情况除外）。

    var a = [1,2,3];
    var b = [1,2,3];
    
    var c = { x: 1, y: 2 };
    var d = { x: 1, y: 2 };
    
    var e = "text";
    var f = "te" + "xt";
    
    a == b            // false
    a === b           // false
    
    c == d            // false
    c === d           // false
    
    e == f            // true
    e === f           // true
    

特殊情况是当您将一个基元与一个由于其`toString`or`valueOf`方法而计算结果相同的对象进行比较时。例如，考虑将字符串基元与使用`String`构造函数创建的字符串对象进行比较。

    "abc" == new String("abc")    // true
    "abc" === new String("abc")   // false
    

这里`==`操作符检查两个对象的值并返回`true`，但`===`发现它们的类型不同并返回`false`。哪一个是正确的？这实际上取决于您要比较的内容。我的建议是完全绕过这个问题，只是不要使用`String`构造函数从字符串文字创建字符串对象。

**参考**  
[https://262.ecma-international.org/5.1/#sec-11.9.3](https://262.ecma-international.org/5.1/#sec-11.9.3)

### Using the `==` operator (_Equality_)

    true == 1; //true, because 'true' is converted to 1 and then compared
    "2" == 2;  //true, because "2" is converted to 2 and then compared
    

### Using the `===` operator (_Identity_)

    true === 1; //false
    "2" === 2;  //false
    

This is because the **equality operator `==` does type coercion**, meaning that the interpreter implicitly tries to convert the values before comparing.

On the other hand, the **identity operator `===` does not do type coercion**, and thus does not convert the values when comparing.

Here's an interesting visualisation of the equality comparison between `==` and `===`.

**Source: [https://github.com/dorey/JavaScript-Equality-Table](https://github.com/dorey/JavaScript-Equality-Table)** ([demo](https://dorey.github.io/JavaScript-Equality-Table/), [unified demo](https://dorey.github.io/JavaScript-Equality-Table/unified/))

* * *

`var1 === var2`
---------------

When using `===` for JavaScript equality testing, everything is as is.  
Nothing gets converted before being evaluated.

![JS中===的相等性判断](https://i.stack.imgur.com/62vxI.png)

`var1 == var2`
--------------

When using `==` for JavaScript equality testing, some _**funky conversions**_ take place.

![JS中==的相等性判断](https://i.stack.imgur.com/35MpY.png)

### Summary of equality in Javascript

![JavaScript 中的平等](https://i.stack.imgur.com/FX7z1.png)

* * *

### Conclusion:

**Always use `===`**, unless you fully understand the [funky conversions](https://dorey.github.io/JavaScript-Equality-Table/#two-equals) that take place with `==`.

In the answers here, I didn't read anything about what **equal** means. Some will say that `===` means **equal and of the same type**, but that's not really true. It actually means that **both operands reference the same object**, or in case of **value types, have the same value**.

So, let's take the following code:

    var a = [1,2,3];
    var b = [1,2,3];
    var c = a;
    
    var ab_eq = (a === b); // false (even though a and b are the same type)
    var ac_eq = (a === c); // true
    

The same here:

    var a = { x: 1, y: 2 };
    var b = { x: 1, y: 2 };
    var c = a;
    
    var ab_eq = (a === b); // false (even though a and b are the same type)
    var ac_eq = (a === c); // true
    

Or even:

    var a = { };
    var b = { };
    var c = a;
    
    var ab_eq = (a === b); // false (even though a and b are the same type)
    var ac_eq = (a === c); // true
    

This behavior is not always obvious. There's more to the story than being equal and being of the same type.

The rule is:

_**For value types (numbers):**_  
`a === b` returns true if `a` and `b` have the same value and are of the same type

_**For reference types:**_  
`a === b` returns true if `a` and `b` reference the exact same object

_**For strings:**_  
`a === b` returns true if `a` and `b` are both strings and contain the exact same characters

* * *

Strings: the special case...
----------------------------

Strings are not value types, but in Javascript they behave like value types, so they will be "equal" when the characters in the string are the same and when they are of the same length (as explained in the third rule)

Now it becomes interesting:

    var a = "12" + "3";
    var b = "123";
    
    alert(a === b); // returns true, because strings behave like value types
    

But how about this?:

    var a = new String("123");
    var b = "123";
    
    alert(a === b); // returns false !! (but they are equal and of the same type)
    

I thought strings behave like value types? Well, it depends who you ask... In this case a and b are not the same type. `a` is of type `Object`, while `b` is of type `string`. Just remember that creating a string object using the `String` constructor creates something of type `Object` that behaves as a string _most of the time_.

Let me add this counsel:

_**If in doubt, read the [specification](http://www.ecma-international.org/publications/standards/Ecma-262.htm)!**_

ECMA-262 is the specification for a scripting language of which JavaScript is a dialect. Of course in practice it matters more how the most important browsers behave than an esoteric definition of how something is supposed to be handled. But it is helpful to understand why **new String("a") !== "a"**.

Please let me explain how to read the specification to clarify this question. I see that in this very old topic nobody had an answer for the very strange effect. So, if you can read a specification, this will help you in your profession tremendously. It is an acquired skill. So, let's continue.

Searching the PDF file for === brings me to page 56 of the specification: **11.9.4. The Strict Equals Operator ( === )**, and after wading through the specificationalese I find:

> **11.9.6 The Strict Equality Comparison Algorithm**  
> The comparison x === y, where x and y are values, produces **true** or **false**. Such a comparison is performed as follows:  
>   1. If Type(x) is different from Type(y), return **false**.  
>   2. If Type(x) is Undefined, return **true**.  
>   3. If Type(x) is Null, return **true**.  
>   4. If Type(x) is not Number, go to step 11.  
>   5. If x is **NaN**, return **false**.  
>   6. If y is **NaN**, return **false**.  
>   7. If x is the same number value as y, return **true**.  
>   8. If x is +0 and y is −0, return **true**.  
>   9. If x is −0 and y is +0, return **true**.  
>   10. Return **false**.  
>   11. If Type(x) is String, then return **true** if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions); otherwise, return **false**.  
>   12. If Type(x) is Boolean, return **true** if x and y are both **true** or both **false**; otherwise, return **false**.  
>   13. Return **true** if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return **false**.

Interesting is step 11. Yes, strings are treated as value types. But this does not explain why **new String("a") !== "a"**. Do we have a browser not conforming to ECMA-262?

Not so fast!

Let's check the types of the operands. Try it out for yourself by wrapping them in **typeof()**. I find that **new String("a")** is an object, and step 1 is used: return **false** if the types are different.

If you wonder why **new String("a")** does not return a string, how about some exercise reading a specification? Have fun!

* * *

Aidiakapi wrote this in a comment below:

> From the specification
> 
> **11.2.2 The new Operator**:
> 
> If Type(constructor) is not Object, throw a TypeError exception.
> 
> With other words, if String wouldn't be of type Object it couldn't be used with the new operator.

**new** always returns an Object, even for **String** constructors, too. And alas! The value semantics for strings (see step 11) is lost.

And this finally means: **new String("a") !== "a"**.

I tested this in Firefox with [Firebug](http://en.wikipedia.org/wiki/Firebug_%28software%29) using code like this:

    console.time("testEquality");
    var n = 0;
    while (true) {
      n++;
      if (n == 100000)
        break;
    }
    console.timeEnd("testEquality");

Run code snippetHide results

Expand snippet

and

    console.time("testTypeEquality");
    var n = 0;
    while (true) {
      n++;
      if (n === 100000)
        break;
    }
    console.timeEnd("testTypeEquality");

Run code snippetHide results

Expand snippet

My results (tested five times each and averaged):

    ==: 115.2
    ===: 114.4
    

So I'd say that the miniscule difference (this is over 100000 iterations, remember) is negligible. Performance _**isn't**_ a reason to do `===`. Type safety (well, as safe as you're going to get in JavaScript), and code quality is.

In PHP and JavaScript, it is a strict equality operator. Which means, it will compare both type and values.

In JavaScript it means of the same value and type.

For example,

    4 == "4" // will return true
    

but

    4 === "4" // will return false

**为什么 `==` 这么难以预测？**

当你将空字符串 `""` 与数字零 `0` 进行比较时，会得到什么结果？

`true`

没错，根据 `==` 的规则，一个空字符串和数字零被认为是相同的。

但这还不是全部。再看这个例子：

```
'0' == false // true
```

**数组的情况更加奇怪。**

```
[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true
```

**字符串的情况则更加怪异**

```
[1,2,3] == '1,2,3' // true - 真的吗?!
'\r\n\t' == 0 // true - 这也太扯了吧!
```

情况还会变得更糟：

**什么时候相等不等于相等？**

```
let A = ''  // 空字符串
let B = 0   // 数字零
let C = '0' // 字符串中的零

A == B // true - 好吧...
B == C // true - 到目前为止还不错...
A == C // **FALSE** - 情节转折！
```

我们再来看一遍：

```
(A == B) && (B == C) // true
(A == C) // **FALSE**
```

这些疯狂的事情只发生在原始类型上。

当你使用 `==` 来比较对象时，情况会变得完全不同。

这时你可能会想...

**为什么会这样发生？**

这是因为不像 "三等号"（`===`）只检查两个值是否完全相同。

`==` 做了**一大堆其他的事情**。

它对待函数、null、undefined、字符串等都有特殊处理。

事情变得相当混乱。

事实上，如果你尝试编写一个执行 `==` 相同操作的函数，它可能看起来像这样：

```javascript
function isEqual(x, y) { // 如果 `==` 是一个函数
    if (typeof y === typeof x) return y === x;
    // 将 null 和 undefined 视为相同
    var xIsNothing = (y === undefined) || (y === null);
    var yIsNothing = (x === undefined) || (x === null);

    if (xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);

    if (typeof y === "function" || typeof x === "function") {
        // 如果任一值是字符串
        // 将函数转换为字符串并比较
        if (typeof x === "string") {
            return x === y.toString();
        } else if (typeof y === "string") {
            return x.toString() === y;
        }
        return false;
    }

    if (typeof x === "object") x = toPrimitive(x);
    if (typeof y === "object") y = toPrimitive(y);
    if (typeof y === typeof x) return y === x;

    // 如果 x 和 y 不是数字，则将它们转换为数字
    if (typeof x !== "number") x = +x;
    if (typeof y !== "number") y = +y;
    // 实际上真正的 `==` 比这还要复杂，尤其是在ES6中
    return x === y;
}

function toPrimitive(obj) {
    var value = obj.valueOf();
    if (value !== obj) return value;
    return obj.toString();
}
```

**这意味着什么？**

意味着 `==` 很复杂。

因为它复杂，所以很难知道在使用它时会发生什么。

这意味着你可能会遇到bug。

**故事的寓意是...**

让你的生活变得简单些。

使用 `===` 而不是 `==`。



故事结束。

The **\===** operator is called a strict comparison operator, it **does** differ from the **\==** operator.

Lets take 2 vars a and b.

For **"a == b"** to evaluate to true a and b need to be the **same value**.

In the case of **"a === b"** a and b must be the **same value** and also the **same type** for it to evaluate to true.

Take the following example

    var a = 1;
    var b = "1";
    
    if (a == b) //evaluates to true as a and b are both 1
    {
        alert("a == b");
    }
    
    if (a === b) //evaluates to false as a is not the same type as b
    {
        alert("a === b");
    }
    

**In summary**; using the **\==** operator might evaluate to true in situations where you do not want it to so using the **\===** operator would be safer.

In the 90% usage scenario it won't matter which one you use, but it is handy to know the difference when you get some unexpected behaviour one day.

`===` checks same sides are equal in _type_ as well as _value_.
---------------------------------------------------------------

* * *

Example:
--------

    '1' === 1 // will return "false" because `string` is not a `number`
    

Common example:
---------------

    0 == ''  // will be "true", but it's very common to want this check to be "false"
    

Another common example:
-----------------------

    null == undefined // returns "true", but in most cases a distinction is necessary
    

* * *

From my long-time experience an _untyped_ check is preferable because you do not care if the value is either `undefined`, `null`, `0` or `""`

Another comparison approach is using `Object.is` and [here's a great informative answer about it](https://stackoverflow.com/a/30543212/104380).

Javascript execution flow diagram for strict equality / Comparison '==='

[![Javascript strict equality](https://i.stack.imgur.com/A27Be.png)](https://i.stack.imgur.com/A27Be.png)

Javascript execution flow diagram for non strict equality / comparison '=='

[![Javascript non equality](https://i.stack.imgur.com/Ccyb8.png)](https://i.stack.imgur.com/Ccyb8.png)

JavaScript `===` **vs** `==` .

    0==false   // true
    0===false  // false, because they are of a different type
    1=="1"     // true, auto type coercion
    1==="1"    // false, because they are of a different type

It means **equality without type coercion** type coercion means JavaScript do not automatically convert any other data types to string data types

    0==false   // true,although they are different types
    
    0===false  // false,as they are different types
    
    2=='2'    //true,different types,one is string and another is integer but 
                javaScript convert 2 to string by using == operator 
    
    2==='2'  //false because by using === operator ,javaScript do not convert 
               integer to string 
    
    2===2   //true because both have same value and same types

In a typical script there will be no performance difference. More important may be the fact that thousand "===" is 1 KB heavier than thousand "==" :) [JavaScript profilers](https://stackoverflow.com/questions/tagged/javascript+performance) can tell you if there is a performance difference in your case.

But personally I would do what JSLint suggests. This recommendation is there not because of performance issues, but because type coercion means `('\t\r\n' == 0)` is true.

_**The equal comparison operator == is confusing and should be avoided.**_

If you **HAVE TO** live with it, then remember the following 3 things:

1.  **It is not transitive: _(a == b)_ and _(b == c)_ does not lead to _(a == c)_**
2.  **It's mutually exclusive to its negation: _(a == b)_ and _(a != b)_ always hold opposite Boolean values, with all a and b.**
3.  **In case of doubt, learn by heart the following truth table:**

EQUAL OPERATOR TRUTH TABLE IN JAVASCRIPT

*   Each row in the table is a set of 3 mutually "equal" values, meaning that any 2 values among them are equal using the equal == sign\*

\*\* STRANGE: note that any two values on the first column are not equal in that sense.\*\*

    ''       == 0 == false   // Any two values among these 3 ones are equal with the == operator
    '0'      == 0 == false   // Also a set of 3 equal values, note that only 0 and false are repeated
    '\t'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    '\r'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    '\n'     == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    '\t\r\n' == 0 == false   // -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    
    null == undefined  // These two "default" values are not-equal to any of the listed values above
    NaN                // NaN is not equal to any thing, even to itself.

There is unlikely to be any performance difference between the two operations in your usage. There is no type-conversion to be done because both parameters are already the same type. Both operations will have a type comparison followed by a value comparison.

Simply

`==` means **comparison** between operands **with** type coercion

and

`===` means **comparison** between operands **without** type coercion.

Type coercion in JavaScript means automatically converting data types to other data types.

For example:

    123 == "123"  // Returns true, because JS coerces string "123" to number 123
                  // and then goes on to compare `123 == 123`.
    
    123 === "123" // Returns false, because JS does not coerce values of different types here.

**Yes!** It does matter.

`===` operator in javascript **checks value as well as type** where as `==` operator just checks **the value (does type conversion if required)**.

![enter image description here](https://i.stack.imgur.com/5ttlR.png)

You can easily test it. Paste following code in an HTML file and open it in browser

 <script>
 
 function onPageLoad()
 {
 var x = "5";
 var y = 5;
 alert(x === 5);
 };
 
 </script>
 
 </head>
 
 <body onload='onPageLoad();'>
 

You will get '**false**' in alert. Now modify the `onPageLoad()` method to `alert(x == 5);` you will get **true**.

As a rule of thumb, I would generally use `===` instead of `==` (and `!==` instead of `!=`).

Reasons are explained in in the answers above and also Douglas Crockford is pretty clear about it ([JavaScript: The Good Parts](https://rads.stackoverflow.com/amzn/click/com/0596517742)).

However there is **one single exception**: `== null` is an efficient way to check for 'is null or undefined':

    if( value == null ){
        // value is either null or undefined
    }
    

For example jQuery 1.9.1 uses this pattern 43 times, and the [JSHint syntax checker](http://www.jshint.com/docs/#options) even provides the `eqnull` relaxing option for this reason.

From the [jQuery style guide](http://contribute.jquery.org/style-guide/js/):

> Strict equality checks (===) should be used in favor of ==. The only exception is when checking for undefined and null by way of null.

    // Check for both undefined and null values, for some important reason. 
    undefOrNull == null;
    

EDIT 2021-03:

Nowadays [most browsers](https://caniuse.com/mdn-javascript_operators_logical_nullish_assignment) support the [Nullish coalescing operator (`??`)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing_operator) and the [Logical nullish assignment `(??=)`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Logical_nullish_assignment), which allows a more concise way to assign a default value if a variable is null or undefined, for example:

    if (a.speed == null) {
      // Set default if null or undefined
      a.speed = 42;
    }
    

can be written as any of these forms

    a.speed ??= 42;
    a.speed ?? a.speed = 42;
    a.speed = a.speed ?? 42;

It's a strict check test.

It's a good thing especially if you're checking between 0 and false and null.

For example, if you have:

    $a = 0;
    

Then:

    $a==0; 
    $a==NULL;
    $a==false;
    

All returns true and you may not want this. Let's suppose you have a function that can return the 0th index of an array or false on failure. If you check with "==" false, you can get a confusing result.

So with the same thing as above, but a strict test:

    $a = 0;
    
    $a===0; // returns true
    $a===NULL; // returns false
    $a===false; // returns false

`===` operator checks the values as well as the types of the variables for equality.

`==` operator just checks the value of the variables for equality.

JSLint sometimes gives you unrealistic reasons to modify stuff. `===` has exactly the same performance as `==` if the types are already the same.

It is faster only when the types are not the same, in which case it does not try to convert types but directly returns a false.

So, _IMHO,_ JSLint maybe used to write new code, but useless over-optimizing should be avoided at all costs.

Meaning, there is no reason to change `==` to `===` in a check like `if (a == 'test')` when you know it for a fact that a can only be a String.

Modifying a lot of code that way wastes developers' and reviewers' time and achieves nothing.

A simple example is

    2 == '2'  -> true, values are SAME because of type conversion.
    
    2 === '2'  -> false, values are NOT SAME because of no type conversion.

The top 2 answers both mentioned == means equality and === means identity. Unfortunately, this statement is incorrect.

If both operands of == are objects, then they are compared to see if they are the same object. If both operands point to the same object, then the equal operator returns true. Otherwise, the two are not equal.

    var a = [1, 2, 3];  
    var b = [1, 2, 3];  
    console.log(a == b)  // false  
    console.log(a === b) // false  
    

In the code above, both == and === get false because a and b are not the same objects.

That's to say: if both operands of == are objects, == behaves same as ===, which also means identity. The essential difference of this two operators is about type conversion. == has conversion before it checks equality, but === does not.

The problem is that you might easily get into trouble since JavaScript have a lot of implicit conversions meaning...

    var x = 0;
    var isTrue = x == null;
    var isFalse = x === null;
    

Which pretty soon becomes a problem. The best sample of why implicit conversion is "evil" can be taken from this code in [MFC](http://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library) / C++ which actually will compile due to an implicit conversion from CString to HANDLE which is a pointer typedef type...

    CString x;
    delete x;
    

Which obviously during runtime does _very_ undefined things...

Google for implicit conversions in C++ and [STL](http://en.wikipedia.org/wiki/Standard_Template_Library) to get some of the arguments against it...

From the [core javascript reference](https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Operators/Comparison_Operators)

> `===` Returns `true` if the operands are strictly equal (see above) with no type conversion.

**Equality comparison:**

Operator `==`

Returns true, when both operands are equal. The operands are converted to the same type before being compared.

    >>> 1 == 1
    true
    >>> 1 == 2
    false
    >>> 1 == '1'
    true
    

**Equality and type comparison:**

Operator `===`

Returns true if both operands are equal and of the same type. It's generally better and safer if you compare this way, because there's no behind-the-scenes type conversions.

    >>> 1 === '1'
    false
    >>> 1 === 1
    true

Here is a handy comparison table that shows the conversions that happen and the differences between `==` and `===`.

As the conclusion states:

> "Use three equals unless you fully understand the conversions that take place for two-equals."

[http://dorey.github.io/JavaScript-Equality-Table/](http://dorey.github.io/JavaScript-Equality-Table/)

在JavaScript中，`null` 和 `undefined` 都代表不存在的值，即：

```javascript
var a;         // a被声明了，但没有赋值，其值为undefined
var b = null;  // b被赋予了null，表示一个空值
```

这里变量 `a` 和 `b` 都没有具体的值。相对地，0、`false` 和空字符串 `''` 虽然代表各自的值，但它们有一个共同点：都被认为是假值（falsy value），也就是说，在条件判断中它们都会被当作 `false`。

据此，0、`false` 和 `''` 可以看作是一组特殊的假值。而 `null` 和 `undefined` 则构成另一组特殊的无值。查看下面的比较图，`null` 与 `undefined` 在JavaScript中被认为是相等的。同理，0、`false` 和 `''` 也被认为彼此相等。尽管如此，它们在JavaScript中都符合假值的条件。

![在此输入图像描述](https://i.stack.imgur.com/11I0i.jpg)

与此相对，任何对象（如 `{}` 和数组等）、非空字符串以及布尔值 `true` 都被视为真值（truthy value），在条件判断中它们相当于 `true`。但是，这些真值并不意味着它们之间相等。

在 JavaScript 中，你通常应该使用 `===` (严格等于) 运算符来进行比较操作，而不是 `==` (宽松等于) 运算符。

`===` (严格等于) 运算符会比较两个值的类型和值，只有当两者都相等时，它才会返回 `true`。这意味着如果两个值的类型不同，它们永远不会被认为是严格相等的。

```javascript
3 === '3' // false，因为一个是数字类型，另一个是字符串类型
```

而 `==` (宽松等于) 运算符会在比较之前将两个值进行类型转换（如果它们的类型不同的话），然后再比较它们的值。

```javascript
3 == '3' // true，因为字符串 '3' 会被转换成数字 3
```

使用 `===` 可以避免由 JavaScript 自动类型转换导致的潜在错误和混淆，因此它通常是一个更好的选择。然而，必须指出在某些罕见情况下，如果你确实需要进行类型转换，那么使用 `==` 也是合适的。但在多数情况下，推荐使用 `===` 来确保代码的准确性和清晰性。

JS 中应该使用哪个等于运算符 == 和 === ？

在JavaScript中，`let`和`var`都可用于声明变量，但它们之间存在几个关键的区别：

1. **作用域**：
   - `var`声明的变量拥有函数作用域，如果在函数之外声明，则为全局作用域。
   - `let`声明的变量拥有块级作用域（block scope），即只在其声明的块或子块中有效。

**例子**：
```javascript
function varTest() {
  if (true) {
    var x = 2;
  }
  console.log(x); // 输出2，因为x在整个函数中都是可见的
}

function letTest() {
  if (true) {
    let y = 2;
  }
  console.log(y); // 引发错误，y不可见，因为它只在if块中有效
}
```
   
2. **变量提升**：
   - `var`声明的变量会被提升至函数或全局作用域的顶部，但是在执行到声明语句之前，变量的值是`undefined`。
   - `let`声明的变量也存在提升，但不会被初始化。在代码执行到声明语句之前，它不可以被访问，这个区间称为“暂时性死区”（temporal dead zone）。

**例子**：
```javascript
console.log(a); // 输出undefined，因为var声明的变量被提升了
var a = 3;

console.log(b); // 引发ReferenceError错误，因为此时b还在暂时性死区
let b = 4;
```

3. **重复声明**：
   - 使用`var`声明变量时，可以在同一作用域中重复声明同一个变量而不会出错。
   - 使用`let`声明变量时，不允许在相同作用域内重复声明同一个变量。

**例子**：
```javascript
var c = 1;
var c = 2; // 有效，不会出错

let d = 1;
let d = 2; // 无效，会引发SyntaxError错误
```

4. **全局对象的属性**：
   - 在全局作用域中，用`var`声明变量会创建一个新的全局对象的属性。
   - 用`let`在全局作用域中声明变量不会在全局对象中添加属性。

**例子**：
```javascript
var e = 5; // 在浏览器中，window.e将会是5
let f = 5; // 在浏览器中，window.f将是undefined
```

总结来说，`let`提供了比`var`更严格的作用域控制，是ES6引入的，以解决`var`引起的一些作用域问题并提供更好的代码管理方式。在现代JavaScript编程中，一般推荐使用`let`（和`const`）来代替`var`。

范围规则
====

主要区别在于范围规则。由关键字声明的变量的作用域`var`为直接函数体（因此为函数作用域），而`let`变量的作用域为由 表示的直接_封闭_块`{ }`（因此为块作用域）。

 function run() {
 var foo = "Foo";
 let bar = "Bar";
 
 console.log(foo, bar); // Foo Bar
 
 {
 var moo = "Mooo"
 let baz = "Bazz";
 console.log(moo, baz); // Mooo Bazz
 }
 
 console.log(moo); // Mooo
 console.log(baz); // ReferenceError
 }
 
 run();

运行代码片段Hide results

展开片段

`let`语言中引入关键字的原因是函数作用域令人困惑，并且是 JavaScript 中错误的主要来源之一。

看一下[另一个 Stack Overflow 问题](https://stackoverflow.com/questions/750486/javascript-closure-inside-loops-simple-practical-example)中的示例：

 var funcs = [];
 // let's create 3 functions
 for (var i = 0; i < 3; i++) {
 // and store them in funcs
 funcs[i] = function() {
 // each should log its value.
 console.log("My value: " + i);
 };
 }
 for (var j = 0; j < 3; j++) {
 // and now let's run each one to see
 funcs[j]();
 }

运行代码片段Hide results

展开片段

`My value: 3``funcs[j]();`由于匿名函数绑定到同一变量，因此每次调用时都会输出到控制台。

人们必须创建立即调用的函数来从循环中捕获正确的值，但这也很麻烦。

吊装
==

使用关键字声明的变量`var`会[被提升并_初始化_](https://dev.to/godcrampy/the-secret-of-hoisting-in-javascript-egi)，这意味着即使在声明它们之前，它们也可以在其封闭范围内访问，但是它们的值是`undefined`在到达声明语句之前：

 function checkHoisting() {
 console.log(foo); // undefined
 var foo = "Foo";
 console.log(foo); // Foo
 }
 
 checkHoisting();

运行代码片段Hide results

展开片段

`let` variables are [hoisted but _not initialized_](https://stackoverflow.com/questions/31219420/are-variables-declared-with-let-or-const-hoisted) until their definition is evaluated. Accessing them before the initialization results in a `ReferenceError`. The variable is said to be in [the temporal dead zone](https://stackoverflow.com/questions/33198849/what-is-the-temporal-dead-zone) from the start of the block until the declaration statement is processed.

 function checkHoisting() {
 console.log(foo); // ReferenceError
 let foo = "Foo";
 console.log(foo); // Foo
 }
 
 checkHoisting();

Run code snippetHide results

Expand snippet

Creating global object property
===============================

At the top level, `let`, unlike `var`, does not create a property on the global object:

 var foo = "Foo"; // globally scoped
 let bar = "Bar"; // globally scoped but not part of the global object
 
 console.log(window.foo); // Foo
 console.log(window.bar); // undefined

Run code snippetHide results

Expand snippet

Redeclaration
=============

In strict mode, `var` will let you re-declare the same variable in the same scope while `let` raises a SyntaxError.

 'use strict';
 var foo = "foo1";
 var foo = "foo2"; // No problem, 'foo1' is replaced with 'foo2'.
 
 let bar = "bar1"; 
 let bar = "bar2"; // SyntaxError: Identifier 'bar' has already been declared

Run code snippetHide results

Expand snippet

`let` can also be used to avoid problems with closures. It binds fresh value rather than keeping an old reference as shown in examples below.

 for(var i=1; i<6; i++) {
 $("#div" + i).click(function () { console.log(i); });
 }

 <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
 Clicking on each number will log to console: 
 <div id="div1">1</div>
 <div id="div2">2</div>
 <div id="div3">3</div>
 <div id="div4">4</div>
 <div id="div5">5</div>

Run code snippetHide results

Expand snippet

Code above demonstrates a classic JavaScript closure problem. Reference to the `i` variable is being stored in the click handler closure, rather than the actual value of `i`.

Every single click handler will refer to the same object because there’s only one counter object which holds 6 so you get six on each click.

A general workaround is to wrap this in an anonymous function and pass `i` as an argument. Such issues can also be avoided now by using `let` instead `var` as shown in the code below.

(Tested in Chrome and Firefox 50)

 for(let i=1; i<6; i++) {
 $("#div" + i).click(function () { console.log(i); });
 }

 <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
 Clicking on each number will log to console: 
 <div id="div1">1</div>
 <div id="div2">2</div>
 <div id="div3">3</div>
 <div id="div4">4</div>
 <div id="div5">5</div>

Run code snippetHide results

Expand snippet

### What's the difference between `let` and `var`?

* A variable defined using a `var` statement is known throughout [**the function**](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/function) it is defined in, from the start of the function. _(\*)_
* A variable defined using a `let` statement is only known in [**the block**](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/block) it is defined in, from the moment it is defined onward. _(\*\*)_

To understand the difference, consider the following code:

 // i IS NOT known here
 // j IS NOT known here
 // k IS known here, but undefined
 // l IS NOT known here
 
 function loop(arr) {
 // i IS known here, but undefined
 // j IS NOT known here
 // k IS known here, but has a value only the second time loop is called
 // l IS NOT known here
 
 for( var i = 0; i < arr.length; i++ ) {
 // i IS known here, and has a value
 // j IS NOT known here
 // k IS known here, but has a value only the second time loop is called
 // l IS NOT known here
 };
 
 // i IS known here, and has a value
 // j IS NOT known here
 // k IS known here, but has a value only the second time loop is called
 // l IS NOT known here
 
 for( let j = 0; j < arr.length; j++ ) {
 // i IS known here, and has a value
 // j IS known here, and has a value
 // k IS known here, but has a value only the second time loop is called
 // l IS NOT known here
 };
 
 // i IS known here, and has a value
 // j IS NOT known here
 // k IS known here, but has a value only the second time loop is called
 // l IS NOT known here
 }
 
 loop([1,2,3,4]);
 
 for( var k = 0; k < arr.length; k++ ) {
 // i IS NOT known here
 // j IS NOT known here
 // k IS known here, and has a value
 // l IS NOT known here
 };
 
 for( let l = 0; l < arr.length; l++ ) {
 // i IS NOT known here
 // j IS NOT known here
 // k IS known here, and has a value
 // l IS known here, and has a value
 };
 
 loop([1,2,3,4]);
 
 // i IS NOT known here
 // j IS NOT known here
 // k IS known here, and has a value
 // l IS NOT known here
 

Here, we can see that our variable `j` is only known in the first for loop, but not before and after. Yet, our variable `i` is known in the entire function.

Also, consider that block scoped variables are not known before they are declared because they are not hoisted. You're also not allowed to redeclare the same block scoped variable within the same block. This makes block scoped variables less error prone than globally or functionally scoped variables, which are hoisted and which do not produce any errors in case of multiple declarations.

* * *

### Is it safe to use `let` today?

Some people would argue that in the future we'll ONLY use let statements and that var statements will become obsolete. JavaScript guru [**Kyle Simpson**](https://twitter.com/getify) wrote [**a very elaborate article on why he believes that won't be the case**](https://davidwalsh.name/for-and-against-let).

Today, however, that is definitely not the case. In fact, we need actually to ask ourselves whether it's safe to use the `let` statement. The answer to that question depends on your environment:

* If you're writing server-side JavaScript code ([**Node.js**](https://nodejs.org/en/)), you can safely use the `let` statement.
 
* If you're writing client-side JavaScript code and use a browser based transpiler (like [**Traceur**](https://github.com/google/traceur-compiler) or [**babel-standalone**](https://github.com/babel/babel-standalone)), you can safely use the `let` statement, however your code is likely to be anything but optimal with respect to performance.
 
* If you're writing client-side JavaScript code and use a Node based transpiler (like the [**traceur shell script**](https://github.com/google/traceur-compiler/wiki/Compiling-Offline) or [**Babel**](https://babeljs.io/)), you can safely use the `let` statement. And, because your browser will only know about the transpiled code, performance drawbacks should be limited.
 
* If you're writing client-side JavaScript code and don't use a transpiler, you need to consider browser support.
 
 There are still some browsers that don't support `let` at all :
 

[![在此输入图像描述](https://i.stack.imgur.com/J9kEC.png)](https://i.stack.imgur.com/J9kEC.png)

* * *

### How to keep track of browser support

For an up-to-date overview of which browsers support the `let` statement at the time of your reading this answer, see [**this `Can I Use` page**](http://caniuse.com/#search=let).

* * *

_(\*) Globally and functionally scoped variables can be initialized and used before they are declared because JavaScript variables are [**hoisted**](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting)._ This means that declarations are always moved to the top of the scope.

_(\*\*) Block scoped variables are not hoisted_

Here's an [explanation of the `let` keyword](https://developer.mozilla.org/en/New_in_JavaScript_1.7#Block_scope_with_let) with some examples.

> `let` works very much like `var`. The main difference is that the scope of a `var` variable is the entire enclosing function

[This table](http://en.wikipedia.org/wiki/JavaScript#Version_history) on Wikipedia shows which browsers support Javascript 1.7.

Note that only Mozilla and Chrome browsers support it. IE, Safari, and potentially others don't.

`let`
=====

Block scope
-----------

Variables declared using the `let` keyword are block-scoped, which means that they are available only in the [block](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/block) in which they were declared.

### At the top level (outside of a function)

At the top level, variables declared using `let` don't create properties on the global object.

 var globalVariable = 42;
 let blockScopedVariable = 43;
 
 console.log(globalVariable); // 42
 console.log(blockScopedVariable); // 43
 
 console.log(this.globalVariable); // 42
 console.log(this.blockScopedVariable); // undefined
 

### Inside a function

Inside a function (but outside of a block), `let` has the same scope as `var`.

 (() => {
 var functionScopedVariable = 42;
 let blockScopedVariable = 43;
 
 console.log(functionScopedVariable); // 42
 console.log(blockScopedVariable); // 43
 })();
 
 console.log(functionScopedVariable); // ReferenceError: functionScopedVariable is not defined
 console.log(blockScopedVariable); // ReferenceError: blockScopedVariable is not defined
 

### Inside a block

Variables declared using `let` inside a block can't be accessed outside that block.

 {
 var globalVariable = 42;
 let blockScopedVariable = 43;
 console.log(globalVariable); // 42
 console.log(blockScopedVariable); // 43
 }
 
 console.log(globalVariable); // 42
 console.log(blockScopedVariable); // ReferenceError: blockScopedVariable is not defined
 

### Inside a loop

Variables declared with `let` in loops can be referenced only inside that loop.

 for (var i = 0; i < 3; i++) {
 var j = i * 2;
 }
 console.log(i); // 3
 console.log(j); // 4
 
 for (let k = 0; k < 3; k++) {
 let l = k * 2;
 }
 console.log(typeof k); // undefined
 console.log(typeof l); // undefined
 // Trying to do console.log(k) or console.log(l) here would throw a ReferenceError.
 

### Loops with closures

If you use `let` instead of `var` in a loop, with each iteration you get a new variable. That means that you can safely use a closure inside a loop.

 // Logs 3 thrice, not what we meant.
 for (var i = 0; i < 3; i++) {
 setTimeout(() => console.log(i), 0);
 }
 
 // Logs 0, 1 and 2, as expected.
 for (let j = 0; j < 3; j++) {
 setTimeout(() => console.log(j), 0);
 }
 

Temporal dead zone
------------------

Because of [the temporal dead zone](https://stackoverflow.com/q/33198849/3853934), variables declared using `let` can't be accessed before they are declared. Attempting to do so throws an error.

 console.log(noTDZ); // undefined
 var noTDZ = 43;
 console.log(hasTDZ); // ReferenceError: hasTDZ is not defined
 let hasTDZ = 42;
 

No re-declaring
---------------

You can't declare the same variable multiple times using `let`. You also can't declare a variable using `let` with the same identifier as another variable which was declared using `var`.

 var a;
 var a; // Works fine.
 
 let b;
 let b; // SyntaxError: Identifier 'b' has already been declared
 
 var c;
 let c; // SyntaxError: Identifier 'c' has already been declared
 

`const`
=======

`const` is quite similar to `let`—it's block-scoped and has TDZ. There are, however, two things which are different.

No re-assigning
---------------

Variable declared using `const` can't be re-assigned.

 const a = 42;
 a = 43; // TypeError: Assignment to constant variable.
 

Note that it doesn't mean that the value is immutable. Its properties still can be changed.

 const obj = {};
 obj.a = 42;
 console.log(obj.a); // 42
 

If you want to have an immutable object, you should use [`Object.freeze()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze).

 const obj = Object.freeze({a: 40});
 obj.a = 42;
 console.log(obj.a); // 40
 console.log(obj.b); // undefined
 

Initializer is required
-----------------------

You always must specify a value when declaring a variable using `const`.

 const a; // SyntaxError: Missing initializer in const declaration

The accepted answer is missing a point:

    {
      let a = 123;
    };
    
    console.log(a); // ReferenceError: a is not defined

In most basic terms,
--------------------

```
for (let i = 0; i < 5; i++) {
 // i accessible ✔️
}
// i not accessible ❌
```

---

```
for (var i = 0; i < 5; i++) {
 // i accessible ✔️
}
// i accessible ✔️
```

---

Here is an example of the difference between the two: 
![在此输入图像描述](https://i.stack.imgur.com/dqNYW.png)

As you can see, the `var j` variable still has a value outside the for loop scope (Block Scope), but the `let i` variable is undefined outside of the for loop scope.

 "use strict";
 console.log("var:");
 for (var j = 0; j < 2; j++) {
 console.log(j);
 }
 
 console.log(j);
 
 console.log("let:");
 for (let i = 0; i < 2; i++) {
 console.log(i);
 }
 
 console.log(i);

Run code snippetHide results

Expand snippet

The main difference is the **scope** difference, while **let** can be only available inside the **scope** it's declared, like in for loop, **var** can be accessed outside the loop for example. From the documentation in [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let) (examples also from MDN):

> **let** allows you to declare variables that are limited in scope to the block, statement, or expression on which it is used. This is unlike the **var** keyword, which defines a variable globally, or locally to an entire function regardless of block scope.

> Variables declared by **let** have as their scope the block in which they are defined, as well as in any contained sub-blocks. In this way, **let** works very much like **var**. The main difference is that the scope of a **var** variable is the entire enclosing function:
> 
>     function varTest() {
>       var x = 1;
>       if (true) {
>         var x = 2;  // same variable!
>         console.log(x);  // 2
>       }
>       console.log(x);  // 2
>     }
>     
>     function letTest() {
>       let x = 1;
>       if (true) {
>         let x = 2;  // different variable
>         console.log(x);  // 2
>       }
>       console.log(x);  // 1
>     }`
>     
> 
> At the top level of programs and functions, **let**, unlike **var**, does not create a property on the global object. For example:
> 
>     var x = 'global';
>     let y = 'global';
>     console.log(this.x); // "global"
>     console.log(this.y); // undefined
>     

> When used inside a block, let limits the variable's scope to that block. Note the difference between **var** whose scope is inside the function where it is declared.
> 
>     var a = 1;
>     var b = 2;
>     
>     if (a === 1) {
>       var a = 11; // the scope is global
>       let b = 22; // the scope is inside the if-block
>     
>       console.log(a);  // 11
>       console.log(b);  // 22
>     } 
>     
>     console.log(a); // 11
>     console.log(b); // 2
>     

Also don't forget it's ECMA6 feature, so it's not fully supported yet, so it's better always transpiles it to ECMA5 using Babel etc... for more info about visit [babel website](https://babeljs.io)

There are some subtle differences — `let` scoping behaves more like variable scoping does in more or less any other languages.

e.g. It scopes to the enclosing block, They don't exist before they're declared, etc.

However it's worth noting that `let` is only a part of newer Javascript implementations and has varying degrees of [browser support](http://caniuse.com/#search=let).

* **Variable Not Hoisting**
 
 `let` will **not hoist** to the entire scope of the block they appear in. By contrast, `var` could hoist as below.
 
 {
 console.log(cc); // undefined. Caused by hoisting
 var cc = 23;
 }
 
 {
 console.log(bb); // ReferenceError: bb is not defined
 let bb = 23;
 }
 
 
 Actually, Per @Bergi, [Both `var` and `let` are hoisted](https://stackoverflow.com/questions/31219420/are-variables-declared-with-let-or-const-not-hoisted-in-es6).
 
* **Garbage Collection**
 
 Block scope of `let` is useful relates to closures and garbage collection to reclaim memory. Consider,
 
 function process(data) {
 //...
 }
 
 var hugeData = { .. };
 
 process(hugeData);
 
 var btn = document.getElementById("mybutton");
 btn.addEventListener( "click", function click(evt){
 //....
 });
 
 
 The `click` handler callback does not need the `hugeData` variable at all. Theoretically, after `process(..)` runs, the huge data structure `hugeData` could be garbage collected. However, it's possible that some JS engine will still have to keep this huge structure, since the `click` function has a closure over the entire scope.
 
 However, the block scope can make this huge data structure to garbage collected.
 
 function process(data) {
 //...
 }
 
 { // anything declared inside this block can be garbage collected
 let hugeData = { .. };
 process(hugeData);
 }
 
 var btn = document.getElementById("mybutton");
 btn.addEventListener( "click", function click(evt){
 //....
 });
 
 
* **`let` loops**
 
 `let` in the loop can **re-binds it** to each iteration of the loop, making sure to re-assign it the value from the end of the previous loop iteration. Consider,
 
 // print '5' 5 times
 for (var i = 0; i < 5; ++i) {
 setTimeout(function () {
 console.log(i);
 }, 1000); 
 }
 
 
 However, replace `var` with `let`
 
 // print 1, 2, 3, 4, 5. now
 for (let i = 0; i < 5; ++i) {
 setTimeout(function () {
 console.log(i);
 }, 1000); 
 }
 
 
 Because `let` create a new lexical environment with those names for a) the initialiser expression b) each iteration (previosly to evaluating the increment expression), more details are [here](https://stackoverflow.com/a/30900289/3011380).

The difference is in the [scope](https://en.wikipedia.org/wiki/Variable_(computer_science)#Scope_and_extent) of the variables declared with each.

In practice, there are a number of useful consequences of the difference in scope:

1. `let` variables are only visible in their _nearest enclosing_ block (`{ ... }`).
2. `let` variables are only usable in lines of code that occur _after_ the variable is declared (even though [they are hoisted](/questions/33198849)!).
3. `let` variables may not be redeclared by a subsequent `var` or `let`.
4. Global `let` variables are not added to the global `window` object.
5. `let` variables are _easy to use_ with closures (they do not cause [race conditions](https://en.wikipedia.org/wiki/Race_condition#Software)).

The restrictions imposed by `let` reduce the visibility of the variables and increase the likelihood that unexpected name collisions will be found early. This makes it easier to track and reason about variables, including their [reachability](https://en.wikipedia.org/wiki/Unreachable_memory)(helping with reclaiming unused memory).

Consequently, `let` variables are less likely to cause problems when used in large programs or when independently-developed frameworks are combined in new and unexpected ways.

`var` may still be useful if you are sure you want the single-binding effect when using a closure in a loop (#5) or for declaring externally-visible global variables in your code (#4). Use of `var` for exports may be supplanted if [`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) migrates out of transpiler space and into the core language.

Examples
========

**1\. No use outside nearest enclosing block:** This block of code will throw a reference error because the second use of `x` occurs outside of the block where it is declared with `let`:

 {
 let x = 1;
 }
 console.log(`x is ${x}`); // ReferenceError during parsing: "x is not defined".
 

In contrast, the same example with `var` works.

**2\. No use before declaration:** 
This block of code will throw a `ReferenceError` before the code can be run because `x` is used before it is declared:

 {
 x = x + 1; // ReferenceError during parsing: "x is not defined".
 let x;
 console.log(`x is ${x}`); // Never runs.
 }
 

In contrast, the same example with `var` parses and runs without throwing any exceptions.

**3\. No redeclaration:** The following code demonstrates that a variable declared with `let` may not be redeclared later:

 let x = 1;
 let x = 2; // SyntaxError: Identifier 'x' has already been declared
 

**4\. Globals not attached to `window`:**

 var button = "I cause accidents because my name is too common.";
 let link = "Though my name is common, I am harder to access from other JS files.";
 console.log(link); // OK
 console.log(window.link); // undefined (GOOD!)
 console.log(window.button); // OK
 

**5\. Easy use with closures:** Variables declared with `var` do not work well with closures inside loops. Here is a simple loop that outputs the sequence of values that the variable `i` has at different points in time:

 for (let i = 0; i < 5; i++) {
 console.log(`i is ${i}`), 125/*ms*/);
 }
 

Specifically, this outputs:

 i is 0
 i is 1
 i is 2
 i is 3
 i is 4
 

In JavaScript we often use variables at a significantly later time than when they are created. When we demonstrate this by delaying the output with a closure passed to `setTimeout`:

 for (let i = 0; i < 5; i++) {
 setTimeout(_ => console.log(`i is ${i}`), 125/*ms*/);
 }
 

... the output remains unchanged as long as we stick with `let`. In contrast, if we had used `var i` instead:

 for (var i = 0; i < 5; i++) {
 setTimeout(_ => console.log(`i is ${i}`), 125/*ms*/);
 }
 

... the loop unexpectedly outputs "i is 5" five times:

 i is 5
 i is 5
 i is 5
 i is 5
 i is 5

Here's an example to add on to what others have already written. Suppose you want to make an array of functions, `adderFunctions`, where each function takes a single Number argument and returns the sum of the argument and the function's index in the array. Trying to generate `adderFunctions` with a loop using the `var` keyword won't work the way someone might naïvely expect:

 // An array of adder functions.
 var adderFunctions = [];
 
 for (var i = 0; i < 1000; i++) {
 // We want the function at index i to add the index to its argument.
 adderFunctions[i] = function(x) {
 // What is i bound to here?
 return x + i;
 };
 }
 
 var add12 = adderFunctions[12];
 
 // Uh oh. The function is bound to i in the outer scope, which is currently 1000.
 console.log(add12(8) === 20); // => false
 console.log(add12(8) === 1008); // => true
 console.log(i); // => 1000
 
 // It gets worse.
 i = -8;
 console.log(add12(8) === 0); // => true
 

The process above doesn't generate the desired array of functions because `i`'s scope extends beyond the iteration of the `for` block in which each function was created. Instead, at the end of the loop, the `i` in each function's closure refers to `i`'s value at the end of the loop (1000) for every anonymous function in `adderFunctions`. This isn't what we wanted at all: we now have an array of 1000 different functions in memory with exactly the same behavior. And if we subsequently update the value of `i`, the mutation will affect all the `adderFunctions`.

However, we can try again using the `let` keyword:

 // Let's try this again.
 // NOTE: We're using another ES6 keyword, const, for values that won't
 // be reassigned. const and let have similar scoping behavior.
 const adderFunctions = [];
 
 for (let i = 0; i < 1000; i++) {
 // NOTE: We're using the newer arrow function syntax this time, but 
 // using the "function(x) { ..." syntax from the previous example 
 // here would not change the behavior shown.
 adderFunctions[i] = x => x + i;
 }
 
 const add12 = adderFunctions[12];
 
 // Yay! The behavior is as expected. 
 console.log(add12(8) === 20); // => true
 
 // i's scope doesn't extend outside the for loop.
 console.log(i); // => ReferenceError: i is not defined
 

This time, `i` is rebound on each iteration of the `for` loop. Each function now keeps the value of `i` at the time of the function's creation, and `adderFunctions` behaves as expected.

Now, image mixing the two behaviors and you'll probably see why it's not recommended to mix the newer `let` and `const` with the older `var` in the same script. Doing so can result is some spectacularly confusing code.

 const doubleAdderFunctions = [];
 
 for (var i = 0; i < 1000; i++) {
 const j = i;
 doubleAdderFunctions[i] = x => x + i + j;
 }
 
 const add18 = doubleAdderFunctions[9];
 const add24 = doubleAdderFunctions[12];
 
 // It's not fun debugging situations like this, especially when the
 // code is more complex than in this example.
 console.log(add18(24) === 42); // => false
 console.log(add24(18) === 42); // => false
 console.log(add18(24) === add24(18)); // => false
 console.log(add18(24) === 2018); // => false
 console.log(add24(18) === 2018); // => false
 console.log(add18(24) === 1033); // => true
 console.log(add24(18) === 1030); // => true
 

Don't let this happen to you. Use a linter.

> **NOTE:** This is a teaching example intended to demonstrate the `var`/`let` behavior in loops and with function closures that would also be easy to understand. This would be a terrible way to add numbers. But the general technique of capturing data in anonymous function closures might be encountered in the real world in other contexts. YMMV.

The explanation is taken from the article I wrote at [Medium](https://blog.devgenius.io/how-does-hoisting-in-javascript-works-80614300cb98):

> Hoisting is a JavaScript mechanism where variables and function declarations are moved to the top of their scope by the parser which reads the source code into an intermediate representation before the actual code execution starts by the JavaScript interpreter. So, it actually doesn’t matter where variables or functions are declared, they will be moved to the top of their scope regardless of whether their scope is global or local. This means that
> 
>     console.log (hi);     
>     var hi = "say hi";
>     
> 
> is actually interpreted to
> 
>     var hi = undefined;
>     console.log (hi);
>     hi = "say hi";
>     
> 
> So, as we saw just now, `var` variables are being hoisted to the top of their scope and are being initialized with the value of undefined which means that we can actually assign their value before actually declaring them in the code like so:
> 
>     hi = “say hi”
>     console.log (hi); // say hi
>     var hi;
>     
> 
> Regarding function declarations, we can invoke them before actually declaring them like so:
> 
>     sayHi(); // Hi
>     
>     function sayHi() {
>        console.log('Hi');
>     };
>     
> 
> Function expressions, on the other hand, are not hoisted, so we’ll get the following error:
> 
>     sayHi(); //Output: "TypeError: sayHi is not a function
>     
>     var sayHi = function() {
>       console.log('Hi');
>     }; 
>     
> 
> ES6 introduced JavaScript developers the `let` and `const` keywords. While `let` and `const` are block-scoped and not function scoped as `var` it shouldn’t make a difference while discussing their hoisting behavior. We’ll start from the end, JavaScript hoists `let` and `const`.
> 
>     console.log(hi); // Output: Cannot access 'hi' before initialization 
>     let hi = 'Hi';
>     
> 
> As we can see above, `let` doesn’t allow us to use undeclared variables, hence the interpreter explicitly output a reference error indicating that the `hi` variable cannot be accessed before initialization. The same error will occur if we change the above `let` to `const`
> 
>     console.log(hi); // Output: Cannot access 'hi' before initialization
>     const hi = 'Hi';
>     
> 
> So, bottom line, the JavaScript parser searches for variable declarations and functions and hoists them to the top of their scope before code execution and assign values to them in the memory so in case the interpreter will encounter them while executing the code he will recognize them and will be able to execute the code with their assigned values. Variables declared with `let` or `const` remain uninitialized at the beginning of execution while that variables declared with `var` are being initialized with a value of `undefined`.
> 
> I added this visual illustration to better help understanding of how are the hoisted variables and function are being saved in the memory [![在此输入图像描述](https://i.stack.imgur.com/7aRxL.png)](https://i.stack.imgur.com/7aRxL.png)

Function VS block scope:
------------------------

The main difference between `var` and `let` is that variables declared with `var` are **function scoped**. Whereas functions declared with `let` are **block scoped**. For example:

    function testVar () {
      if(true) {
        var foo = 'foo';
      }
    
      console.log(foo);
    }
    
    testVar();  
    // logs 'foo'
    
    
    function testLet () {
      if(true) {
        let bar = 'bar';
      }
    
      console.log(bar);
    }
    
    testLet(); 
    // reference error
    // bar is scoped to the block of the if statement 
    

**variables with `var`:**

When the first function `testVar` gets called the variable foo, declared with `var`, is still accessible outside the `if` statement. This variable `foo` would be available **everywhere** within the scope of the `testVar` **function**.

**variables with `let`:**

When the second function `testLet` gets called the variable bar, declared with `let`, is only accessible inside the `if` statement. Because variables declared with `let` are **block scoped** (where a block is the code between curly brackets e.g `if{}` , `for{}`, `function{}`).

`let` variables don't get hoisted:
----------------------------------

Another difference between `var` and `let` is variables with declared with `let` **don't get hoisted**. An example is the best way to illustrate this behavior:

variables with `let` **don't** get hoisted:

    console.log(letVar);
    
    let letVar = 10;
    // referenceError, the variable doesn't get hoisted
    

variables with `var` **do** get hoisted:

    console.log(varVar);
    
    var varVar = 10;
    // logs undefined, the variable gets hoisted
    

Global `let` doesn't get attached to `window`:
----------------------------------------------

A variable declared with `let` in the global scope (which is code that is not in a function) doesn't get added as a property on the global `window` object. For example (this code is in global scope):

    var bar = 5;
    let foo  = 10;
    
    console.log(bar); // logs 5
    console.log(foo); // logs 10
    
    console.log(window.bar);  
    // logs 5, variable added to window object
    
    console.log(window.foo);
    // logs undefined, variable not added to window object
    

  

> **When should `let` be used over `var`?**

Use `let` over `var` whenever you can because it is simply scoped more specific. This reduces potential naming conflicts which can occur when dealing with a large number of variables. `var` can be used when you want a global variable explicitly to be on the `window` object (always consider carefully if this is really necessary).

It also appears that, at least in Visual Studio 2015, TypeScript 1.5, "var" allows multiple declarations of the same variable name in a block, and "let" doesn't.

This won't generate a compile error:

    var x = 1;
    var x = 2;
    

This will:

    let x = 1;
    let x = 2;

**When Using `let`**

The `let` keyword attaches the variable declaration to the scope of whatever block (commonly a `{ .. }` pair) it's contained in. In other words,`let` implicitly hijacks any block's scope for its variable declaration.

`let` variables cannot be accessed in the `window` object because they cannot be globally accessed.

 function a(){
 { // this is the Max Scope for let variable
 let x = 12;
 }
 console.log(x);
 }
 a(); // Uncaught ReferenceError: x is not defined
 

**When Using `var`**

`var` and variables in ES5 has scopes in functions meaning the variables are valid within the function and not outside the function itself.

`var` variables can be accessed in the `window` object because they cannot be globally accessed.

 function a(){ // this is the Max Scope for var variable
 { 
 var x = 12;
 }
 console.log(x);
 }
 a(); // 12
 

**If you want to know more continue reading below**

one of the most famous interview questions on scope also can suffice the exact use of `let` and `var` as below;

**When using `let`**

 for (let i = 0; i < 10 ; i++) {
 setTimeout(
 function a() {
 console.log(i); //print 0 to 9, that is literally AWW!!!
 }, 
 100 * i);
 }
 

This is because when using `let`, for every loop iteration the variable is scoped and has its own copy.

**When using `var`**

 for (var i = 0; i < 10 ; i++) {
 setTimeout(
 function a() {
 console.log(i); //print 10 times 10
 }, 
 100 * i);
 }
 

This is because when using `var`, for every loop iteration the variable is scoped and has shared copy.

I just came across one use case that I had to use `var` over `let` to introduce new variable. Here's a case:

I want to create a new variable with dynamic variable names.

    let variableName = 'a';
    eval("let " + variableName + '= 10;');
    console.log(a);   // this doesn't work
    

    var variableName = 'a';
    eval("var " + variableName + '= 10;');
    console.log(a);   // this works
    

The above code doesn't work because `eval` introduces a new block of code. The declaration using `var` will declare a variable outside of this block of code since `var` declares a variable in the function scope.

`let`, on the other hand, declares a variable in a block scope. So, `a` variable will only be visible in `eval` block.

Now I think there is better scoping of variables to a block of statements using `let`:

 function printnums()
 {
 // i is not accessible here
 for(let i = 0; i <10; i+=)
 {
 console.log(i);
 }
 // i is not accessible here
 
 // j is accessible here
 for(var j = 0; j <10; j++)
 {
 console.log(j);
 }
 // j is accessible here
 }
 

I think people will start using let here after so that they will have similar scoping in JavaScript like other languages, Java, C#, etc.

People with not a clear understanding about scoping in JavaScript used to make the mistake earlier.

Hoisting is not supported using `let`.

With this approach errors present in JavaScript are getting removed.

Refer to _[ES6 In Depth: let and const](https://hacks.mozilla.org/2015/07/es6-in-depth-let-and-const/)_ to understand it better.

Let 和 var 有什么区别

`use strict`是JavaScript中的一个指令，用于开启严格模式。它于ECMAScript 5引入，主要有以下几个作用：

1. **消除Javascript语法的一些不严谨之处**：严格模式下，一些原本不会报错的编码习惯会抛出错误。例如，给未声明的变量赋值会抛出一个错误。

   ```javascript
   'use strict';
   undeclaredVariable = 1; // ReferenceError: undeclaredVariable is not defined
   ```

2. **消除一些静默错误**：在非严格模式中，一些类型错误会被静默忽略。但在严格模式下，这些错误会被抛出，便于开发者发现并修复。

   ```javascript
   'use strict';
   false.true = '';         // TypeError: Cannot create property 'true' on boolean 'false'
   (14).sailing = 'home';   // TypeError: Cannot create property 'sailing' on number '14'
   ```

3. **提高编译器效率，增加运行速度**：因为严格模式规避了一些语言特性，JavaScript引擎可以更容易地进行代码优化。

4. **禁用了一些语言上容易混淆的特性**：
   - 不能使用`with`语句，因为它会改变作用域并导致优化问题。
   - 为对象的不可写属性赋值，为对象的只读属性赋值，为对象的不可扩展属性添加新属性，为禁止扩展的对象添加新属性，删除不可删除的属性等行为会抛出错误。
   - 函数的参数不能有同名属性，否则也会抛出错误。

   ```javascript
   'use strict';
   function duplicateParam(p, p) { // SyntaxError: Duplicate parameter name not allowed in this context
       return p + p;
   }
   ```

5. **为将来新版本的JavaScript做好准备**：严格模式禁用了一些在未来语言标准中可能会被赋予新意义的语法，从而可以减少向后兼容问题。

如何应用`use strict`：
- 可以应用于整个脚本，只需在脚本顶部添加`'use strict';`。
- 也可以应用于单个函数，将它放在函数体的顶部。

```javascript
function myFunction() {
  'use strict';
  // Function-level strict mode syntax
  var v = "Hi! I'm a strict mode script!";
}
```

使用严格模式有助于提升代码质量和可维护性，并且使得JavaScript代码更加安全。不过，也需要注意在混合使用严格模式和非严格模式代码时可能会遇到的兼容性问题。

This to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don't know or don't trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on returning nulls to indicate something thus requiring the caller to check for nulls.
To put this another way, there are two instances where null checking comes up:
<ol>
<li>Where null is a valid response in terms of the contract; and
</li>
<li>Where it isn't a valid response.
</li>
</ol>
(2) is easy. As of Java 1.7 you can use <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Objects.html#requireNonNull(T)" rel="noreferrer"><code>Objects.requireNonNull(foo)</code></a>. (If you are stuck with a previous version then <a href="https://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html" rel="noreferrer"><code>assert</code>ions</a> may be a good alternative.)
"Proper" usage of this method would be like below. The method returns the object passed into it and throws a <code>NullPointerException</code> if the object is null. This means that the returned value is always non-null. The method is primarily intended for validating parameters.
<pre class="lang-java s-code-block"><code class="hljs language-java">public Foo(Bar bar) {
 this.bar = Objects.requireNonNull(bar);
}
</code></pre>
It can also be used like an <code>assert</code>ion though since it throws an exception if the object is null. In both uses, a message can be added which will be shown in the exception. Below is using it like an assertion and providing a message.
<pre class="lang-java s-code-block"><code class="hljs language-java">Objects.requireNonNull(someobject, "if someobject is null then something is wrong");
someobject.doCalc();
</code></pre>
Generally throwing a specific exception like <code>NullPointerException</code> when a value is null but shouldn't be is favorable to throwing a more general exception like <code>AssertionError</code>. This is the approach the Java library takes; favoring <code>NullPointerException</code> over <code>IllegalArgumentException</code> when an argument is not allowed to be null.
(1) is a little harder. If you have no control over the code you're calling then you're stuck. If null is a valid response, you have to check for it.
If it's code that you do control, however (and this is often the case), then it's a different story. Avoid using nulls as a response. With methods that return collections, it's easy: return empty collections (or arrays) instead of nulls pretty much all the time.
With non-collections it might be harder. Consider this as an example: if you have these interfaces:
<pre class="lang-java s-code-block"><code class="hljs language-java">public interface Action {
 void doSomething();
}

public interface Parser {
 Action findAction(String userInput);
}
</code></pre>
where Parser takes raw user input and finds something to do, perhaps if you're implementing a command line interface for something. Now you might make the contract that it returns null if there's no appropriate action. That leads the null checking you're talking about.
An alternative solution is to never return null and instead use the <a href="https://en.wikipedia.org/wiki/Null_Object_pattern" rel="noreferrer">Null Object pattern</a>:
<pre class="lang-java s-code-block"><code class="hljs language-java">public class MyParser implements Parser {
 private static Action DO_NOTHING = new Action() {
 public void doSomething() { /* do nothing */ }
 };

 public Action findAction(String userInput) {
 // ...
 if ( /* we can't find any actions */ ) {
 return DO_NOTHING;
 }
 }
}
</code></pre>
Compare:
<pre class="lang-java s-code-block"><code class="hljs language-java">Parser parser = ParserFactory.getParser();
if (parser == null) {
 // now what?
 // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
 // do nothing
} else {
 action.doSomething();
}
</code></pre>
to
<pre class="lang-java s-code-block"><code class="hljs language-java">ParserFactory.getParser().findAction(someInput).doSomething();
</code></pre>
which is a much better design because it leads to more concise code.
That said, perhaps it is entirely appropriate for the findAction() method to throw an Exception with a meaningful error message -- especially in this case where you are relying on user input. It would be much better for the findAction method to throw an Exception than for the calling method to blow up with a simple NullPointerException with no explanation.
<pre class="lang-java s-code-block"><code class="hljs language-java">try {
 ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
 userConsole.err(anfe.getMessage());
}
</code></pre>
Or if you think the try/catch mechanism is too ugly, rather than Do Nothing your default action should provide feedback to the user.
<pre class="lang-java s-code-block"><code class="hljs language-java">public Action findAction(final String userInput) {
 /* Code to return requested Action if found */
 return new Action() {
 public void doSomething() {
 userConsole.err("Action not found: " + userInput);
 }
 }
}
</code></pre>

If you use (or planning to use) a Java IDE like <a href="https://www.jetbrains.com/idea/" rel="noreferrer">JetBrains IntelliJ IDEA</a>, <a href="https://www.eclipse.org/" rel="noreferrer">Eclipse</a> or <a href="https://netbeans.org/" rel="noreferrer">Netbeans</a> or a tool like findbugs then you can use annotations to solve this problem.

Basically, you've got <code>@Nullable</code> and <code>@NotNull</code>.

You can use in method and parameters, like this:

<pre class="lang-java s-code-block"><code class="hljs language-java">@NotNull public static String helloWorld() {
 return "Hello World";
}
</code></pre>

or

<pre class="lang-java s-code-block"><code class="hljs language-java">@Nullable public static String helloWorld() {
 return "Hello World";
}
</code></pre>

The second example won't compile (in IntelliJ IDEA).

When you use the first <code>helloWorld()</code> function in another piece of code:

<pre class="lang-java s-code-block"><code class="hljs language-java">public static void main(String[] args)
{
 String result = helloWorld();
 if(result != null) {
 System.out.println(result);
 }
}
</code></pre>

Now the IntelliJ IDEA compiler will tell you that the check is useless, since the <code>helloWorld()</code> function won't return <code>null</code>, ever.

Using parameter

<pre class="lang-java s-code-block"><code class="hljs language-java">void someMethod(@NotNull someParameter) { }
</code></pre>

if you write something like:

<pre class="lang-java s-code-block"><code class="hljs language-java">someMethod(null);
</code></pre>

This won't compile.

Last example using <code>@Nullable</code>

<pre class="lang-java s-code-block"><code class="hljs language-java">@Nullable iWantToDestroyEverything() { return null; }
</code></pre>

Doing this

<pre class="lang-java s-code-block"><code class="hljs language-java">iWantToDestroyEverything().something();
</code></pre>

And you can be sure that this won't happen. :)

It's a nice way to let the compiler check something more than it usually does and to enforce your contracts to be stronger. Unfortunately, it's not supported by all the compilers.

In IntelliJ IDEA 10.5 and on, they added support for any other <code>@Nullable</code> <code>@NotNull</code> implementations.

See blog post <a href="https://blog.jetbrains.com/idea/2011/03/more-flexible-and-configurable-nullublenotnull-annotations/" rel="noreferrer">More flexible and configurable @Nullable/@NotNull annotations</a>.

<h2>If null-values are not allowed</h2>

If your method is called externally, start with something like this:

<pre class="lang-java s-code-block"><code class="hljs language-java">public void method(Object object) {
 if (object == null) {
 throw new IllegalArgumentException("...");
 }
</code></pre>

Then, in the rest of that method, you'll know that <code>object</code> is not null.

If it is an internal method (not part of an API), just document that it cannot be null, and that's it.

Example:

<pre class="lang-java s-code-block"><code class="hljs language-java">public String getFirst3Chars(String text) {
 return text.subString(0, 3);
}
</code></pre>

However, if your method just passes the value on, and the next method passes it on etc. it could get problematic. In that case you may want to check the argument as above.

<h2>If null is allowed</h2>

This really depends. If find that I often do something like this:

<pre class="lang-java s-code-block"><code class="hljs language-java">if (object == null) {
 // something
} else {
 // something else
}
</code></pre>

So I branch, and do two completely different things. There is no ugly code snippet, because I really need to do two different things depending on the data. For example, should I work on the input, or should I calculate a good default value?

<hr>

It's actually rare for me to use the idiom "<code>if (object != null &amp;&amp; ...</code>".

It may be easier to give you examples, if you show examples of where you typically use the idiom.

Wow, I almost hate to add another answer when we have 57 different ways to recommend the <code>NullObject pattern</code>, but I think that some people interested in this question may like to know that there is a proposal on the table for Java 7 to add <a href="http://tech.puredanger.com/java7/#null" rel="noreferrer">"null-safe handling"</a>—a streamlined syntax for if-not-equal-null logic.

The example given by Alex Miller looks like this:

<pre class="lang-java s-code-block"><code class="hljs language-java">public String getPostcode(Person person) { 
 return person?.getAddress()?.getPostcode(); 
} 
</code></pre>

The <code>?.</code> means only de-reference the left identifier if it is not null, otherwise evaluate the remainder of the expression as <code>null</code>. Some people, like Java Posse member Dick Wall and the <a href="http://blog.joda.org/2008/12/jdk-7-language-changes-devoxx-votes_3751.html" rel="noreferrer">voters at Devoxx</a> really love this proposal, but there is opposition too, on the grounds that it will actually encourage more use of <code>null</code> as a sentinel value.

<hr>

Update: An <a href="http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000047.html" rel="noreferrer">official proposal</a> for a null-safe operator in Java 7 has been submitted under <a href="http://openjdk.java.net/projects/coin/" rel="noreferrer">Project Coin.</a> The syntax is a little different than the example above, but it's the same notion.

<hr>

Update: The null-safe operator proposal didn't make it into Project Coin. So, you won't be seeing this syntax in Java 7.

<h2>If undefined values are not permitted:</h2>

You might configure your IDE to warn you about potential null dereferencing. E.g. in Eclipse, see Preferences &gt; Java &gt; Compiler &gt; Errors/Warnings/Null analysis.

<h2>If undefined values are permitted:</h2>

If you want to define a new API where undefined values make sense, use the <a href="http://www.codecommit.com/blog/scala/the-option-pattern" rel="noreferrer">Option Pattern</a> (may be familiar from functional languages). It has the following advantages:

<ul>
<li>It is stated explicitly in the API whether an input or output exists or not.</li>
<li>The compiler forces you to handle the "undefined" case.</li>
<li><a href="http://james-iry.blogspot.com/2007/08/martians-vs-monads-null-considered.html" rel="noreferrer">Option is a monad</a>, so there is no need for verbose null checking, just use map/foreach/getOrElse or a similar combinator to safely use the value <a href="http://blog.tackley.net/2010/09/option-in-scala-vs-null-in-java.html" rel="noreferrer">(example)</a>.</li>
</ul>

Java 8 has a built-in <a href="http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html" rel="noreferrer"><code>Optional</code></a> class (recommended); for earlier versions, there are library alternatives, for example <a href="http://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained" rel="noreferrer">Guava</a>'s <a href="https://google.github.io/guava/releases/19.0/api/docs/com/google/common/base/Optional.html" rel="noreferrer"><code>Optional</code></a> or <a href="http://code.google.com/p/functionaljava" rel="noreferrer">FunctionalJava</a>'s <a href="http://www.functionaljava.org/javadoc/4.4/functionaljava/fj/data/Option.html" rel="noreferrer"><code>Option</code></a>. But like many functional-style patterns, using Option in Java (even 8) results in quite some boilerplate, which you can reduce using a less verbose JVM language, e.g. Scala or Xtend.

If you have to deal with an API which might return nulls, you can't do much in Java. Xtend and Groovy have the <a href="https://www.eclipse.org/xtend/documentation.html#operators" rel="noreferrer">Elvis operator</a> <code>?:</code> and the <a href="https://www.eclipse.org/xtend/documentation.html#nullSafeFeatureCalls" rel="noreferrer">null-safe dereference operator</a> <code>?.</code>, but note that this returns null in case of a null reference, so it just "defers" the proper handling of null.

Only for this situation -

Not checking if a variable is null before invoking an equals method (a string compare example below):

<pre class="lang-java s-code-block"><code class="hljs language-java">if ( foo.equals("bar") ) {
 // ...
}
</code></pre>

will result in a <code>NullPointerException</code> if <code>foo</code> doesn't exist.

You can avoid that if you compare your <code>String</code>s like this:

<pre class="lang-java s-code-block"><code class="hljs language-java">if ( "bar".equals(foo) ) {
 // ...
}
</code></pre>

Java 8 introduced the <a href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html" rel="nofollow noreferrer"><code>java.util.Optional</code></a> class that addresses some of the problem. One can at least say that it improves the readability of the code, and in the case of public APIs make the contract clearer to the client developer.
They work as follows:
An optional object for a given type (<code>Fruit</code>) is created as the return type of a method. It can be empty or contain a <code>Fruit</code> object:
<pre class="lang-java s-code-block"><code class="hljs language-java">public static Optional&lt;Fruit&gt; find(String name, List&lt;Fruit&gt; fruits) {
 for (Fruit fruit : fruits) {
 if (fruit.getName().equals(name)) {
 return Optional.of(fruit);
 }
 }
 return Optional.empty();
}
</code></pre>
Now look at this code where we search a list of <code>Fruit</code> (<code>fruits</code>) for a given Fruit instance:
<pre class="lang-java s-code-block"><code class="hljs language-java">Optional&lt;Fruit&gt; found = find("lemon", fruits);
if (found.isPresent()) {
 Fruit fruit = found.get(); // Prefer found.orElseThrow() in Java 9+
 String name = fruit.getName();
}
</code></pre>
You can use the <a href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html#map(java.util.function.Function)" rel="nofollow noreferrer"><code>map</code></a> method to perform a computation on — or extract a value from —&nbsp;an optional object. The <a href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html#orElse(T)" rel="nofollow noreferrer"><code>orElse</code></a> method lets you provide a fallback for missing values, converting an <code>Optional</code> to a non-nullable value.
<pre class="lang-java s-code-block"><code class="hljs language-java">String nameOrFallback = find("lemon", fruits)
 .map(f -&gt; f.getName())
 .orElse("empty-name");
</code></pre>
Of course, handling the null/empty value is still necessary, but at least the developer is conscious that the value might be empty and the risk of forgetting to check is limited.
In an API built from scratch using <code>Optional</code> whenever a return value might be empty, and returning a plain object only when it cannot be <code>null</code> (convention), the client code might abandon null checks on simple object return values.
Of course <code>Optional</code> could also be used as a method argument, perhaps a better way to indicate optional arguments than 5 or 10 overloading methods in some cases. Be aware that using it in this manner is <a href="https://stackoverflow.com/a/26328555/1108305">recommended against</a> by Java Language Architect Brian Goetz: "You should almost never use <code>Optional</code> as […] a method parameter."
<code>Optional</code> offers other convenient methods, such as <a href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html#orElseGet(java.util.function.Supplier)" rel="nofollow noreferrer"><code>orElseGet</code></a> that calculates a default value only if the <code>Optional</code> is empty, and <a href="https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Optional.html#ifPresent(java.util.function.Consumer)" rel="nofollow noreferrer"><code>ifPresent</code></a> that peforms an operation only if the <code>Optional</code> is non-empty, both of which work with <a href="https://en.wikipedia.org/wiki/Anonymous_function" rel="nofollow noreferrer">lambda expressions</a>.
I invite you to read this article (the main source for writing this answer) in which the problematic behavior of <code>NullPointerException</code> (and in general null pointer) and the (partial) solution brought by <code>Optional</code> are well explained: <a href="http://java.dzone.com/articles/java-optional-objects" rel="nofollow noreferrer">Java Optional Objects</a>.

Depending on what kind of objects you are checking you may be able to use some of the classes in the apache commons such as: <a href="http://commons.apache.org/lang/" rel="noreferrer">apache commons lang</a> and <a href="http://commons.apache.org/collections/" rel="noreferrer">apache commons collections</a>

Example: 

<pre class="lang-java s-code-block"><code class="hljs language-java">String foo;
...
if( StringUtils.isBlank( foo ) ) {
 ///do something
}
</code></pre>

or (depending on what you need to check):

<pre class="lang-java s-code-block"><code class="hljs language-java">String foo;
...
if( StringUtils.isEmpty( foo ) ) {
 ///do something
}
</code></pre>

The StringUtils class is only one of many; there are quite a few good classes in the commons that do null safe manipulation.

Here follows an example of how you can use null vallidation in JAVA when you include apache library(commons-lang-2.4.jar)

<pre class="lang-java s-code-block"><code class="hljs language-java">public DOCUMENT read(String xml, ValidationEventHandler validationEventHandler) {
 Validate.notNull(validationEventHandler,"ValidationHandler not Injected");
 return read(new StringReader(xml), true, validationEventHandler);
}
</code></pre>

And if you are using Spring, Spring also has the same functionality in its package, see library(spring-2.4.6.jar) 

Example on how to use this static classf from spring(org.springframework.util.Assert)

<pre class="lang-java s-code-block"><code class="hljs language-java">Assert.notNull(validationEventHandler,"ValidationHandler not Injected");
</code></pre>

<ul>
<li>If you consider an object should not be null (or it is a bug) use an assert.</li>
<li>If your method doesn't accept null params say it in the javadoc and use an assert.</li>
</ul>

You have to check for object != null only if you want to handle the case where the object may be null...

There is a proposal to add new annotations in Java7 to help with null / notnull params:
<a href="http://tech.puredanger.com/java7/#jsr308" rel="noreferrer">http://tech.puredanger.com/java7/#jsr308</a>

I'm a fan of "fail fast" code. Ask yourself - are you doing something useful in the case where the parameter is null? If you don't have a clear answer for what your code should do in that case... i.e. - it should never be null in the first place, then ignore it and allow a <code>NullPointerException</code> to be thrown. The calling code will make just as much sense of an NPE as it would an <code>IllegalArgumentException</code>, but it'll be easier for the developer to debug and understand what went wrong if an NPE is thrown rather than your code attempting to execute some other unexpected contingency logic - which ultimately results in the application failing anyway.

In Java 1.7 or later, the standard way to do this is as follows:

<pre class="lang-java s-code-block"><code class="hljs language-java">import java.util.concurrent.ThreadLocalRandom;

// nextInt is normally exclusive of the top value,
// so add 1 to make it inclusive
int randomNum = ThreadLocalRandom.current().nextInt(min, max + 1);
</code></pre>

See <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ThreadLocalRandom.html#nextInt(int,int)" rel="noreferrer">the relevant JavaDoc</a>. This approach has the advantage of not needing to explicitly initialize a <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html" rel="noreferrer">java.util.Random</a> instance, which can be a source of confusion and error if used inappropriately.

However, conversely there is no way to explicitly set the seed so it can be difficult to reproduce results in situations where that is useful such as testing or saving game states or similar. In those situations, the pre-Java 1.7 technique shown below can be used.

Before Java 1.7, the standard way to do this is as follows:

<pre class="lang-java s-code-block"><code class="hljs language-java">import java.util.Random;

/**
 * Returns a pseudo-random number between min and max, inclusive.
 * The difference between min and max can be at most
 * &lt;code&gt;Integer.MAX_VALUE - 1&lt;/code&gt;.
 *
 * @param min Minimum value
 * @param max Maximum value. Must be greater than min.
 * @return Integer between min and max, inclusive.
 * @see java.util.Random#nextInt(int)
 */
public static int randInt(int min, int max) {

 // NOTE: This will (intentionally) not run as written so that folks
 // copy-pasting have to think about how to initialize their
 // Random instance. Initialization of the Random instance is outside
 // the main scope of the question, but some decent options are to have
 // a field that is initialized once and then re-used as needed or to
 // use ThreadLocalRandom (if using at least Java 1.7).
 // 
 // In particular, do NOT do 'Random rand = new Random()' here or you
 // will get not very good / not very random results.
 Random rand;

 // nextInt is normally exclusive of the top value,
 // so add 1 to make it inclusive
 int randomNum = rand.nextInt((max - min) + 1) + min;

 return randomNum;
}
</code></pre>

See <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html#nextInt(int)" rel="noreferrer">the relevant JavaDoc</a>. In practice, the <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Random.html" rel="noreferrer">java.util.Random</a> class is often preferable to <a href="https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Math.html#random()" rel="noreferrer">java.lang.Math.random()</a>.

In particular, there is no need to reinvent the random integer generation wheel when there is a straightforward API within the standard library to accomplish the task.

Note that this approach is more biased and less efficient than a <code>nextInt</code> approach, <a href="https://stackoverflow.com/a/738651/360211">https://stackoverflow.com/a/738651/360211</a>

One standard pattern for accomplishing this is:

<pre class="lang-java s-code-block"><code class="hljs language-java">Min + (int)(Math.random() * ((Max - Min) + 1))
</code></pre>

The <a href="http://en.wikipedia.org/wiki/Java_%28programming_language%29" rel="noreferrer">Java</a> Math library function Math.random() generates a double value in the range <code>[0,1)</code>. Notice this range does not include the 1.

In order to get a specific range of values first, you need to multiply by the magnitude of the range of values you want covered. 

<pre class="lang-java s-code-block"><code class="hljs language-java">Math.random() * ( Max - Min )
</code></pre>

This returns a value in the range <code>[0,Max-Min)</code>, where 'Max-Min' is not included.

For example, if you want <code>[5,10)</code>, you need to cover five integer values so you use

<pre class="lang-java s-code-block"><code class="hljs language-java">Math.random() * 5
</code></pre>

This would return a value in the range <code>[0,5)</code>, where 5 is not included.

Now you need to shift this range up to the range that you are targeting. You do this by adding the Min value.

<pre class="lang-java s-code-block"><code class="hljs language-java">Min + (Math.random() * (Max - Min))
</code></pre>

You now will get a value in the range <code>[Min,Max)</code>. Following our example, that means <code>[5,10)</code>:

<pre class="lang-java s-code-block"><code class="hljs language-java">5 + (Math.random() * (10 - 5))
</code></pre>

But, this still doesn't include <code>Max</code> and you are getting a double value. In order to get the <code>Max</code> value included, you need to add 1 to your range parameter <code>(Max - Min)</code> and then truncate the decimal part by casting to an int. This is accomplished via:

<pre class="lang-java s-code-block"><code class="hljs language-java">Min + (int)(Math.random() * ((Max - Min) + 1))
</code></pre>

And there you have it. A random integer value in the range <code>[Min,Max]</code>, or per the example <code>[5,10]</code>:

<pre class="lang-java s-code-block"><code class="hljs language-java">5 + (int)(Math.random() * ((10 - 5) + 1))
</code></pre>

Use:

<pre class="lang-java s-code-block"><code class="hljs language-java">Random ran = new Random();
int x = ran.nextInt(6) + 5;
</code></pre>

The integer <code>x</code> is now the random number that has a possible outcome of <code>5-10</code>.

Use:
<pre class="lang-java s-code-block"><code class="hljs language-java">minValue + rn.nextInt(maxValue - minValue + 1)
</code></pre>

With <a href="https://www.oracle.com/java/technologies/java8.html" rel="noreferrer">Java 8</a> they introduced the method <a href="http://docs.oracle.com/javase/8/docs/api/java/util/Random.html#ints-int-int-" rel="noreferrer"><code>ints(int randomNumberOrigin, int randomNumberBound)</code></a> in the <a href="http://docs.oracle.com/javase/8/docs/api/java/util/Random.html" rel="noreferrer"><code>Random</code></a> class.
For example if you want to generate five random integers (or a single one) in the range [0, 10], just do:
<pre class="lang-java s-code-block"><code class="hljs language-java">Random r = new Random();
int[] fiveRandomNumbers = r.ints(5, 0, 11).toArray();
int randomNumber = r.ints(1, 0, 11).findFirst().getAsInt();
</code></pre>
The first parameter indicates just the size of the <code>IntStream</code> generated (which is the overloaded method of the one that produces an unlimited <code>IntStream</code>).
If you need to do multiple separate calls, you can create an infinite primitive iterator from the stream:
<pre class="lang-java s-code-block"><code class="hljs language-java">public final class IntRandomNumberGenerator {

 private PrimitiveIterator.OfInt randomIterator;

 /**
 * Initialize a new random number generator that generates
 * random numbers in the range [min, max]
 * @param min - the min value (inclusive)
 * @param max - the max value (inclusive)
 */
 public IntRandomNumberGenerator(int min, int max) {
 randomIterator = new Random().ints(min, max + 1).iterator();
 }

 /**
 * Returns a random number in the range (min, max)
 * @return a random number in the range (min, max)
 */
 public int nextInt() {
 return randomIterator.nextInt();
 }
}
</code></pre>
You can also do it for <code>double</code> and <code>long</code> values.

You can edit your second code example to:

<pre class="lang-java s-code-block"><code class="hljs language-java">Random rn = new Random();
int range = maximum - minimum + 1;
int randomNum = rn.nextInt(range) + minimum;
</code></pre>

Just a small modification of your first solution would suffice.

<pre class="lang-java s-code-block"><code class="hljs language-java">Random rand = new Random();
randomNum = minimum + rand.nextInt((maximum - minimum) + 1);
</code></pre>

<hr>

See more here for implementation of <a href="https://insight.io/github.com/lambdalab-mirror/jdk8u-jdk/blob/master/src/share/classes/java/util/Random.java?line=77" rel="noreferrer"><code>Random</code></a>

<code>ThreadLocalRandom</code> equivalent of class <code>java.util.Random</code> for multithreaded environment. Generating a random number is carried out locally in each of the threads. So we have a better performance by reducing the conflicts. 

<pre class="lang-java s-code-block"><code class="hljs language-java">int rand = ThreadLocalRandom.current().nextInt(x,y);
</code></pre>

<code>x</code>,<code>y</code> - intervals e.g. (1,10)

The <code>Math.Random</code> class in <a href="http://en.wikipedia.org/wiki/Java_%28programming_language%29" rel="noreferrer">Java</a> is 0-based. So, if you write something like this: 

<pre class="lang-java s-code-block"><code class="hljs language-java">Random rand = new Random();
int x = rand.nextInt(10);
</code></pre>

<code>x</code> will be between <code>0-9</code> inclusive.

So, given the following array of <code>25</code> items, the code to generate a random number between <code>0</code> (the base of the array) and <code>array.length</code> would be:

<pre class="lang-java s-code-block"><code class="hljs language-java">String[] i = new String[25];
Random rand = new Random();
int index = 0;

index = rand.nextInt( i.length );
</code></pre>

Since <code>i.length</code> will return <code>25</code>, the <code>nextInt( i.length )</code> will return a number between the range of <code>0-24</code>. The other option is going with <code>Math.Random</code> which works in the same way.

<pre class="lang-java s-code-block"><code class="hljs language-java">index = (int) Math.floor(Math.random() * i.length);
</code></pre>

For a better understanding, check out forum post <a href="http://web.archive.org/web/20070308142422/http://www.kirupa.com/forum/showthread.php?s=&amp;postid=81565" rel="noreferrer">Random Intervals (archive.org)</a>.

It can be done by simply doing the statement:
<pre class="lang-java s-code-block"><code class="hljs language-java">Randomizer.generate(0, 10); // Minimum of zero and maximum of ten
</code></pre>
Below is its source code.
<h3>File Randomizer.java</h3>
<pre class="lang-java s-code-block"><code class="hljs language-java">public class Randomizer {
 public static int generate(int min, int max) {
 return min + (int)(Math.random() * ((max - min) + 1));
 }
}
</code></pre>
It is just clean and simple.

in your terminal type
<pre><code>cd /
</code></pre>
then use this command:
<pre><code>du -h --max-depth=1
</code></pre>
it will take some time, but you will get folder list with sizes
<a href="https://i.sstatic.net/i850f.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/i850f.jpg" alt="enter image description here"></a>
as explained in details here:
<a href="https://floyk.com/en/post/how-to-find-which-folders-are-taking-the-disk-space-by-using-terminal-on-linux" rel="nofollow noreferrer">https://floyk.com/en/post/how-to-find-which-folders-are-taking-the-disk-space-by-using-terminal-on-linux</a>

It could be coming from Jenkins, Docker or any other process. To solve that, you should <a href="https://puvox.software/blog/solution-clean-full-disk-space-by-dev-vda1/" rel="nofollow noreferrer">clean logs and set it's size</a>.

From the above output of 'df -h' the disk space is used by some file or folders in '/' location. As you are able to SSH in to the server follow the below steps and that will show the files that are using more space.

<ul>
<li>cd /</li>
<li>ls -lSr | tail -10</li>
</ul>

The first command [cd space slash] will direct you to the '/' folder and second command will list files based on its size. Please post the output of the above command. This will show the files that are using more space on the current directory. Once you can find this you will be able to remove the unused files (if any). Or you can contact the hosting provider to mount another harddisk space to '/' to migrate those files and free more space.

<pre class="lang-js s-code-block"><code class="hljs language-javascript">const usernameChangeHandler = async (event) =&gt; {
 await setEnteredUsername(event.target.value);
 console.log(enteredUsername, enteredAge); 
};
</code></pre>
<code>enteredUsername</code> is never going to change. It's a closure variable that's local to this single time you rendered the component. It's usually a <code>const</code>, but even if it was made with <code>let</code>, <code>setEnteredUsername</code> does not even attempt to change its value. What <code>setEnteredUsername</code> does is ask react to rerender the component. When the render eventually happens, a new local variable will be created with the new value, but code from your old render has no access to that.
If you need to run some code after calling <code>setEnteredUsername</code>, but you don't actually care if the component has rerendered yet, the just use the value in <code>event.target.value</code>, since you know that's going to be the new value of the state:
<pre class="lang-js s-code-block"><code class="hljs language-javascript">const usernameChangeHandler = (event) =&gt; {
 setEnteredUsername(event.target.value);
 console.log(event.target.value, enteredAge);
}
</code></pre>
If instead you need to make make sure that the component has rerendered and then do something after that, you can put your code in a useEffect. Effects run after rendering, and you can use the dependency array to make it only run if the values you care about have changed:
<pre class="lang-js s-code-block"><code class="hljs language-javascript">const [enteredUsername, setEnteredUsername] = useState('');

useEffect(() =&gt; {
 console.log('rendering complete, with new username', enteredUsername);
}, [enteredUsername]);

const usernameChangeHandler = (event) =&gt; {
 setEnteredUsername(event.target.value);
};
</code></pre>

the act of setting state is asynchronous; therefore, console logging directly after setting your state will not accurately provide you with how state currently looks. Instead as many have suggested you can utilize the useEffect lifecycle hook to listen for changes in your enteredUserName state like so:
<pre class="lang-js s-code-block"><code class="hljs language-javascript">useEffect(() =&gt; {
 console.log(enteredUsername);
}, [enteredUsername]);
</code></pre>
listening for changes within the useEffect will allow you to create side effects once state has updated and caused your component to rerender. This in turn will trigger your useEffect with the enteredUsername dependency, as the enteredUserName state has changed.

It's not documented (at time of asking), but NPM can filter workspace commands to subdirectories of workspaces by giving the <code>--workspace</code> flag a path as its value. For example:
<pre><code>npm run --workspace packages/presets --workspace packages/plugins build
</code></pre>
This will find workspaces that are directly in <code>$project_root/packages/presets/</code> or <code>$project_root/packages/plugins/</code>, but not workspaces in subdirectories of these subdirectories.
Deeper-nested subdirectories can be included using <code>/**</code>, like:
<pre><code>npm run --workspace packages/** build
</code></pre>
<hr>
The above examples would work with workspaces organised into subdirectories, defined in package.json like:
<pre><code> "workspaces": [
 "packages/plugins/*",
 "packages/presets/*",
 ...more
 ],
</code></pre>
...or a catch-all like:
<pre><code> "workspaces": [
 "packages/**",
 ...more
 ],
</code></pre>
<hr>
While pointing <code>--workspace</code> to subdirectories of workspaces instead of individual workspaces like this doesn't seem to be documented anywhere at time of writing, it does appear to be an intentional, planned, supported feature. I found a note proposing it <a href="https://github.com/npm/rfcs/pull/117" rel="noreferrer">deep in one of the rfcs</a>:
<blockquote>
Note: Globs are not supported as a valid --workspace argument value, the proposed alternative is to use npm --workspace= in which is a folder containing multiple workspaces.
</blockquote>
I couldn't find anything explicitly stating that this proposal was implemented, but I tried reorganising my monorepo into subdirectories and using a subdirectory with the <code>--workspace</code> flag, and it worked.
Their reason for choosing paths rather than glob patterns in workspace names (like yarn does and lerna did) appears to be because of the:
<blockquote>
many pitfalls of supporting globs in the variety of supported shells and operational systems
</blockquote>

<a href="https://stackoverflow.com/a/71350662/3404438">This answer</a> is very complete. Just a couple of tweaks that worked for me:
I needed to use the npm command/script before the --workspace flag, and I did not needed to use the <code>/**</code> at the end.
<pre><code>npm run &lt;script-name&gt; --workspace parent/directory/
</code></pre>
Examples:
<pre><code>npm publish --workspace packages/public/
npm run build --workspace packages/helpers/
</code></pre>
This is documented in other parts of npm so it took a bit of digging. The information is generally the same in all places, because the <code>--workspace</code> flag is a configuration for multiple npm commands:
<pre><code>Valid values for the workspace config are either:

Workspace names
Path to a workspace directory
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
</code></pre>
I found it documented <a href="https://docs.npmjs.com/cli/v8/using-npm/config#workspace" rel="nofollow noreferrer">here</a> and <a href="https://docs.npmjs.com/cli/v8/commands/npm-publish#workspace" rel="nofollow noreferrer">here</a>.
Unfortunately there does not seem to be a way to use globs. Only way to group things would be by parent directory.
Disclaimer: I was going to add a comment to <a href="https://stackoverflow.com/a/71350662/3404438">this answer</a> but it was becoming too long and details might have been missed. I think that is the right answer.

所有问题

JS 如何验证电子邮件地址

JS 如何使字符串的第一个字母变成大写？

JS 中应该使用哪个等于运算符 == 和 === ？

Let 和 var 有什么区别

JS 中 use strict 的作用是什么？