企业官网建设流程全解析

1. 隐式转换的"幕后黑手"：原来JS背地里调用了这三个方法

做前端开发的朋友应该都有过这种经历：明明写的是if (a == b)，结果在某些数据组合下就是不符合预期；明明一个数组和数字相加，结果冒出一串莫名其妙的字符串；明明null、undefined、0、''、false看起来差不多，用==一比较却各有各的脾气。这背后起作用的就是 JavaScript 的隐式类型转换，也就是 JS 引擎在运算过程中，背着我们偷偷把一种类型转成另一种类型的行为。

很多教程喜欢直接甩一张"JS类型转换规则大表"，让你死记硬背。但说实话，那张表密密麻麻十几行，今天背完明天就忘，遇到个新组合还是抓瞎。我个人的经验是，想真正搞懂隐式转换，得先搞懂 JS 底层到底是怎么做转换的，也就是 ECMAScript 规范里定义的那三个核心内部方法：ToPrimitive、ToNumber、ToString。所有隐式转换的坑，归根结底都是这三个方法在不同场景下被触发导致的。

1.1 ToPrimitive：万物皆可"原值化"

先说ToPrimitive，这是隐式转换的第一步，也是很多人完全不了解的一步。它的作用是把一个值（尤其是对象）转成对应的原始值（primitive value），也就是string、number、boolean、null、undefined、symbol这几种。规范里它有两个可选参数，一个是hint（提示），另一个是可选的对象转换方法，但在实际引擎实现中，hint的取值就三种："string"、"number"、"default"。

当引擎需要把一个对象转成原始值时，会先检查对象身上有没有Symbol.toPrimitive方法，如果有就直接调用；如果没有，就依次找valueOf和toString。查找顺序取决于hint的值：

• hint是"number"：先调用valueOf，如果返回值不是原始类型，再调用toString，如果还不是原始类型，就抛TypeError。
• hint是"string"：先调用toString，如果返回值不是原始类型，再调用valueOf。
• hint是"default"：大多数情况下的表现和"number"一致，但个别类型（比如Date）会表现为"string"的查找顺序。

这个逻辑用大白话讲，就是 JS 在问一个对象："你要变成原始值了，你打算怎么变？"如果对象自己定义了Symbol.toPrimitive，那就听对象的；否则就按照默认的"找方法"流程来。对于普通对象，默认的valueOf返回对象本身，toString返回"[object Object]"，所以大部分对象在隐式转换时最终都会变成"[object Object]"这个字符串。这就是为什么你写{} + []会得到"[object Object]"而不是一个数字。

1.2 ToNumber：非数字转数字的"标准答案"

ToNumber的作用是把一个值转成数字。它有几个比较关键的规则：

• undefined转成NaN
• null转成0
• true转成1，false转成0
• 字符串会去掉首尾空白后尝试解析，空字符串转成0，解析不出来的转成NaN
• 对象会先走ToPrimitive，并且hint为"number"，拿到原始值后再按上述规则转数字

这里有个特别容易踩的坑：Number([])和Number([5])的结果完全不一样。[]先被ToPrimitive转成空字符串''，然后空字符串按规则转成0；而[5]先变成'5'，再转成数字5。如果你拿[] == false去比较，会得到true，就是因为[]被转成了0，而false也被转成了0，两边相等。很多人在这个坑里徘徊很久，其实就是没搞懂[]变成原始值时先经历了一次字符串化。

1.3 ToString：字符串化也不是把所有东西直接拼起来

ToString的规则相对直观一些：数字转成对应的字符串，布尔值转成'true'或'false'，数组会取所有元素用英文逗号拼接成字符串，普通对象则同样走ToPrimitive（hint为"string"），最终得到'[object Object]'。

但这里有一个让很多人困惑的地方：[1, 2] + [3, 4]的结果是什么？答案是'1,23,4'。因为数组在加法运算中触发了ToPrimitive，默认hint为"default"，按valueOf->toString的顺序，数组的valueOf返回自身（不是原始值），于是继续调toString，得到'1,2'和'3,4'，接着两个字符串相加，最终得到'1,23,4'。你随便拿个计算器按一下都算不出这个结果，但 JS 就能给你搞出来。

这三个内部方法明白了，再去看各种隐式转换的坑，会发现它们不再是零散的知识点，而是一个有逻辑的体系。下面我把最常见的踩坑场景一个个拆开讲，每个都会告诉你"为什么"，而不是只给结论。

2. 宽松相等（==）的隐藏规则表：这个古老的坑，建议直接放弃治疗

==可能是隐式转换里被吐槽最多、也最容易让人翻车的操作符。它的规则在小数点前面数都数不清，而且不同浏览器的历史实现还有过差异（当然现在按 ES 规范已经统一了）。我直接把它最核心的几个规则总结出来，尽量口语化，方便你理解和记忆。

2.1 类型不同时，== 的转换决策树

当==两边的类型不相同时，引擎会按照这样的顺序判断：

1. 如果一个是null，一个是undefined，直接返回true。
2. 如果一个是数字，一个是字符串，把字符串转成数字再比较。
3. 如果其中一方是布尔值，把布尔值转成数字（true为1，false为0）再比较。
4. 如果一个是对象，另一个是数字或字符串，把对象用ToPrimitive转成原始值再比较。

这里第二和第三条连起来会产生一个经典的坑：'0' == false的结果是什么？按规则，先处理布尔值，false变成0，然后一边是字符串'0'、一边是数字0，再把字符串'0'转成数字0，两边都是0，于是结果是true。你以为是字符串和布尔值的比较，实际上绕来绕去变成了0 == 0，仿佛两个完全不相干的东西在泥地里打了一圈滚，最后滚成了同一个形状。

再比如null == 0，按第一条规则，null只和undefined相等，和数字0不相等，结果是false。但null >= 0的结果却是true。因为>=里面会先把null转成数字0再比较大小。宽松相等和大小比较的转换策略完全不同，这是很多人调试半天也找不到原因的关键。

2.2 最经典的几组"撞鬼"组合

我把实际开发中最容易出现的几组比较结果直接列个表，你收藏起来当速查表用就行：

看到[] == ![]是true，很多人直接懵了：一个空数组和一个"取反后的空数组"怎么会相等？实际上右边![]因为数组是对象、对象转布尔值永远是true，所以![]是false。左边[]按对象转原始值的流程变成空字符串再变成0，右边false也变成0，于是相等。整个过程看似鬼畜，但每一步都严格走在规则里。

2.3 官方文档里的权威说明和我的建议

MDN 上关于==的文档其实写得很清楚，它官方给出的建议就一句话：不要使用宽松相等，除非你明确知道自己要处理的是null和undefined的兼容判断。实际上，我在代码审查中看到==就条件反射要求改掉，因为任何使用==的场景，几乎都可以改写为更明确的方式。

比如判断一个变量既不是null也不是undefined，直接用value != null其实是个广为人知的例外技巧，但这需要团队每个人都理解这条规则，否则下一个人改代码时很容易理解错。所以我更推荐的做法是：明确写成value !== null && value !== undefined，虽然啰嗦一点，但不会引起歧义。

在真实项目里，我遇到过最离谱的一次线上 bug，就是后端返回的字段值有时候是数字0、有时候是空字符串''、偶尔还是false，前端的判断逻辑写的是if (value == false)，结果三个值全部命中了这个条件，但产品上这三个值的含义完全不同。后来改成if (value === 0)、else if (value === '')、else if (value === false)分开处理才彻底解决。用===的最大好处不是性能，而是让每个判断都变得可预测、可读、可维护。

3. 加法运算符 + 的双重语义：它既是数学相加，也是字符串拼接，关键看谁先"变节"

在所有运算符里，+是唯一一个"身兼两职"的：它既能做数学加法，又能做字符串拼接。这个双重身份是无数 bug 的源头。如果你去查 ECMAScript 规范，+运算符的计算逻辑是：先对两个操作数分别做ToPrimitive（默认 hint），只要任何一个操作数经过转换后是字符串，就把两个都转成字符串做拼接；否则两个都转成数字做加法。

关键就在这个"任何一个操作数是字符串"上。JS 并不像某些语言那样"左右类型一致才算拼接"，而是哪怕右边是个数字，只要左边是字符串，就整个变成拼接操作。

3.1 加法的"传染性"：一个字符串毁掉一次加法

我举个例子：'1' + 2 + 3的结果是'123'，而不是6或'15'。因为运算顺序是从左到右，先算'1' + 2，左边是字符串，于是变成字符串拼接，得到'12'，再拼上3，得到'123'。这个传染性是向左向右都会扩散的，只要链中任何一个操作数是字符串，整条链都会变成拼接。

但注意：1 + 2 + '3'的结果是'33'。因为先算1 + 2，两个都是数字，正常数学相加得到3，然后3 + '3'，右边出现字符串，最终拼接成'33'。这个"从左到右逐步计算"的细节很多人忽略，导致在写长表达式时抱着"反正最后会转成数字"的侥幸心理，结果被字符串半路劫持。

3.2 数组、对象加入加法混战的结果

数组参与+运算的案例，前面已经提过[1,2] + [3,4]得到'1,23,4'。对象参与加法时，行为同样出人意料。比如{} + []，在一些浏览器控制台里你甚至看不到正确结果，因为语句开头的{}会被解析成代码块而不是对象字面量，这属于语法解析层面的坑，不是类型转换本身的问题。但如果你写({}) + []，结果就是'[object Object]'拼接空字符串，得到'[object Object]'。

更有意思的是({}) + {}，结果是'[object Object][object Object]'。因为两个对象都转成了'[object Object]'。那({}) + [0]呢？对象转成'[object Object]'，数组转成'0'，拼接结果就是'[object Object]0'。你是不是觉得这些结果很无厘头？但实际上它们都非常符合规则，你只要记住"对象在加法里默认变成'[object Object]'"，这些结果几乎都能靠推理推出来。

3.3 这年头为什么还要在意加法字符串化的坑

现在的 ES6+ 已经提供了模板字符串，字符串拼接可以直接写成`${a}${b}`，比用+拼字符串清晰得多。但实际开发中仍然会有大量场景绕不开+，比如把数字转成字符串的经典小技巧value + ''，就是因为+遇到字符串就会把另一边也转成字符串，这个特性在追求极致代码简洁时确实好用。但要小心：如果你是想把用户输入的'1'转成数字1，用'1' - 0可以，用'1' * 1可以，用+'1'也行，但用'1' + 0会得到'10'。这三个一眼看上去差不多的写法，结果天差地别。

我遇到过最实际的场景是格式化金额的时候，从后端拿到的字符串'100.5'，想把它加10再展示，直接写value + 10，结果输出了'100.510'，页面还看不出毛病，直到运营对账才发现金额多了。后来每次做数值计算前前端都会先显式调一次Number()或者parseFloat()，把类型锁死再运算。这种坑不是逻辑复杂，而是"隐式"两个字让人防不胜防。

4. 除了加法之外的其他运算符：减、乘、除、比较、位运算的"强行转数值"

+是隐式转换的重灾区，但其他运算符也不是省油的灯。好在它们有一个共同点：除了+之外，-、*、/、%、>、<、>=、<=、&、|、^、<<、>>`` 等等，通通都只认数字。也就是说，这些运算符会想尽办法把操作数转成数字，转不出来就给你一个NaN`。

4.1 减乘除的转换逻辑：全都先转数字再说

举个最简单的例子：'5' - 2的结果是3，'5' * '2'的结果是10。字符串在这里被直接转成了数字。如果转不成数字，比如'abc' - 2，结果就是NaN，而且这个NaN还会一路传染到整条计算链上，'abc' - 2 + 3的结果也是NaN，哪怕最后一个3是个正常数字。

-运算符还有个特殊用途：一元负号-只对一个操作数生效，也可以触发 ToNumber。所以-[1]会得到-1（数组转成'1'再转数字1），-[]会得到-0（你没看错，负零也是 JS 的一个合法数值），-[1,2]得到NaN。这些冷知识虽然平时用不上，但在关键时刻能帮你排查那些"莫名其妙出现-0或NaN"的 bug。

4.2 比较运算符的类型陷阱：字符串比较 vs 数字比较

比较运算符>、<等有一个隐藏规则：如果两个操作数都是字符串，就按字典序（Unicode 码点）逐字符比较；否则转成数字再比大小。这个规则看起来简单，实际上坑非常多。

比如'10' < '9'的结果是true，因为你以为是数字比较10 < 9所以是false，但字符串比较时是按字符逐个比的，先比第一位字符'1'和'9'，'1'的 Unicode 码点是 49，'9'的是 57，49 小于 57，所以整个表达式的值是true。如果按照数字大小，10肯定大于9，所以这个结果对很多人来说非常反直觉。

更麻烦的是混合类型比较：'10' < 9呢？因为有一个操作数不是字符串，于是两个都转数字，'10'转成10，10 < 9结果是false。如果你想对用户输入的版本号做比较，比如'1.10' < '1.9'，字符串比较会得到错误结果，必须先拆成数字一个个比，或者用专门的库处理。

4.3 NaN 的"六亲不认"特性：全宇宙唯一一个不等于自己的值

NaN是所有隐式转换失败后的兜底结果。'abc' * 1是NaN，undefined + 1是NaN，[1, 2] - 3也是NaN。NaN有一个极其反直觉的特性：NaN == NaN是false，NaN === NaN也是false，因为它"不等于自己"。所以判断一个值是不是NaN，不能写value === NaN，而应该用Number.isNaN(value)或全局的isNaN(value)。

这里还有个新旧 API 的区别值得说一下：全局isNaN会先把参数转成数字，所以isNaN('abc')是true，因为它试着把'abc'转数字没成功；但isNaN('123')是false，因为能转成数字。而Number.isNaN不会做类型转换，只有参数本身就是数字且等于NaN时才返回true，所以Number.isNaN('abc')是false。如果你拿全局isNaN去判断一个不确定类型的变量，很容易把"能被转成数字的字符串"误判为"不是 NaN"，从而放走真正的错误值。

4.4 位运算的"截断效应"：32位有符号整数强制转换

位运算符|、&、^、<<、>>不仅会做 ToNumber，还会额外把数字转成 32 位有符号整数，再执行位运算。这个转换会带来"截断"效果：小数部分被直接丢弃，而不是四舍五入。所以1.5 | 0的结果是1，-1.5 | 0的结果是-1，2147483648 | 0的结果是-2147483648（因为超出了 32 位有符号整数范围）。

在社区里，| 0被当作"快速取整"的 hack 用了很多年，性能确实比Math.floor快一点，但代价是只能处理 32 位范围内的数字，超出范围就出问题。而且| 0对负数的行为是向零取整，而Math.floor是向下取整，两者在负数场景下结果不同。如果你对可读性、正确性有要求，老老实实用Math.trunc或Math.floor，不要为了那点性能埋雷。

5. 从"看懂坑"到"不踩坑"：我的防御性编码实战清单

讲了这么多规则和案例，如果只停留在"我知道有坑"的层面，那还不够。真正有价值的是把这些坑转化为一套可落地的编码防御方案。这是我多年开发里整理出来的实操清单，分享出来供你直接参考。

5.1 写代码时强制使用严格相等，但留一个例外

不用==、改用===是最基础的防御手段。我一般会在项目的 ESLint 配置里直接加上一条规则：

{ "rules": { "eqeqeq": ["error", "always", { "null": "ignore" }] } }

这样配置的意思是：强制要求使用===和!==，唯一例外是判断value != null时允许使用宽松不等，因为双等号在这种情况下可以同时排除null和undefined，并且不会触发其他类型转换，相对安全。

配好这条规则之后，代码里所有==都会在 CI 阶段直接报错，从机制上杜绝隐式转换的风险。很多人会觉得"用===有点啰嗦"，但实际敲起代码来区别并不大，而避免的 bug 却可能是致命的。

5.2 边界判空统一走显式函数

我见过很多同学在判空时喜欢写if (!value)，这个在布尔语境下会自动把 value 转成布尔值，导致空字符串、0、false、null、undefined、NaN全部命中。如果业务上"0 也是一个合法值"，那么这种写法就会把合法的0也误判为空值。

建议的做法是封装一个统一的判空函数，把"什么算空值"定义清楚：

function isBlank(value) { return ( value === null || value === undefined || (typeof value === 'string' && value.trim() === '') || (Array.isArray(value) && value.length === 0) ); }

实际业务中，"数字 0"通常不算空，但这要根据场景微调。关键在于把判空逻辑集中起来，而不是散落在各个 if 里，这样即使后续要调整"空值"的定义，也只改一处。

5.3 需要转数字时，不要依赖隐式转换

有几种常见写法本身没有问题，但建议统一成显式写法，方便代码阅读和 review：

• +value改成Number(value)
• value * 1改成Number(value)
• value - 0改成Number(value)

我承认+value写起来很爽，尤其在一串表达式里，它能少打好多字。但问题在于，不是所有人都清楚一元加号会触发 ToNumber，而且代码里混用+value、value - 0、value * 1三种形式，会让后来者怀疑你是不是有什么偏好在里面。统一成Number()后，任何人在代码里看到意图都一目了然。

反过来，需要转字符串时，我也建议优先用String(value)或模板字符串，而不是value + ''。因为模板字符串还能顺便做插值，可读性更好，而且不会让人担心是不是在做数学运算。

5.4 面对"神秘结果"时的排查套路

万一线上还是出现了隐式转换导致的诡异结果，我给你一套排查路数：

1. 把出问题的表达式原样复制到浏览器控制台，逐步拆分，每次只算一步，看引擎给出的中间值。
2. 在每一步里使用typeof查看变量类型，确认有没有变量从其他地方传入了预料之外的字符串。
3. 打开 DevTools 的 Sources 面板，在表达式位置打断点，用 Watch 面板分别查看两个操作数的当前值和类型。
4. 如果问题多次复现，可以将可疑的转换点用显式转换替换，看结果是否变化，用二分法定位问题链路。

我遇到过一个真实案例：一个表格页的搜索功能，输入"10"之后结果一直是空的，排查了半天发现比较逻辑里写的是item.value >= inputValue，前端从输入框拿到的inputValue永远是字符串，而item.value是数字。字符串'10'和数字比较时，引擎会把两边都转数字，正常来说这样也能比。但问题是某个item.value是undefined，转数字成了NaN，NaN >= '10'的结果是false，那一行数据就被过滤掉了。这个 bug 根因其实是数据本身有问题，但隐式转换把"数据问题"伪装成了"比较逻辑问题"，让人绕了很久。

5.5 用 TypeScript 和 JSDoc 给 JavaScript"上保险"

如果你在的项目有条件引入 TypeScript，那是再好不过的防御手段。TS 的静态类型检查能在编译阶段就拦截掉大量隐式转换相关的低级错误。比如一个变量声明为number，你把它传给期望string的函数时，编译器直接报错，根本轮不到运行时出 bug。

但很多老项目没法一刀切上 TS，这时候可以考虑用 JSDoc 配合// @ts-check来给普通 JS 文件增加类型检查能力。TS 编译器本身就能读 JSDoc 的类型标注，你只要在文件头部加一行// @ts-check，IDE 就会根据注释里的@param {number}这类标注帮你检查类型问题。成本很低，收益却立竿见影。

从长期维护的角度看，让"类型转换"变成代码里显式的一部分，比记住所有隐式转换规则可靠得多。毕竟人脑的记忆容量有限，今天背完==的规则，下周可能就忘了一半。而代码里的===和Number()，是写一次就能一直生效的。

6. 还有两个容易忽略的隐式转换场景：if 条件和模板字符串的陷阱

做完整套防御方案之后，还有两个边缘场景需要补充，它们虽然不涉及运算符，但同样属于隐式转换的范畴，在开发中经常遇到。

6.1 if 语句的"布尔化"规则：哪些值会掉进 false 阵营

在if、while、for的条件表达式里，JS 会把条件值强制转成布尔值。这里有一个"falsy（假值）清单"：

• false
• 0（以及-0）
• ''（空字符串）
• null
• undefined
• NaN
• 0n（BigInt 的零）

除了这七个值之外的所有值，转成布尔值都是true，包括你意想不到的：'false'字符串、[]空数组、{}空对象、'0'字符串、函数、Symbol等等。

这就是为什么if ('0')会进入分支，而if (0)不会。也是为什么你写if (value)来判断"有没有值"时，value为0或空字符串会直接被跳过。如果你只是想判断"这个变量不等于 null/undefined"，用if (value != null)是安全的（这是上面提过的双等号例外），但如果你想判断"有没有一个真值"，就要想清楚0和空字符串在业务里的含义。

6.2 模板字符串的隐式字符串化：对象嵌套对象时的"沼泽"

模板字符串${value}会把 value 隐式地转换成字符串。普通变量还好，但当 value 是数组或对象时，转出来的内容经常不是你想的。比如${[1,2,3]}得到'1,2,3'，这还能接受；但${ {a: 1} }得到的是'[object Object]'，你期望的'{"a":1}'根本不会出现。

如果想要可读的对象字符串，必须用JSON.stringify(value)，或者JSON.stringify(value, null, 2)得到带缩进的格式。注意JSON.stringify也有自己的坑：函数、undefined、Symbol属性的值会被忽略，NaN和Infinity会被转成null，这在调试时容易造成误导，但至少它不会给你一个'[object Object]'让人抓狂。

6.3 显式转换时也要当心的一个隐性细节：parseInt vs Number

显式转换听起来安全，但也藏着一个暗坑：parseInt和Number对字符串的解析策略不同。parseInt('100px')返回100，因为它从左到右解析，遇到非数字就停；Number('100px')返回NaN，因为它要求整个字符串都是合法的数字表示。

所以如果你确定字符串应该是一个完整数字，用Number更严格、更能暴露问题；如果字符串可能携带单位、需要截取数字前缀，用parseInt/parseFloat更合适。两者各有用武之地，关键是搞清楚各自的边界行为。此外parseInt还推荐写全第二个参数，即parseInt(value, 10)，避免在极少数历史环境里把'08'这类字符串按八进制解析。

我在处理用户输入的金额、数量、电话号码等数据时，一律用Number，因为用户输入不应该包含"100px"这种东西，一旦包含，我宁可要NaN弹个错误提示，也不能静默截断成100导致数据错误。

7. 官方文档与资料入口：别只背二手结论，学会看规范原文

文章最后，我把一些权威文档入口和个人阅读建议整理出来。标题里提到了"附官方文档"，那就把文档地址和使用方法一起说清楚，方便你自己查证。

7.1 最值得看的几份官方资料

• ECMAScript 语言规范（ECMA-262）：这是 JS 语法和语义的最终权威。规格文档里的"Abstract Operations"章节定义了ToPrimitive、ToNumber、ToString、ToBoolean等内部方法。初次看规范会有点吃力，但你可以只看与类型转换相关的几个小节。
• MDN JavaScript 参考：MDN 的运算符页面和行为说明非常详尽，而且每个运算符页面的"描述"里通常都有专门讲类型转换的部分。比如加法运算符的官方页面就明确写了"如果不涉及字符串，则全部转为数字相加"。
• JavaScript 类型转换相关的 ECMAScript 表格：很多技术博客都整理过"隐式转换规则速查表"，但切记要去对照 EC-262 原文验证，不要盲信二手信息。这几年有个印象挺深的事：早期网上流传的一份规则表把[] == 0标成false，但实际是true，就因为作者抄错了。所以凡是要背规则，优先找官方的说明。

7.2 怎么查一个运算符的精确转换行为

我自己的方法很简单：打开 MDN 对应运算符的页面，直接搜"Type"或者"转换"关键词，通常能找到它的算法步骤。如果你想追根究底，再顺着去 ECMA-262 的规范找该运算符所属的求值章节。比如加法运算符在规范里的章节标题是12.8.3 The Addition Operator (+)，里面用伪代码写了完整的求值流程，包括什么时候调ToPrimitive、什么时候调ToString、什么时候调ToNumber。

把规范和 MDN 对照着看，你会发现很多困惑其实只是对规则理解不完整。而一旦你具备了自己查规范的能力，下次遇到任何类型转换问题，都能在几分钟内从官方文档里得到准确答案，而不是在搜索引擎里翻来翻去。

7.3 给新手的自学路径建议

如果你刚接触 JavaScript 不久，我建议按这个顺序学习隐式转换：

1. 先把===和!==作为默认符号记牢，强制自己不用==。
2. 然后专门花一个下午，把ToPrimitive、ToNumber、ToString三条规则读透，配合控制台里的Number()、String()、Boolean()实验。
3. 接着亲手把这些"撞鬼组合"在控制台里打印一遍：[] == false、[1] == 1、'10' < '9'、({}) + []、NaN === NaN，每个都按上面讲的规则推导一遍结果。
4. 最后再做一个小项目，强制要求自己所有类型判断、数值转换、字符串拼接都写成显式方式，坚持一两周，隐式转换的坑基本就不会再找上你了。

这个过程大约需要两到三天时间，投入产出比极高。因为隐式转换是"会者不难、难者不会"的东西，一旦建立了体系化的认识，以前那些"诡异行为"就全都变成了"意料之中"。

我自己早期做前端时，也曾经被==坑到怀疑人生，后来把 ECMAScript 规范啃了一部分，才发现在这块付出的时间非常值得。它不但让我写代码时更有把握，在帮别人 review 代码时也能迅速指出潜在问题，而不是凭感觉说"这里好像有点不妥"。希望这篇文章也能帮你把这块短板补上。