如果编程语言是一个大家庭，那么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 就是那个永远让你保持好奇心的“魔法盒子”。它有时让你抓狂，但更多的时候，它却让你充满成就感。继续探索，继续编码吧！
