49 Вопрос: Какой оператор равенства (== vs ===) следует использовать в сравнениях JavaScript?

вопрос создан в Wed, Mar 22, 2017 12:00 AM

Я использую JSLint , чтобы пройти через JavaScript, и он возвращает много предложений, чтобы заменить == (два знака равенства) с === (три знака равенства) при выполнении таких вещей, как сравнение idSele_UNVEHtype.value.length == 0 внутри оператора if.

Есть ли выигрыш в производительности при замене == на ===?

Любое улучшение производительности будет приветствоваться, поскольку существует много операторов сравнения.

Если преобразование типов не выполняется, увеличится ли производительность по сравнению с ==?

    
5669
  1. Кому может быть интересна та же тема === vs ==, но в PHP, можете прочитать здесь: stackoverflow.com/questions/2401478/why-is-faster-than-in-php/… а>
    2010-12-31 12: 33: 37Z
  2. На всякий случай, если кому-то интересно в 2012 году: === намного быстрее, чем ==. jsperf.com/comparison-of-comparisons
    2012-07-03 23: 02: 38Z
  3. @ minitech так и должно быть, поскольку он не выполняет преобразование типов
    2012-07-14 19: 10: 25Z
  4. @ minitech, я сомневаюсь, что кто-то собирается сделать свое приложение заметно быстрее, используя === вместо ==. На самом деле, тест не показывает большой разницы между обоими в современных браузерах. Лично я обычно использую == везде, если мне действительно не нужно строгое равенство.
    2012-12-25 09: 09: 27Z
  5. Вот часть выступления Крокфорда по JS The Good Parts , где он обсуждает операторы === и ==: youtube.com/… Если он не воспроизводится, он в 15 : 20
    2013-04-22 16: 17: 00Z
30 ответов                              30                         

Оператор identity (===) ведет себя идентично оператору равенства (==), за исключением того, что преобразование типов не выполняется, и типы должны быть одинаковыми, чтобы считаться равными.

Ссылка: Учебник по Javascript: операторы сравнения

Оператор == сравнивает на равенство после выполнения любых необходимых преобразований типов . Оператор === не выполнит преобразование, поэтому, если два значения не совпадают, тип === просто вернет false. Оба одинаково быстрые.

Процитирую превосходный JavaScript Дугласа Крокфорда ,

  

В JavaScript есть два набора операторов равенства: === и !== и их злые близнецы == и !=. Хорошие работают так, как вы ожидаете. Если два операнда имеют одинаковый тип и имеют одинаковое значение, то === выдает 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
     

Отсутствие транзитивности вызывает тревогу. Мой совет - никогда не использовать злых близнецов. Вместо этого всегда используйте === и !==. Все только что показанные сравнения дают false с оператором ===.

Обновление:

Хороший вопрос был поднят @Casebash в комментарияхи в @Phillipe Laybaert's ответ о ссылочных типах. Для справочных типов == и === действуют согласованно друг с другом (за исключением специального случая).

 
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 или valueOf. Например, рассмотрим сравнение строкового литерала со строковым объектом, созданным конструктором String.

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

Здесь оператор == проверяет значения двух объектов и возвращает true, но === видит, что они не одного типа, и возвращает false. Который правильный? Это действительно зависит от того, что вы пытаетесь сравнить. Мой совет - полностью обойти вопрос и просто не использовать конструктор String для создания строковых объектов.

Ссылка
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3 р>     

6193
2017-05-23 12: 10: 45Z
  1. === не быстрее, если типы одинаковы. Если типы не совпадают, === будет быстрее, потому что не будет пытаться выполнить преобразование.
    2008-12-31 03: 02: 11Z
  2. === никогда не будет медленнее, чем ==. Они оба выполняют проверку типов, поэтому === ничего не делает по сравнению с ==, но проверка типов может позволить === завершиться быстрее, если типы не совпадают.
    2009-02-02 04: 17: 55Z
  3. Замена всех == /! = на === /! == увеличивает размер файла js, тогда загрузка займет больше времени. :)
    2010-03-31 09: 22: 07Z
  4. "... правила, по которым они действуют, сложны и не запоминаются ..." Теперь такие утверждения заставляют вас чувствовать себя в безопасности при программировании ...
    2011-12-09 16: 24: 46Z
  5. Иногда система типов JavaScript заставляет меня убегать от криков.
    2012-11-08 04: 06: 58Z

Использование оператора == ( 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

Использование оператора === ( Identity )

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

Это связано с тем, что оператор равенства == выполняет приведение типов , что означает, что интерпретатор неявно пытается преобразовать значения перед сравнением.

С другой стороны, оператор идентичности === не выполняет приведение типов и, следовательно, не преобразует значения при сравнении и поэтому работает быстрее (согласно этот тест JS (тест пропускается на один шаг.

    
1074
2019-04-29 01: 53: 48Z
  1. @ Обезьяна программного обеспечения: не для типов значений (число, логическое значение, ...)
    2009-06-05 20: 00: 24Z
  2. type coercion vs type casting vs type convertion: stackoverflow.com/questions/8857763/…
    2014-07-23 12: 02: 16Z
  3. Поскольку никто не упомянул таблицу равенства Javascript, вот она: dorey.github.io/JavaScript-Equality-Table
    2015-01-06 03: 17: 19Z
  4. В первом утверждении, вы уверены, что «истина» преобразуется в 1, а не 1 преобразуется в истину?
    2016-11-22 10: 05: 58Z
  5. Откуда происходят термины "равенство" и "идентичность"? Стандарт не использует эти термины. Он называет == «абстрактным равенством», а === - «строгим равенством». Разумеется, называть == «равенство» - это ИМХО ужасно, поскольку оно не транзитивно, но зачем спорить? Я беру больше проблем с «идентичностью», хотя; Я думаю, что этот термин довольно обманчив, хотя и «работает». А если серьезно, кто придумал термин «идентичность»? Я ищу стандарт и не могу его найти.
    2018-02-07 08: 03: 44Z

Интересное графическое представление сравнения равенства между == и ===.

Источник: http://dorey.github.io/JavaScript-Equality- Таблица / сильный> р>

var1 === var2

  

При использовании === для проверки на равенство JavaScript все остается как есть. Ничто не преобразуется перед оценкой.

Оценка равенства === в JS

var1 == var2

  

При использовании == для проверки равенства JavaScript некоторые   происходят конверсии в стиле фанк.

Оценка равенства == в JS

  

Мораль истории:

     

Используйте ===, если вы не полностью понимаете   конверсии с ==.

    

639
2018-07-13 17: 14: 41Z
  1. Я бы пошел еще дальше с моралью: всегда использую === /! ===, но понимаю преобразование для возможности справиться с кодом других людей
    2015-05-08 11: 11: 03Z
  2. @ mfeineis вы имеете в виду === или! == вместо == или! =. Не хочу путать новых кодеров;)
    2016-06-23 14: 04: 34Z
  3. из моего опыта использования трех равных может вызвать проблемы, и их следует избегать, если они полностью не поняты. два равенства дают гораздо лучшие результаты, потому что в 99% случаев я действительно не хочу, чтобы типы были одинаковыми.
    2017-02-12 08: 47: 06Z
  4. @ vsync: если вы действительно не хотите, чтобы типы были равными , вам следует использовать три равняется !
    2017-04-24 05: 19: 24Z
  5. Единственное исключение: вы можете безопасно использовать x == null, чтобы проверить, является ли x null или undefined.
    2018-09-12 15: 40: 08Z

В ответах здесь я ничего не читал о том, что означает равно . Некоторые скажут, что === означает равный и того же типа , но это не совсем так. Фактически это означает, что оба операнда ссылаются на один и тот же объект , или в случае типов значений имеют одинаковое значение .

Итак, давайте возьмем следующий код:

 
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

То же самое здесь:

 
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

Или даже:

 
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

Такое поведение не всегда очевидно. В этой истории есть нечто большее, чем быть равными и быть однотипными.

Правило таково:

Для типов значений (чисел):
a === b возвращает значение true, если a и b имеют одинаковое значение и имеют одинаковый тип

Для ссылочных типов:
a === b возвращает значение true, если a и b ссылаются на один и тот же объект

Для строк:
a === b возвращает значение true, если a и b являются строками и содержат одинаковые символы

Строки: особый случай ...

Строки не являются типами значений, но в Javascript они ведут себя как типы значений, поэтому они будут «равны», когда символы в строке одинаковы и имеют одинаковую длину (как описано в третьем правиле) р>

Теперь это становится интересным:

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

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

Но как насчет этого?

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

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

Я думал, что строки ведут себя как типы значений? Ну, это зависит от того, кого вы спрашиваете ... В этом случае a и b не одного типа. a относится к типу Object, а b относится к типу string. Просто помните, что при создании строкового объекта с использованием конструктора String создается что-то типа Object, которое в большинстве случаев ведет себя как строка .

    
596
2012-01-10 09: 08: 34Z
  1. activa: Я хотел бы уточнить, что строки одинаковы только тогда, когда они являются литералами. new String ("abc") === "abc" - false (согласно моим исследованиям).
    2009-06-05 19: 54: 58Z
  2. new Number() == "0". Также в Firefox: (function(){}) == "function () {\n}"
    2011-03-30 05: 21: 36Z
  3. Спасибо, что объяснили, почему new String("123") !== "123". Они разных типов. Простой, но запутанный.
    2012-08-26 05: 51: 54Z
  4. String объектов ведут себя как строки, как и любой другой объект . new String никогда не следует использовать, так как это не создает реальных строк. Настоящая строка, которая может быть сделана со строковыми литералами или вызывать String как функцию без new, например: String(0); //"0", Real string, not an object
    2012-12-04 23: 51: 33Z
  5. Но в описанных вами случаях оператор "==" ведет себя точно так же.
    2015-02-06 10: 48: 04Z

Позвольте мне добавить этот совет:

В случае сомнений прочитайте спецификацию !

ECMA-262 - это спецификация языка сценариев, для которого JavaScript является диалектом. Конечно, на практике важнее то, как ведут себя наиболее важные браузеры, чем эзотерическое определение того, как что-то должно обрабатываться. Но полезно понять, почему new String ("a")! == "a" .

Позвольте мне объяснить, как прочитать спецификацию, чтобы прояснить этот вопрос. Я вижу, что в этой очень старой теме ни у кого не было ответа на очень странный эффект. Так что, если вы можете прочитать спецификацию, это очень поможет вам в вашей профессии. Это приобретенный навык. Итак, продолжим.

Поиск в файле PDF для === приводит меня к странице 56 спецификации: 11.9.4. Оператор строгого равенства (===) , и после просмотра спецификации я нахожу:

  

11.9.6 Алгоритм сравнения строгого равенства
  Сравнение x === y, где x и y являются значениями, дает true или false . Такое сравнение выполняется следующим образом:
  1. Если Type (x) отличается от Type (y), верните false .
  2. Если Тип (x) не определен, верните true .
  3. Если Тип (x) равен Null, верните true .
  4. Если тип (x) не является числом, перейдите к шагу 11.
  5. Если x равен NaN , верните false .
  6. Если y NaN , верните false .
  7. Если x совпадает с y, верните true .
  8. Если x равно +0, а y равно −0, верните true .
  9. Если x равен −0, а y равен +0, верните true .
  10. Верните false .
  11. Если для Type (x) задано значение String, вернуть true , если x и y представляют собой одну и ту же последовательность символов (одинаковую длину и saменя персонажи в соответствующих позициях); в противном случае верните false .
  12. Если Type (x) - логическое значение, верните true , если x и y оба имеют true или оба false ; в противном случае верните false .
  13. Верните true , если x и y относятся к одному и тому же объекту или если они ссылаются на объекты, соединенные друг с другом (см. 13.1.2). В противном случае верните false .

Интересен шаг 11. Да, строки обрабатываются как типы значений. Но это не объясняет, почему new String ("a")! == "a" . У нас есть браузер, не соответствующий ECMA-262?

Не так быстро!

Давайте проверим типы операндов. Попробуйте сами, обернув их в typeof () . Я считаю, что new String ("a") является объектом, и используется шаг 1: верните false , если типы различаются.

Если вам интересно, почему new String ("a") не возвращает строку, как насчет упражнения по чтению спецификации? Веселись!

Aidiakapi написал это в комментарии ниже:

  

Из спецификации

     

11.2.2 Новый оператор :

     

Если Type (конструктор) не является Object, генерировать исключение TypeError.

     

Другими словами, если String не будет иметь тип Object, его нельзя использовать с оператором new.

new всегда возвращает объект, даже для конструкторов String . И увы! Семантика значения для строк (см. Шаг 11) потеряна.

И наконец, это означает: new String ("a")! == "a" .

    
261
2015-10-26 10: 45: 32Z
  1. Подразумевается, что результат типа (x) совпадает с typeof?
    2012-11-15 18: 35: 49Z
  2. @ nalply Я не совсем понимаю беспокойство по поводу поведения с new String('x'), потому что я никогда не видел никакого кода в дикой природе, который использует примитивные объекты-оболочки, и я не думаю, что есть много веских причин, особенно в наши дни. Вы когда-нибудь сталкивались с кодом, который делает?
    2018-09-10 18: 28: 06Z
  3. @ Энди, проблема в злонамеренном или просто небрежном стороннем коде, тогда вы не можете предположить, что никто не использует new String().
    2018-09-11 09: 46: 36Z
  4. Если он небрежный, то, как вы узнаете, ===. Если это злонамеренно, я думаю, что new String(), вероятно, меньше всего беспокоит вас. Я понимаю проблему в теории, но, опять же, у вас есть примеры из реальной жизни? Для меня это похоже на старое беспокойство, что кто-то может установить undefined на другое значение.
    2018-09-12 15: 34: 23Z
  5. Я не знаю, откуда вы это взяли, но ваш алгоритм сравнения ошибается на шаге 2. В разделе «7.2.15 Сравнение строгого равенства» сначала проверяется, являются ли типы то же самое, если да, являются ли они номером. Если нет, то используется раздел «7.2.12 SameValueNonNumber (x, y)».
    2019-06-17 19: 40: 22Z

В PHP и JavaScript это оператор строгого равенства. Это означает, что он будет сравнивать как тип, так и значения.

    
98
2010-05-12 12: 58: 39Z
  1. @ David: правильно. Вот почему этот ответ является неточным (или даже неправильным)
    2010-05-31 12: 25: 27Z
  2. @ David var a = {}, b = {}; a == b возвращает false.
    2011-02-26 18: 37: 49Z
  3. Да: два разных объекта с одинаковым типом и значением сравнивают false, т.е.этот ответ просто неправильный. Почему у него 50 голосов?
    2013-10-18 10: 45: 37Z
  4. Я понимаю, что это старый, но выяснить, почему этот ответ все еще "правильный", потому что в примере var a = {}, b = {};, хотя и a, и b действительно являются объектом, но технически говоря, они не являются одинаковыми значениями. Это разные экземпляры. Обратите внимание, что сравнение экземпляров ведет себя иначе, чем сравнение примитивов. Что, вероятно, добавляет к этой путанице. Вы увидите похожее поведение сравнения, если будете использовать версию экземпляра примитивных типов данных. Например, new String('asdf') или new Number(5). Пример: new Number(5) == new Number(5) - ложь, хотя они имеют одинаковое значение.
    2017-05-18 18: 02: 00Z
  5. Мы все забываем, что ссылка на объект на самом деле является типом значения, так как это указатель на слот памяти. Сравнение объектов не сравнивает «значение объекта», но является ли оба указателя одинаковыми, что означает, что они ссылаются на один и тот же слот памяти. Это очень тонкое различие в сравнении типов, так как оператор "===" действительно должен сказать "если тип, значение и ссылка на объект в памяти одинаковы".
    2018-09-03 20: 05: 25Z

Я проверил это в Firefox с Firebug , используя такой код: р>  

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

и р>  

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

Мои результаты (проверенные пять раз и усредненные):

 
==: 115.2
===: 114.4

Так что я бы сказал, что минимальная разница (это более 100000 итераций, помните) ничтожна. Производительность не является причиной для ===. Напечатайте безопасность (ну, так же безопасно, как и в JavaScript), и качество кода.

    
94
2014-10-26 11: 07: 41Z
  1. Больше, чем безопасность типов, вам нужна логическая корректность - иногда вы хотите, чтобы все было правдиво, когда == не согласен.
    2011-09-13 21: 14: 15Z
  2. Теперь, как они сравниваются, когда существует фактическое приведение типа для оператора ==? Помните, что именно тогда происходит повышение производительности.
    2013-07-13 21: 13: 44Z
  3. ОСНОВНАЯ разница при правильном тестировании по вышеупомянутым причинам - быстрее проверять только неравенство типов. jsfiddle.net/4jhuxkb2
    2015-07-06 17: 04: 57Z

В JavaScript это означает то же значение и тип.

Например,

 
4 == "4" // will return true

, но

 
4 === "4" // will return false 
    
91
2014-10-26 11: 11: 58Z

Оператор === называется оператором строгого сравнения, он действительно отличается от оператора == .

Давайте возьмем 2 переменные a и b.

Чтобы "a == b" оценить как истинное, a и b должны иметь одинаковое значение .

В случае "a === b" a и b должны иметь одинаковое значение , а также того же типа для него оценить, чтобы правда.

Возьмите следующий пример

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

В итоге ; использование оператора == может дать значение true в ситуациях, когда вы этого не хотите, поэтому использование оператора === будет более безопасным.

В сценарии использования 90% не имеет значения, какой из них вы используете, но удобно знать разницу, когда однажды вы получаете неожиданное поведение.

    
80
2013-08-21 08: 39: 53Z

Он проверяет, равны ли одинаковые стороны в типе и значении .

Пример:

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

Общий пример:

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

Еще один распространенный пример:

 
null == undefined // returns "true", but in most cases a distinction is necessary
    
74
2018-07-19 07: 04: 17Z
  1. также, 'string' !== 'number'
    2012-01-06 19: 34: 54Z

Почему == такой непредсказуемый?

Что вы получаете, когда сравниваете пустую строку "" с нулевым числом 0?

true

Да, верно, согласно ==, пустая строка и число ноль совпадают.

И это не заканчивается, вот еще один:

 
'0' == false // true

С массивами все становится очень странным.

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

Тогда страннее со строками

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

Становится хуже:

Когда равен не равен?

 
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!

Позвольте мне сказать это снова:

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

И это просто сумасшедшие вещи, которые вы получаете с примитивами.

Это совершенно новый уровень безумия, когда вы используете == с объектами.

На данный момент вы, вероятно, задаетесь вопросом ...

Почему это происходит?

Ну, это потому, что в отличие от "triple equals" (===), который просто проверяет, совпадают ли два значения.

== выполняет целый ряд других вещей .

Он имеет специальную обработку для функций, специальную обработку для нулей, неопределенных строк, вы называете это.

Это довольно странно.

На самом деле, если бы вы попытались написать функцию, которая делает то, что делает ==, она бы выглядела примерно так:

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

Так что это значит?

Это означает, что == является сложным.

Поскольку это сложно, трудно понять, что произойдет, когда вы его используете.

Это означает, что вы можете получить ошибки.

Итак, мораль этой истории ...

Сделай свою жизнь менее сложной.

Используйте === вместо ==.

Конец.

    
72
2018-04-21 15: 39: 44Z
  1. Ваш looseEqual неверен. Function == Function.toString() верно, но looseEqual(Function, Function.toString()) неверно. Не уверен, почему вы отфильтровываете функции в начале.
    2016-09-07 22: 16: 44Z
  2. @ Oriol, вы были правы, я обновил код, чтобы учесть это, к вашему сведению, на основании моих тестов было недостаточно удалить фильтр для "функций", вместо этого «функции» должны были обрабатываться совсем по-другому.
    2016-09-08 22: 43: 51Z
  3. Будьте в курсе спецификация не обрабатывает функции по-разному, это всего лишь объекты. Кажется, проблема в том, что вы полагаетесь на typeof x === "object", чтобы проверить, является ли это объектом, но `typeof работает только для ненулевых примитивов. Возможно, вас заинтересует мой список правильных способов проверить, является ли значение объектом
    2016-09-08 23: 25: 01Z
  4. Я пытался обрабатывать функции и объекты одинаково, но обнаружил, что его результаты неверны. Например, если функции обрабатываются как объекты, то сравнение функции с объектом, который реализует функцию valueOf () или toString (), которая соответствует функции, пройдет, но в действительности это не так. Пример: (function blah() { console.log("test"); }) != {valueOf:function(){return "function blah() { console.log(\"test\"); }";}} - посмотрите эту скрипту JS, которая выполняет все тесты: jsfiddle.net/luisperezphd/7k6gcn6g (там 1225 тестПерестановки)
    2016-09-10 16: 22: 22Z
  5. Вы правы, большие наблюдения, это подчеркивает главное, что == делает много вещей, делая очень трудным предвидеть результаты, в то время как === намного проще и предсказуемое, что является одной из основных причин, === является рекомендуемым выбором. (Я добавлю примечание к ответу с указанием вашей точки зрения)
    2016-09-11 13: 20: 38Z

Блок-схема выполнения Javascript для строгого равенства /сравнения '==='

Javascript строгое равенство

Блок-схема выполнения Javascript для нестрогого равенства /сравнения '=='

Javascript неравенство

    
67
2015-09-05 13: 53: 16Z
  1. Я не понимаю, почему стрелка string указывает на большую серую рамку, это должно означать, что прерыватель преобразует строку в число?
    2017-02-11 13: 26: 09Z
  2. @ vsync Указывает на параметр строки в сером поле, т.е. строка - > # || NaN. Javascript не является языком сценариев типов, то есть в основном он может иметь любой тип переменной. Итак, он указывает на эту серую коробку.
    2017-02-12 06: 56: 21Z
  3. Я просто спросил, предназначено ли оно для целей приведения, так как string предполагается сравнивать с типом number, поэтому прерыватель смотрит на то, с чем следует сравнивать строку, и приведите строку соответственно?
    2017-02-12 08: 44: 48Z
  4. Большое серое поле - это то, что ToNumber будет возвращать при задании различных типов, поэтому, если ему дана строка, он выберет только последний вариант (и преобразует его в число ). == использует ToNumber только в случаях string == number или boolean == anything выше (и только на string/boolean). Это означает, что == никогда не преобразует undefined или null, даже если они находятся в сером поле. (Для любой комбинации undefined, null или обоих, == всегда будет возвращать true. Кроме того, независимо от того, находится ли значение слева или справа, не имеет значения, =====) будет возвращать один и тот же результат.)
    2018-03-07 05: 54: 22Z

JavaScript === против ==.

 
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
    
53
2015-11-12 03: 18: 12Z

Это означает равенство без приведения типов . приведение типов означает, что JavaScript не преобразует автоматически никакие другие типы данных в строковые типы данных

 
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 
    
52
2017-07-30 21: 40: 44Z

В типичном сценарии разницы в производительности не будет. Более важным может быть тот факт, что тысяча "===" на 1 КБ тяжелее тысячи "==" :) профилировщиков JavaScript может сказать вам, есть ли разница в производительности в вашем случае.

Но лично я бы сделал то, что предлагает JSLint. Эта рекомендация не из-за проблем с производительностью, а из-за того, что приведение типов означает ('\t\r\n' == 0).

    
47
2017-05-23 12: 02: 56Z
  1. Не всегда верно. При сжатии gzip разница будет почти незначительной.
    2009-06-22 23: 43: 15Z
  2. Согласен, но тысяча "===" также означает 10 тысяч строк кода, так что на 1 КБ больше или меньше ...;)
    2016-09-28 18: 32: 51Z
  3. Если вы беспокоитесь о размере, то просто поменяйте все == с ===, а затем используйте регулярное выражение, заключенное в av eval, чтобы переключить его обратно
    2017-04-23 03:30: 55Z

Оператор сравнения == сбивает с толку, и его следует избегать.

Если вы ДОЛЖНЫ жить с этим, запомните следующие 3 вещи:

  1. Это не транзитивно: (a == b) и (b == c) не приводит к (a == c )
  2. Он взаимоисключающий со своим отрицанием: (a == b) и (a! = b) всегда содержат противоположные логические значения со всеми a и б.
  3. В случае сомнений выучите наизусть следующую таблицу истинности:

РАВНАЯ ТАБЛИЦА РАВНЫХ ОПЕРАТОРОВ В JAVASCRIPT

  • Каждая строка в таблице представляет собой набор из 3 взаимно "равных" значений, что означает, что любые 2 значения из них равны, используя знак равенства == * * /

** STRANGE: обратите внимание, что любые два значения в первом столбце в этом смысле не равны. **

 
''       == 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.
    
43
2014-02-19 15: 01: 17Z

Маловероятно, что между этими двумя операциями будет какая-либо разница в производительности. Преобразование типов не требуется, поскольку оба параметра уже одного типа. Обе операции будут иметь сравнение типов с последующим сравнением значений.

    
36
2008-12-11 14: 44: 55Z

Да! Это имеет значение.

Оператор === в javascript проверяет значение, а также тип , где оператор == просто проверяет значение (выполняет преобразование типа при необходимости) .

введите описание изображения здесь

Вы можете легко проверить это. Вставьте следующий код в файл HTML и откройте его в браузере

 
<script>

function onPageLoad()
{
    var x = "5";
    var y = 5;
    alert(x === 5);
};

</script>

</head>

<body onload='onPageLoad();'>

Вы получите false в состоянии тревоги. Теперь измените метод onPageLoad() на alert(x == 5);, и вы получите true .

    
36
2015-01-10 14: 34: 14Z

Оператор === проверяет значения и типы переменных на равенство.

Оператор == просто проверяет значение переменных на равенство.

    
33
2017-11-20 12: 05: 13Z

Это строгий проверочный тест.

Это хорошо, особенно если вы проверяете между 0 и false и null.

Например, если у вас есть:

 
$a = 0;

Тогда:

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

Все возвращает true, и вы можете этого не хотеть. Предположим, у вас есть функция, которая может возвращать 0-й индекс массива или false при сбое. Если вы проверите «==» false, вы можете получить запутанный результат.

Так с тем жевыше, но строгий тест:

 
$a = 0;

$a===0; // returns true
$a===NULL; // returns false
$a===false; // returns false
    
31
2015-04-27 08: 26: 10Z
  1. В JavaScript это совершенно неправильно и ошибочно неполно. 0 != null. -1
    2013-05-06 03: 07: 17Z

JSLint иногда дает вам нереальные причины для изменения материала. === имеет точно такую ​​же производительность, что и ==, если типы уже совпадают.

Это быстрее, только когда типы не совпадают, и в этом случае он не пытается преобразовать типы, но напрямую возвращает false.

Итак, IMHO, JSLint может использоваться для написания нового кода, но бесполезной чрезмерной оптимизации следует избегать любой ценой.

То есть, нет смысла менять == на === в чеке, подобном if (a == 'test'), когда вы знаете, что факт может быть только строкой.

Изменение большого количества кода таким образом тратит время разработчиков и рецензентов и ничего не дает.

    
30
2017-11-20 12: 11: 45Z

Просто

== означает сравнение между операндами с type conversion

&амп; р>

=== означает сравнение между операндами без type conversion

Преобразование типов в javaScript означает, что javaScript автоматически преобразует любые другие типы данных в строковые типы данных.

Например:

 
123=='123'   //will return true, because JS convert integer 123 to string '123'
             //as we used '==' operator 

123==='123' //will return false, because JS do not convert integer 123 to string 
            //'123' as we used '===' operator 
    
29
2017-11-20 12: 49: 58Z

Простой пример

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

2 === '2'  -> false, values are NOT SAME because of no type conversion.
    
25
2015-07-04 03: 56: 47Z

Как правило, я бы использовал === вместо ==!== вместо !=).

Причины объяснены в ответах выше, и Дуглас Крокфорд довольно ясно об этом ( JavaScript: хорошие части ).

Однако есть одно единственное исключение :  == null - это эффективный способ проверить, является ли значение null или undefined:

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

Например, jQuery 1.9.1 использует этот шаблон 43 раза и средство проверки синтаксиса JSHint даже предоставляет eqnull расслабляющий вариант по этой причине.

Из руководства по стилю jQuery :

  

Строгие проверки на равенство (===) должны использоваться в пользу ==. Единственный   исключение - при проверке неопределенности и нуля посредством нуля.

 
// Check for both undefined and null values, for some important reason. 
undefOrNull == null;
    
24
2013-04-27 14: 15: 38Z

В верхних 2 ответах оба упомянутых == означают равенство, а === означает идентичность. К сожалению, это утверждение неверно.

Если оба операнда == являются объектами, их сравнивают, чтобы увидеть, являются ли они одним и тем же объектом. Если оба операнда указывают на один и тот же объект, оператор равенства возвращает true. Иначе, два не равны.

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

В приведенном выше коде оба == и === становятся ложными, потому что a и b не являются одинаковыми объектами.

То есть: если оба операнда == являются объектами, == ведет себя так же, как ===, что также означает идентичность. Существенное отличие этих двух операторов заключается в преобразовании типов. == имеет преобразование, прежде чем проверяет равенство, но === нет.

    
24
2013-09-09 08: 31: 45Z

Проблема в том, что вы можете легко попасть в беду, поскольку JavaScript имеет много неявных преобразований, что означает ...

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

Что довольно скоро становится проблемой. Лучший пример того, почему неявное преобразование является «злым», можно взять из этого кода в MFC /C ++ который на самом деле скомпилируется из-за неявного преобразования из CString в HANDLE, который является указателем typedef типа ...

 
CString x;
delete x;

Очевидно, что во время выполнения очень неопределенные вещи ...

Google для неявных преобразований в C ++ и STL , чтобы получить некоторые аргументы против этого .. . р>     

22
2014-10-26 11: 08: 37Z
  1. 0 == null имеет значение false.
    2014-01-13 00: 25: 19Z

Из основной ссылки на JavaScript

  

=== Возвращает true, если операнды строго равны (см. выше)   без преобразования типов.

    
22
2015-11-12 03: 17: 34Z

Сравнение равенства:

Оператор ==

Возвращает true, когда оба операнда равны. Операнды перед сравнением преобразуются в один и тот же тип.

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

Сравнение равенства и типов:

Оператор ===

Возвращает true, если оба операнда имеют одинаковый тип. Это вообще лучше и безопаснее, если сравнивать таким образом, потому что нет закулисных преобразований типов.

 
>>> 1 === '1'
false
>>> 1 === 1
true
    
21
2013-10-02 21: 54: 43Z

* Операторы === vs == *

 
1 == true    =>    true
true == true    =>    true
1 === true    =>    false
true === true    =>    true
    
19
2014-03-19 12: 08: 11Z

Вот удобная сравнительная таблица, в которой показаны происходящие преобразования и различия между == и ===.

В заключении говорится:

  

"Используйте три равных, если вы не полностью понимаете, какие преобразования   место для двух равных. "

http://dorey.github.io/JavaScript-Equality-Table/ р>     

19
2014-03-27 11: 41: 35Z
источник размещен Вот
Другие вопросы