Operatorul de egalitate strictă (===) se comportă identic cu operatorul de egalitate abstract (==), cu excepția faptului că nu se face nicio conversie de tip, iar tipurile trebuie să fie aceleași pentru a fi considerate egale.

Referință: Tutorial Javascript: Operatori de comparație

Operatorul == va compara pentru egalitate după ce face orice conversie de tip necesară. Operatorul === nu va efectua conversia, deci, dacă două valori nu sunt de același tip, === va returna pur și simplu false. Ambele sunt la fel de rapide.

Pentru a cita excelentul JavaScript: The Good Parts al lui Douglas Crockford,

JavaScript are două seturi de operatori de egalitate: === și !== și gemenii lor malefici == și !=. Cei buni funcționează așa cum v-ați aștepta. Dacă cei doi operanzi sunt de același tip și au aceeași valoare, atunci === produce true și !== produce false. Gemenii răi fac ceea ce trebuie atunci când operanzii sunt de același tip, dar dacă sunt de tipuri diferite, încearcă să constrângă valorile. regulile după care fac acestea sunt complicate și de nememorat. Acestea sunt câteva dintre cazurile interesante:

'' == '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

Lipsa tranzitivității este alarmantă. Sfatul meu este să nu folosiți niciodată gemenii răi. În schimb, folosiți întotdeauna === și !==. Toate comparațiile tocmai arătate produc false cu operatorul ===.

Actualizați:

Un punct bun a fost adus în discuție de @Casebash în comentarii și în @Phillipe Laybaert răspunsul referitor la obiecte. Pentru obiecte, == și === acționează în mod consecvent unul cu celălalt (cu excepția unui caz special).

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

Cazul special este atunci când comparați o primitivă cu un obiect care evaluează la aceeași primitivă, datorită metodei sale toString sau valueOf. De exemplu, luați în considerare compararea unei primitive șir cu un obiect șir creat folosind constructorul String.

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

Aici operatorul == verifică valorile celor două obiecte și returnează true, dar === vede că nu sunt de același tip și returnează false. Care este corect? Asta chiar depinde de ceea ce încerci să compari. Sfatul meu este să ocoliți complet întrebarea și pur și simplu să nu folosiți constructorul String pentru a crea obiecte șir din literale șir.

Referință
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3

Folosind operatorul == (Egalitatea)

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

Folosind operatorul === (Identitate)

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

Acest lucru se datorează faptului că operatorul de egalitate == tip coerciție, ceea ce înseamnă că interpretul încearcă implicit să convertească valorile înainte de a compara.

Pe de altă parte, operatorul de identitate === nu face coerciție de tip și, prin urmare, nu convertește valorile la comparare și, prin urmare, este mai rapid (așa cum se arată în Acest test de referință JS), deoarece omite un pas.

O reprezentare picturală interesantă a comparației de egalitate între == și ===.

Sursa: http://dorey.github.io/JavaScript-Equality-Table/

var1 === var2

Când utilizați === pentru testarea egalității JavaScript, totul este așa cum este. Nimic nu este convertit înainte de a fi evaluat.

var1 == var2

Când utilizați == pentru testarea egalității JavaScript, au loc unele conversii ciudate.

Concluzie:

Folosiți întotdeauna ===.

^{(Dacă nu înțelegeți pe deplin conversiile care au loc cu ==.)}

În răspunsurile de aici, nu am citit nimic despre ce înseamnă egal. Unii vor spune că === înseamnă egal și de același tip, dar nu este chiar adevărat. De fapt înseamnă că ambele operanzi fac referire la același obiect sau, în cazul tipurilor de valori, au aceeași valoare.

Deci, să luăm următorul cod:

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

La fel aici:

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

Sau chiar:

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

Acest comportament nu este întotdeauna evident. Există mai mult în poveste decât a fi egal și a fi de același tip.

Regula este:

Pentru tipurile de valori (numere):
a === b returnează adevărat dacă a și b au aceeași valoare și sunt de același tip

Pentru tipurile de referință:
a === b returnează adevărat dacă a și b fac referire exact la același obiect

Pentru șiruri:
a === b returnează adevărat dacă a și b sunt ambele șiruri și conțin exact aceleași caractere

Corzi: cazul special...

Șirurile nu sunt tipuri de valoare, dar în Javascript se comportă ca tipuri de valoare, deci vor fi egale atunci când caracterele din șir sunt aceleași și când au aceeași lungime (după cum este explicat în a treia regulă)

Acum devine interesant:

var a = "12" + "3";
var b = "123";

alert(a === b); // returns true, because strings behave like value types

Dar ce zici de asta?:

var a = new String("123");
var b = "123";

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

Am crezut că șirurile se comportă ca tipuri de valori? Ei bine, depinde pe cine întrebi... În acest caz a și b nu sunt de același tip. a este de tip Object, în timp ce b este de tip string. Nu uitați doar că crearea unui obiect șir folosind constructorul String creează ceva de tip Object care se comportă ca un șir de cele mai multe ori.

Permiteți-mi să adaug acest sfat:

Dacă aveți îndoieli, citiți specificația !

ECMA-262 este specificația pentru un limbaj de scripting din care JavaScript este un dialect. Desigur, în practică contează mai mult modul în care se comportă cele mai importante browsere decât o definiție ezoterică a modului în care ar trebui să fie tratat ceva. Dar este util să înțelegeți de ce noul String(a) !== a.

Vă rog să vă explic cum să citesc specificația pentru a clarifica această întrebare. Văd că în acest subiect foarte vechi nimeni nu a avut un răspuns pentru efectul foarte ciudat. Deci, dacă poți citi o specificație, aceasta te va ajuta enorm în profesia ta. Este o abilitate dobândită. Deci, hai să continuăm.

Căutarea === în fișierul PDF mă duce la pagina 56 a specificației: 11.9.4. Operatorul Strict Equals ( === )și, după ce am parcurs specificațiile, găsesc:

11.9.6 Algoritmul strict de comparare a egalității
Comparația x === y, unde x și y sunt valori, produce adevărat sau fals >. O astfel de comparație se efectuează după cum urmează:
  1. Dacă Tipul(x) este diferit de Tipul(y), returnați fals.
  2. Dacă Tipul(x) este Nedefinit, returnați adevărat.
  3. Dacă Tipul(x) este Null, returnați adevărat.
  4. Dacă Tipul(x) nu este Număr, treceți la pasul 11 .
  5. Dacă x este NaN, returnați fals.
  6. Dacă y este NaN, returnați false .
  7. Dacă x este aceeași valoare numerică cu y, returnează adevărat.
  8. Dacă x este +0 și y este −0, returnează adevărat.
  9. Dacă x este −0 și y este +0, returnează adevărat.
  10. Returnează fals.
11. Dacă Type(x) este String, atunci returnează true dacă x și y sunt exact aceeași secvență de caractere (aceeași lungime și aceleași caractere în pozițiile corespunzătoare); în caz contrar, returnați fals.
  12. Dacă Tipul(x) este boolean, returnați adevărat dacă x și y sunt ambele adevărate sau ambele fals; în caz contrar, returnați fals.
  13. Returnați adevărat dacă x și y se referă la același obiect sau dacă se referă la obiecte unite între ele (vezi 13.1.2 ). În caz contrar, returnați false.

Interesant este pasul 11. Da, șirurile sunt tratate ca tipuri de valori. Dar acest lucru nu explică de ce noul String(a) !== a. Avem un browser care nu este conform cu ECMA-262?

Nu asa de repede!

Să verificăm tipurile de operanzi. Încercați-l singur, împachetându-le în typeof(). Găsesc că new String(a) este un obiect și se folosește pasul 1: returnează false dacă tipurile sunt diferite.

Dacă vă întrebați de ce new String(a) nu returnează un șir, ce zici de un exercițiu de citire a unei specificații? A se distra!

Aidiakapi a scris asta într-un comentariu de mai jos:

Din caietul de sarcini

11.2.2 Noul operator:

Dacă Type(constructor) nu este Object, aruncați o excepție TypeError.

Cu alte cuvinte, dacă String nu ar fi de tip Object, nu ar putea fi folosit cu noul operator.

new returnează întotdeauna un Object, chiar și pentru constructorii String. Și vai! Semantica valorii pentru șiruri (vezi pasul 11) este pierdută.

Și asta înseamnă în cele din urmă: New String(a) !== a.

Am testat acest lucru în Firefox cu Firebug folosind cod ca acesta:

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

și

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

Rezultatele mele (testate de cinci ori fiecare și mediate):

==: 115.2
===: 114.4

Deci, aș spune că diferența minusculă (aceasta este de peste 100.000 de iterații, amintiți-vă) este neglijabilă. Performanța nu este un motiv pentru a face ===. Tastați siguranță (ei bine, pe cât de sigur veți obține în JavaScript), iar calitatea codului este.

În PHP și JavaScript, este un operator de egalitate strict. Ceea ce înseamnă că va compara atât tipul, cât și valorile.

În JavaScript înseamnă aceeași valoare și tip.

De exemplu,

4 == "4" // will return true

dar

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

Operatorul === este numit operator de comparație strictă, difer de operatorul ==.

Să luăm 2 vars a și b.

Pentru ca „a == b” să se evalueze la a și b adevărat trebuie să fie aceeași valoare.

În cazul „a === b” a și b trebuie să fie aceeași valoare și, de asemenea, același tip pentru ca acesta să fie evaluat la Adevărat.

Luați următorul exemplu

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");
}

În rezumat; utilizarea operatorului == ar putea fi evaluată drept adevărat în situațiile în care nu doriți, astfel încât utilizarea operatorului === ar fi mai sigură.

În scenariul de utilizare de 90%, nu va conta pe care îl folosiți, dar este la îndemână să știți diferența atunci când aveți un comportament neașteptat într-o zi.

De ce == este atât de imprevizibil?

Ce obții când compari un șir gol "" cu numărul zero 0?

true

Da, așa este conform == un șir gol și numărul zero sunt același timp.

Și nu se termină aici, iată încă una:

'0' == false // true

Lucrurile devin foarte ciudate cu matrice.

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

Apoi mai ciudat cu șiruri

[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!

Devine mai rău:

Când este egal nu este egal?

let A = ''  // empty string
let B = 0   // zero
let C = '0' // zero string

A == B // true - ok... 
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!

Lasă-mă să spun asta din nou:

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

Și acestea sunt doar chestiile nebunești pe care le primești cu primitivii.

Este un nivel cu totul nou de nebunie când folosești == cu obiecte.

În acest moment, probabil vă întrebați...

De ce se întâmplă acest lucru?

Ei bine, pentru că, spre deosebire de „triplu egal” (===), care doar verifică dacă două valori sunt aceleași.

== face multe alte chestii.

Are o manipulare specială pentru funcții, o gestionare specială pentru valorile nule, nedefinite, șiruri de caractere, cum ar fi.

Devine destul de ciudat.

De fapt, dacă ați încerca să scrieți o funcție care face ceea ce face ==, ar arăta cam așa:

function isEqual(x, y) { // if `==` were a function
    if(typeof y === typeof x) return y === x;
    // treat null and undefined the same
    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 either value is a string 
        // convert the function into a string and compare
        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;

    // convert x and y into numbers if they are not already use the "+" trick
    if(typeof x !== "number") x = +x;
    if(typeof y !== "number") y = +y;
    // actually the real `==` is even more complicated than this, especially in ES6
    return x === y;
}

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

Deci, ce înseamnă asta?

Înseamnă că == este complicat.

Pentru că este complicat, este greu să știi ce se va întâmpla când îl vei folosi.

Ceea ce înseamnă că ai putea ajunge cu bug-uri.

Deci morala poveștii este...

Faceți-vă viața mai puțin complicată.

Folosiți === în loc de ==.

Sfârșitul.

=== verifică că aceleași părți sunt egale în tip, precum și în valoare.

Exemplu:

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

Exemplu comun:

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

Un alt exemplu comun:

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

De multe ori o verificare netipată ar fi utilă, deoarece nu vă pasă dacă valoarea este fie undefined, null, 0 sau ""

Diagrama fluxului de execuție Javascript pentru egalitate strictă / Comparație '==='

Diagrama fluxului de execuție Javascript pentru egalitate/comparație non strictă „==”

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

Înseamnă constrângere de tip egalitate fără constrângere de tip înseamnă că JavaScript nu convertește automat alte tipuri de date în tipuri de date șir

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 

Într-un script tipic nu va exista nicio diferență de performanță. Mai important poate fi faptul că o mie de „===" este cu 1 KB mai greu decât o mie de „==" :) Profileri JavaScript vă poate spune dacă există o diferență de performanță în cazul dvs.

Dar personal aș face ceea ce sugerează JSLint. Această recomandare există nu din cauza problemelor de performanță, ci pentru că tipul de constrângere înseamnă că ('\t\r\n' == 0) este adevărat.

Operatorul de comparație egală == este confuz și ar trebui evitat.

Dacă TREBUIE să trăiți cu ea, atunci amintiți-vă următoarele 3 lucruri:

1. Nu este tranzitiv: (a == b) și (b == c) nu duc la (a == c)
2. Se exclud reciproc negației sale: (a == b) și (a != b) au întotdeauna valori booleene opuse, cu toate a și b.< /strong>
3. În caz de îndoială, aflați pe de rost următorul tabel de adevăr:

''       == 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.