聊一聊 JS 中的『隱式類型轉(zhuǎn)換』

Jenny_Tong 發(fā)布于2019-08-19 17:39 / 758人閱讀

摘要：具體的行為取決于參數(shù)的類型。說(shuō)到，就不得不提一下方法，方法自帶隱式類型轉(zhuǎn)換，該方法在測(cè)試其參數(shù)之前，會(huì)先調(diào)用方法將其轉(zhuǎn)換為數(shù)字。全等運(yùn)算符會(huì)先進(jìn)行數(shù)據(jù)類型判斷，并且不會(huì)發(fā)生隱式類型轉(zhuǎn)換。

類型轉(zhuǎn)換還不行？還非得隱式？這是什么高級(jí)玩意？

廢話不多說(shuō)，我們先上一盤?，額，不對(duì)，先看一個(gè)例子吧。

3 + true

實(shí)際上在大多數(shù)編程語(yǔ)言中，都會(huì)認(rèn)為上面這個(gè)表達(dá)式是錯(cuò)誤的。因?yàn)椴紶柋磉_(dá)式與算術(shù)運(yùn)算是不兼容的。尤其是在靜態(tài)語(yǔ)言中，甚至不會(huì)被運(yùn)行運(yùn)行。即使是動(dòng)態(tài)語(yǔ)言中，通常雖然可以讓程序運(yùn)行，但是會(huì)拋出一個(gè)異常。

然而，然而， Javascript 不僅運(yùn)行程序能夠正常運(yùn)行，而且還會(huì)順利地產(chǎn)生結(jié)果 4。Javascript 真的是對(duì)類型錯(cuò)誤出奇的寬容啊。看起來(lái)很像是一件好事對(duì)不對(duì)？

基本上，在 Javascript 中，只有在一些極少數(shù)情況下才會(huì)因?yàn)轭愋湾e(cuò)誤而拋出一個(gè)異常。諸如: 調(diào)用非函數(shù)對(duì)象或者獲取 null / undefined 的屬性時(shí)。

但是在大多數(shù)情況下，Javascript 都是不會(huì)拋出異常的。這個(gè)『小婊砸』反而按照多種多樣的轉(zhuǎn)換協(xié)議偷偷的強(qiáng)制轉(zhuǎn)換為她期望的值。諾，你看，還花樣轉(zhuǎn)換呢，真會(huì)玩嘛。這就是所謂的『隱式類型轉(zhuǎn)換』。

那么，上面那個(gè)例子中，究竟是發(fā)生了什么樣的轉(zhuǎn)換方式呢？

首先，Javascript 這個(gè)『小婊砸』在遇到算數(shù)運(yùn)算符(- 、* 、/ 和 %)的時(shí)候會(huì)在運(yùn)算之前將參與運(yùn)算的雙方轉(zhuǎn)換成數(shù)字。

那么問(wèn)題又來(lái)了，true 怎么就轉(zhuǎn)換成數(shù)字了呢？實(shí)際上我們通過(guò) Number(true) 就可以看到， true 轉(zhuǎn)換為數(shù)字之后就是為 1，相反，false 轉(zhuǎn)換為數(shù)字之后就對(duì)應(yīng)為 0。

細(xì)心的你可能發(fā)現(xiàn)我在上面并沒(méi)有提到 + 運(yùn)算符，那是因?yàn)樗鼜?fù)雜。因?yàn)樗瘸袚?dān)著數(shù)字相加，又肩負(fù)著字符串連接操作的重任。具體的行為取決于參數(shù)的類型。

但是，如果一個(gè)數(shù)字和一個(gè)字符串相加，會(huì)碰撞出什么樣的火花呢？

顯然 Javascript 這個(gè)『小婊砸』更偏愛(ài)字符串多一點(diǎn)，她會(huì)將數(shù)字(toString())轉(zhuǎn)換為字符串，然后執(zhí)行字符串連接操作。

例如:

"1" + 2;    // "12"
1 + "2";    // "12"

但是，注意，Javascript 對(duì)操作順序非常敏感，以至于會(huì)發(fā)生這樣的事情:

1 + 2 + "3";    // "33"

因?yàn)榧臃ㄟ\(yùn)算是自左向右的，因此它等同于下面的表達(dá)式:

(1 + 2) + "3";    // "33"

再來(lái)看這一個(gè)例子:

if (1 == true) {
    alert("true");
} else {
    alert("false");
}

相信你一定輕松的猜到了結(jié)果對(duì)不對(duì)？

但是，哼，你以為我的問(wèn)題會(huì)這么簡(jiǎn)單么？那豈不是太小看你了。

我們都知道，Javascript 中，數(shù)字 0 為假，非0 均為真, 那么我想問(wèn)的是，在上面的條件語(yǔ)句中，到底是 1 被隱式類型轉(zhuǎn)換了呢還是 true 被隱式類型轉(zhuǎn)換了呢？

實(shí)際上在條件判斷運(yùn)算 == 中的轉(zhuǎn)換規(guī)則是這樣的:

如果比較的兩者中有布爾值(Boolean)，會(huì)把 Boolean 先轉(zhuǎn)換為對(duì)應(yīng)的 Number，即 0 和 1，然后進(jìn)行比較。

如果比較的雙方中有一方為 Number，一方為 String時(shí)，會(huì)把 String 通過(guò) Number() 方法轉(zhuǎn)換為數(shù)字，然后進(jìn)行比較。

如果比較的雙方中有一方為 Boolean，一方為 String時(shí)，會(huì)將雙方轉(zhuǎn)換為數(shù)字，然后再進(jìn)行比較。

如果比較的雙方中有一方為 Number，一方為Object時(shí)，則會(huì)調(diào)用 valueOf 方法將Object轉(zhuǎn)換為數(shù)字，然后進(jìn)行比較。

例如:

1 == { valueOf: function() {return 1;} }    // true
1 + { valueOf: function() {return 1;} }    // 2

需要強(qiáng)調(diào)的是，在 Javascript 中，只有 空字符串、數(shù)字0、false、null、undefined 和 NaN 這 6 個(gè)值為假之外，其他所有的值均為真值。

說(shuō)到 NaN，就不得不提一下 isNaN() 方法，isNaN() 方法自帶隱式類型轉(zhuǎn)換，該方法在測(cè)試其參數(shù)之前，會(huì)先調(diào)用 Number() 方法將其轉(zhuǎn)換為數(shù)字。所以 isNaN("1") 這個(gè)語(yǔ)句中明明用一個(gè)字符串去測(cè)試，返回值仍然為 false 也就不足為怪了。

在 + 號(hào)運(yùn)算中還有一種更復(fù)雜的情況，那就是數(shù)字/字符串和對(duì)象進(jìn)行運(yùn)算的時(shí)候，上面已經(jīng)舉例說(shuō)明了數(shù)字和對(duì)象運(yùn)算的情況，我們?cè)賮?lái)說(shuō)一下字符串和對(duì)象運(yùn)算的情況。

當(dāng)字符串和對(duì)象進(jìn)行 + 運(yùn)算的時(shí)候，Javascript 會(huì)通過(guò)對(duì)象的 toString() 方法將其自身轉(zhuǎn)換為字符串，然后進(jìn)行連接操作。

"1" + { toString: function() {return 1;} }    // "11"

之所以說(shuō)它特殊，是因?yàn)楫?dāng)一個(gè)對(duì)象同時(shí)包含 toString() 和 valueOf() 方法的時(shí)候，運(yùn)算符 + 應(yīng)該調(diào)用哪個(gè)方法并不明顯(做字符串連接還是加法應(yīng)該根據(jù)其參數(shù)類型，但是由于隱式類型轉(zhuǎn)換的存在，類型并不顯而易見(jiàn)。)，Javascript 會(huì)盲目的選擇 valueOf() 方法而不是 toString() 來(lái)解決這個(gè)問(wèn)題。這就意味著如果你打算對(duì)一個(gè)對(duì)象做字符串連接的操作，但結(jié)果卻是......

var obj = {
    toString: function() { return "Object CustomObj"; },
    valueOf: function() { return 1; }
};

console.log("Object: " + obj);    // "Object: 1"

隱式類型轉(zhuǎn)換會(huì)給我們?cè)斐珊芏嗦闊敲丛撛趺幢苊饽兀?/p>

建議在所有使用條件判斷的時(shí)候都使用全等運(yùn)算符 === 來(lái)進(jìn)行條件判斷。全等運(yùn)算符會(huì)先進(jìn)行數(shù)據(jù)類型判斷，并且不會(huì)發(fā)生隱式類型轉(zhuǎn)換。