如果編程語言是一個大家庭，那么JavaScript無疑是那個有點怪異，但又讓所有人喜愛的“怪叔叔”——雖然大家都喜歡他，但似乎沒人能完全理解他。

你肯定聽過那些讓人啼笑皆非的故事，比如NaN竟然是個數字，或者JavaScript居然只用了10天就被開發出來（是真的！）。但是，今天我們要深入挖掘一些更為深奧的JavaScript冷知識——這些內容即使是資深開發者也未必知道。

系好安全帶，讓我們一起探索這個充滿混亂與魅力的JavaScript世界吧！

1. +[] 其實是 0 —— JavaScript的“魔術數字”

假設你在做一個購物網站，客戶可以將商品加入購物車，每個商品都有一個價格。當購物車為空時，你當然希望它顯示出“0”元，而不是顯示空白。那該怎么做呢？JavaScript 給了你一個非常神奇的解決方案——+[]！

你可能會問：“空數組怎么變成數字0了？”其實，這就像你在餐廳里點了一道菜，服務員告訴你：‘這道菜是零元’，你看著菜單，確實什么都沒點，但系統卻自動給你算了個0元賬單。

console.log(+[]); // 0
console.log(typeof +[]); // "number"

怎么回事呢？在JavaScript里，[] 是一個空數組，它本來并不是一個數字。可是當你給它加一個 + 符號，這個空數組會被迫變成一個字符串，空字符串 ""。然后，當空字符串被轉換成數字時，它就變成了 0。就像購物車本來什么都沒放，但系統默默幫你計算了一個“空”賬單——0元。

這也許看起來很奇怪，但在實際的開發中，你可能會用這個技巧來進行一些數值計算。比如，你在判斷一個數組是否為空時，可能會巧妙地用 +[] 來表示一個初始值 0，而不需要額外定義變量。就像在不看菜單的情況下，服務員已經給你默默計算好了賬單。

2. void 運算符的“秘密”

你可能見過 void 運算符，很多人都知道它返回 undefined，但你知道嗎？這只是其中的一個方面，它背后其實有個不為人知的秘密。

比方說，你正在開發一個網站，需要在某個地方打印出“歡迎回來”，但又不希望這個打印操作返回任何值。正常情況下，console.log() 會打印出內容，但它實際上會返回 undefined。這時候，如果你加上 void 運算符，結果就變得更加神秘了。

void console.log("歡迎回來"); // 打印 "歡迎回來"，但是返回 undefined

那么，void 是怎么工作的呢？void 運算符的作用是“評估一個表達式，但不返回其值”。換句話說，它執行了 console.log("歡迎回來") 這個操作，讓它正常輸出，但卻不會返回任何值。看似毫無意義的 void 運算符，其實在一些場景下非常有用，尤其是當你不想讓某個操作的返回值影響其他操作時。

3. 函數也能擁有屬性

在 JavaScript 中，函數不僅僅是代碼塊，它們本質上也是對象。這意味著，你可以像給普通對象添加屬性一樣，給函數也添加屬性。這聽起來是不是有點“魔幻”？

想象一下，你有一個簡單的函數，它的作用是打印“Hello”。在常規情況下，這個函數只會返回一個字符串：“Hello”。但如果你想賦予這個函數一些“個性”，也就是給它加上一些額外的屬性呢？JavaScript 允許你這么做！

function greet() {
  return "Hello";
}
greet.language = "English";
console.log(greet.language); // "English"

怎么回事？在上面的例子中，greet 是一個簡單的函數，但我們給它添加了一個名為 language 的屬性，值為 "English"。你可以看到，函數 greet 不僅僅做它的本職工作（返回 "Hello"），還變得像一個對象一樣，承載了額外的信息。

這有什么用呢？你可以把它想象成給一個“工具”增加了“功能”。比如，你設計了一個非常實用的“智能助手”函數，它不僅能完成本職工作（比如計算、輸出等），你還可以給它增加一些額外的屬性，像“語言”、“版本號”等，用來記錄助手的詳細信息。

這種特性在實際開發中也非常有用，尤其是在一些需要對函數進行動態配置或擴展的場景下。比如，你可能需要給某些函數標記不同的功能，或者在調試時，添加一些用于記錄的元數據。這樣不僅使你的代碼更靈活，還能讓它看起來更“有趣”。

4. null 是個對象，它偏偏不喜歡你

在 JavaScript 中，有一個總是讓人抓狂的存在——null。它看起來不像對象，但偏偏系統把它當成了對象。這聽起來就像是一個明明不是員工，卻拿到了公司員工卡的“客串角色”。來看看這段代碼：

console.log(typeof null); // "object"

為什么 null 是一個對象呢？這個問題的背后有著一段“歷史”故事。其實，早期 JavaScript 的類型系統并不完美，null 被錯誤地標記為對象。這種錯誤一直沒有修復，因為如果修改了這一點，整個互聯網的許多現有代碼都會因為這個不兼容的變化而崩潰。所以，盡管 null 看起來并不像一個真正的對象，我們仍然不得不忍受這個奇怪的現象，直到今天。

為什么它會讓你感到困惑呢？可以把 null 想象成一個假的對象，盡管它并不具備對象的屬性和方法，但 JavaScript 系統卻偏偏把它當成了對象。就好比你進了一家公司，所有員工都穿著公司制服，而“null”雖然沒有做任何工作，但卻穿著制服被誤認為是員工。

這也是 JavaScript 充滿“怪異”的一個典型例子，早期的設計決定了今天的我們不得不和它一起生活，盡管它有點讓人抓狂。

5. __proto__ 性能陷阱

在 JavaScript 中，每一個對象都有一個“隱藏的”屬性——__proto__，它指向對象的原型。通過 __proto__，你可以查看和修改一個對象的原型鏈，但這里有個大問題：頻繁使用 __proto__ 會讓你的代碼變得非常慢！

現代的 JavaScript 引擎會優化對象，當它們的原型鏈不發生變化時，性能會變得更好。但是，一旦你開始修改對象的 __proto__，這種優化就會迅速消失，就像調試時你的耐心一樣——一瞬間就沒有了。

看看下面這段代碼：

const obj = { a: 1 };
obj.__proto__ = { b: 2 }; // 現在你讓一切變慢了！

為什么這樣會影響性能呢？可以把 __proto__ 想象成一條“隱形的繩子”，它把每個對象和它的原型連接起來。當你不去動它時，JavaScript 引擎就能像高效的機器一樣執行你的代碼。可是，一旦你開始用 __proto__ 來“拉扯”這條繩子，系統就需要重新計算和更新原型鏈，從而導致性能下降，程序執行變慢。

這就好比你在企業中有一個高效的團隊，每個人都按部就班地完成自己的工作，但如果你每天去干預他們，隨便換換角色、變換工作內容，效率肯定會下降。同理，頻繁調整原型鏈，特別是通過 __proto__，會讓性能大打折扣。

解決方案是什么呢？如果你真的需要修改原型鏈，應該使用 Object.setPrototypeOf，它是修改原型鏈的標準方法，而且性能上也比直接操作 __proto__ 更加高效。如果完全不需要改變原型鏈，最好就不要在運行時去“干預”它。保持對象的穩定性，性能自然也能得到保證。

6. 全局對象在“監視”你

在瀏覽器中，window 是全局對象，而在 Node.js 中，它是 global。可是，在現代的 JavaScript 模塊中？竟然沒有所謂的全局對象！

// 在瀏覽器中
console.log(window === globalThis); // true

// 在 Node.js 中
console.log(global === globalThis); // true

為什么會這樣呢？全局對象 window 和 global 看起來是那么熟悉，但它們其實只是在各自的環境中扮演了“主角”的角色。瀏覽器中的全局環境是由 window 提供的，而在 Node.js 中是 global。可是隨著現代 JavaScript 模塊化的出現，我們突然發現：在模塊中是沒有直接的全局對象的！每個模塊都擁有自己的作用域和獨立的上下文，不再像過去那樣可以隨時訪問全局環境。

于是，開發者們爭論了好久：在不同的環境中，究竟該如何統一訪問這個“全局對象”呢？

解決方案就是： globalThis。這是一個新出現的全局對象，它能在任何環境中都能訪問到，無論是瀏覽器、Node.js，還是其他 JavaScript 執行環境，globalThis 都是全局對象的標準代表。

就像是你在不同的城市工作，常常會遇到不同的“老板”。在瀏覽器中，你的老板是 window，在 Node.js 中是 global，但是當你進入“跨國公司”后，終于有了一個統一的老板 globalThis，不管你身在何處，都能找到它。雖然它的名字聽起來有些“怪異”——globalThis，但它確實是跨環境的“萬能鑰匙”。

不過，這個萬能鑰匙其實還不太常用。大多數時候，我們還是習慣使用 window 或 global 來訪問全局對象，特別是在傳統的瀏覽器或 Node.js 中。盡管如此，globalThis 的出現無疑為跨平臺開發提供了便利，確保了代碼的兼容性。

7. 數字其實是“假”數字

你以為數字是數字，對吧？在 JavaScript 中，數字可不完全是“真實”的數字。它們是基于 IEEE 754 標準的浮動小數點數。這個標準雖然很強大，但也導致了一些非常搞笑甚至“不可思議”的數學錯誤。

比如，看看這段代碼：

console.log(0.1 + 0.2 === 0.3); // false
console.log(0.1 + 0.2); // 0.30000000000000004

為什么 0.1 + 0.2 并不等于 0.3？看起來簡單的數學運算，結果居然是“假的”！這是因為 JavaScript 采用的是浮動小數點數表示數字，而浮動小數點數不能精確表示所有的十進制小數。就像你在一塊金條上用尺子測量，尺子有限制，測出來的數據永遠不可能完全準確。尤其是當數字需要被轉換或四舍五入時，就會出現像 0.30000000000000004 這樣的“誤差”。

可以把這個問題想象成你買了一瓶水，水瓶上標明容量是 500 毫升，但實際上每次倒水時，總是多出一點點，怎么倒也倒不出精確的 500 毫升，最后可能會得到 499.999 毫升——這就是計算機世界中的“浮動小數點誤差”。

為什么這對你很重要呢？如果你在做財務、賬單、科學計算等對精度要求非常高的工作時，可能會遇到很多這種“意外”錯誤。你可能會發現，精確到小數點后幾位的計算總是跟你預期的不一樣。比如會出現以下這種情況：

let total = 0;
for (let i = 0; i < 10; i++) {
  total += 0.1;
}
console.log(total); // 0.9999999999999999 而不是 1

這就是為什么會計人員盡量避免使用 JavaScript 的原因——你可不想讓系統里的財務計算因為這樣的小數點誤差而出問題，對吧？

解決方案是什么呢？如果你需要進行精確的數學運算（比如金融應用），你可以使用一些專門的庫（如 BigDecimal 或 Decimal.js），這些庫能幫助你處理高精度的數字運算，避免這種浮動小數點帶來的困擾。

8. 默認參數有自己的作用域

有時候，JavaScript 會讓你感覺像在玩“潛伏的代碼游戲”。比如，默認參數的作用域，聽起來似乎很簡單，但實際上它會給你帶來一些非常“出人意料”的行為。

來看看這段代碼：

function show(x = 5, y = x + 1) {
  const x = 10; // 錯誤！x 已經在參數作用域中定義了
  console.log(y);
}
show();

這段代碼出錯的原因是什么？當你定義函數的默認參數時，這些參數會創建一個獨立的作用域。換句話說，函數內部的默認參數會形成一個“局部”作用域，而與函數主體的作用域完全分開。因此，盡管你在參數中已經定義了 x（并給它賦值為 5），在函數內部再定義 x 變量時，JavaScript 會認為你是在重復定義這個變量，從而報錯。

為什么會發生這種情況呢？可以把它想象成，你在一個小鎮上設立了兩個行政辦公室，一個負責管理全鎮的事務，另一個則只管理鎮里的某個特定區域。默認參數就像是那個“區域管理辦公室”，它的管理區域與整個鎮的事務（即函數主體）是完全分開的。所以，當你在“區域管理辦公室”內設定了 x = 5 時，它和函數主體中的 x 并不共享同一個空間。如果你在鎮上的其他地方再定義一個 x，自然就會沖突。

這個特性為什么值得注意呢？這個行為可能會讓你非常困惑，特別是在你想使用默認參數和其他變量時。默認參數的作用域是獨立的，這意味著在定義默認值時，參數不會直接訪問函數內部定義的變量，這可能會導致一些意外的錯誤。

9. with 語句是個“時間膠囊”

在 JavaScript 中，有一個曾經被廣泛使用的語句——with，但如今它已經幾乎沒人用了。它不僅讓人困惑，還容易出錯。with 語句可以擴展一個代碼塊的作用域，使其包含一個對象的所有屬性。

看看這個例子：

const obj = { a: 1, b: 2 };
with (obj) {
  console.log(a); // 1
  console.log(b); // 2
}

with 語句到底做了什么？它把對象 obj 的屬性提升到了代碼塊內部的作用域中。也就是說，在 with (obj) 內，你可以像訪問普通變量一樣直接訪問對象 obj 的屬性。對于這段代碼，a 和 b 都是 obj 的屬性，但通過 with 語句，你無需通過 obj.a 或 obj.b 來訪問它們。

問題出在哪兒呢？雖然看起來 with 語句可以減少代碼的冗余，但它卻制造了很多問題，尤其是在調試和理解代碼時。因為 with 會影響作用域鏈，造成一些不明確的情況，容易導致意外的錯誤。例如，如果在 with 語句的代碼塊內存在和對象屬性同名的局部變量，就會發生沖突，甚至導致代碼的執行結果出乎意料。

這種模糊的作用域問題讓調試變得異常困難，就像你在迷霧中試圖找尋一條明確的道路。程序員可能會因為 with 語句而花費大量時間去排查問題。

為什么 with 語句現在幾乎沒人用呢？現代的 JavaScript 開發者幾乎避免使用 with，它在 ECMAScript 5 中被嚴格模式（strict mode）完全禁用。雖然它仍然存在于語言中，但因為它容易引發錯誤并且不易調試，基本上已經成為了過時的產物。

所以，如何避免 with 的困擾呢？最簡單的辦法就是不使用 with。你完全可以通過直接訪問對象屬性來實現相同的效果：

const obj = { a: 1, b: 2 };
console.log(obj.a); // 1
console.log(obj.b); // 2

這樣，不僅能避免 with 帶來的作用域混亂，也能讓你的代碼更易讀、易維護。

10. 注釋可能會讓你的代碼崩潰

在 JavaScript 中，注釋本來是用來幫助我們理解代碼的對吧？然而，JavaScript 竟然有一種奇怪的注釋方式，它來自 HTML，能讓你在瀏覽器中安心使用，但如果不小心，竟然會導致代碼崩潰！

看看這個代碼例子：

<!-- console.log("Hello"); // 在瀏覽器中正常工作 -->
console.log("Goodbye"); // 在 Node.js 中會報錯 SyntaxError！

怎么回事？在 HTML 中，我們常用 <!-- --> 來包裹注釋，但當你把這段代碼放進 JavaScript 文件里時，<!-- 和 --> 看起來像是注釋標記，但實際上，它們會被解釋成單行注釋的開始符號。更奇怪的是，這種“HTML 注釋”的方式在不同的環境下表現完全不同——在瀏覽器中，<!-- 被當作一個普通的注釋處理，代碼不會出錯；但在 Node.js 環境中，它卻會被當成語法錯誤，導致你的代碼崩潰。

為什么會出現這種情況？這種行為的根源其實在于歷史。早期，JavaScript 和 HTML 是混雜在一起的。在 HTML 中，我們用 <!-- 來表示注釋，而在 JavaScript 中，這種標記被意外地當作了合法的語法。這種兼容性問題在不同環境中表現出來的方式不同，導致開發者在不同平臺間使用 JavaScript 時，可能會遇到這些奇怪的陷阱。

這個問題會帶來什么麻煩？如果你在一個 JavaScript 文件中不小心使用了 HTML 樣式的注釋（<!--），而這個代碼被加載到 Node.js 環境下，直接就會出現 SyntaxError。而瀏覽器在遇到這類注釋時，卻不會出錯。這會讓開發者在不同環境下調試時，浪費很多時間去尋找“看不見”的錯誤。

怎么避免這個問題呢？最簡單的解決辦法是，始終使用標準的 JavaScript 注釋方式：

• 單行注釋：// 這是單行注釋
• 多行注釋：/* 這是多行注釋 */

永遠避免使用 HTML 樣式的注釋 <!-- -->，這樣能確保你的代碼在不同的執行環境中都能正常工作。

// 正確的注釋方式
console.log("Hello");  // 這是一個正常的注釋

結束

JavaScript 就像你朋友圈里的那個“古靈精怪”的朋友，雖然有點混亂、復雜，但總能帶給你無窮的樂趣。即便你覺得自己已經對它了如指掌，但它總有一些新奇的“怪癖”會在不經意間讓你大吃一驚。

每當你遇到一個自信滿滿的 JavaScript 專家時，不妨拋出這些“奇怪的事實”，看看他們的表情是不是瞬間凝固，眉頭微挑。你會發現，連老牌的開發者也有可能被這些“意外的驚喜”逗得啞口無言。

編程的世界總是充滿了挑戰與樂趣，而 JavaScript 就是那個永遠讓你保持好奇心的“魔法盒子”。它有時讓你抓狂，但更多的時候，它卻讓你充滿成就感。繼續探索，繼續編碼吧！