你们 js 用过双等号吗

无脑===

val == null 应该是 js 基本常识技能吧？那判断为 null 你是怎么做的？ val === null || val === undefined?

隐式转换罢了

十多年前我用这个当面试题来着

@june4 #2 直接 if (value)判断是否有值

@june4 啊？判断 null 还要 val == null 么？直接 if (val) 不行么？

@ethusdt 他的意思是当判断是否为 null 时只需要==即可。

不知道啊 ，我用 ts

十几年前好像都是==

隐式转换设计的太复杂了，不同的类型，各种各样可能的 case ，用的时候很容易出现意料之外的问题

太麻烦了，容易出问题

@ethusdt if (val)当然不行，这个把 空串，0 之类的都算 false 了，很多时候就是判断是空值(null)，不是没有值

坚决 === ，我同事曾经用 == 找了 1h 的 bug ，然后叫我帮忙看看哪里出了问题

if(!!val)

完全不适用 ==，只用 ===
不直接使用 if(a)，全部包装成基于业务语义的 isNull isEmpty isValid isGood...

无脑 === ，手动转类型

> 甚至可以这么用: if (a == 0) { ... }, 这里当 a 是 0 / "" / false 时候都成立。

我觉得代码中就不应该出现 a 有可能是 0 / "" / false 的情况……

如果需要展示的情况，0 需要展示，而 "" NaN null undefined 大概率要展示成 -

@june4 #12 哦，我明白了，就是判断某个值是 null ，而非 0/空字符串/false 之类的具体值。但是业务场景下，这些都是一样效果，用户没有填一个值那就给默认 false/0/空字符串，除非有特殊需求默认成其他值。

我想到的就这点了。能再举几个例子场景么。

@masterclock 是个提升代码可读性和健壮性的好习惯

卧槽,我一直偷懒用的==,确实遇到 0 和 false 和 null 的问题

总有人说 JS 简单 结果在双等和三等上面都分不清楚适用场景，，，也分不清 falsy value 和 nullish value
真特么菜。

JS 是个由于初期设计太过垃圾而导致引入过多不必要的复杂性的语言 有大量细节需要记忆 由于不规范导致的灵活性让人可以玩花活 写出来的代码难读难维护 反直觉的设计让不熟悉这门语言的人踩很多坑 很多使用者根本意识不到自己在干什么 看看上面的回复就知道了
从改善这些缺点来讲 TS 是大救星

ESLint 关于===的规则（"eqeqeq"）里，有个选项开关就是允许==null 。

此外早年流行的几个 JS 代码规范，StandardJS, Airbnb, Google Style Guide, 全都是“禁止使用==，但==null 例外”，算是通行做法。

@maplezzz 不是设计得太复杂了 而是当初压根没有设计 完全 PL 外行拍脑袋搞出来的垃圾

@shintendo 我原来就是遵守这个规范 但现在感觉#15 的做法更好 完全避免 JS 的那些隐式语义 包成 util 不费劲而且一目了然 让所有人都能读懂意图

@crocoBaby 这还能偷懒吗，出 bug 了就老实了

@craftsmanship #23 是的，但是这些设计问题变成了面试题来拷打从业者……

@tonytonychopper ===和== 甚至面试都不应该问，完全没有使用 == 的理由，默认===就行。

@tonytonychopper 怎么说呢 为了八股而八股的话 完全没必要 属于做题大国的坏习惯 但八股里考察的点 其实是有意义的 只是以八股的形式出现很恶心
比如隐式转换就能看出使用者对 JS 的熟悉程度 也是非常常见的坑点 想全记住规则并不现实 因为确实太复杂 但这个都不了解的话 那完全不合格
然而所有这些在 AI 时代已经不重要了…

@meteor957 有 #24 已经提过了 再具体点说就是 唯一使用双等的场景 就是用来判断 nullish value
面试时值得问的点太多了 隐式转换确实不合适 因为这应该是 JS 基本功 默认是了解的

用的，因为有时候接口就是会返回 ‘0’

@GuguDan 坏习惯 这种应该 Number(val) === 0 而非偷懒使用双等的隐式转换
想玩花活？没问题 +val === 0
少打几个字母 让代码变得晦涩难读 有意义吗？完全没意义 但很多人这样写 显得自己很 6
这就是 JS

以前前端工程化没流行开的时候，只用`==`的人大把，甚至反而很多人都不知道`===`。特别是一些后端顺便写前端的人。
多亏了前端工程化和各种创建项目的脚手架以及开源项目里面用了 ESLint ，倒逼大家去学习一些规范。
说个我感觉很搞笑的事，以前看到有不少人搜 ESlint 报红怎么解决，最后的方案是卸载掉...

这种现在交给 AI 应该没什么难度吧

我刚入行做 cocos-js 开发的时候，根本不知道===这个东西，一直用== 直到出现了一个隐形 bug ，查了非常久才知道有==和===的问题，十年了，我都无法忘怀这个东西

@tonytonychopper 借机跟测试小妹说话

我去，开倒车

我只用 == 很少用严格===。
项目我一个前端没人管我。 == 能没问题的地方 === 一定没问题。=== 会出现问题的地方 == 可能反而没问题。
通常情况下只有会 string number 之类的在进行比较，其他一切比较情况都是写法有问题

@aloxaf 动态类型转换为 false 的我直接 if(a){} 了

小程序页面穿参会把 number 转成 string ，一般我想省事就用==，懒得再转了。

双等号就是邪修，TC39 委员会的人，也不能把双等号在项目里用明白 太复杂了！下一个维护项目的人，难道要在脑子里跑一遍所有场景下状态机 预判前人写的双等号可能要处理的业务逻辑？

用 a === b || (a !== a && b !== b)

我是邪修 我很常用 == 必要时候才 ===

大概是弱类型语言用的太多了 对==和===一般不会写出 bug

只有一种情况会用：判断是 等于或不等于 null 和 undefined 时。

@craftsmanship 不太懂，难道你说的这种场景用 === 做不到嘛，为啥是唯一场景，==只是更简洁吧。

我在想，反正基本上都是无脑===为什么 ES 规范，不直接将==表示===的作用呢，当然我是刚学前端的 JS 初学者

@akakidz 是的 所以 JS 心智负担很大

多数时候都不应该用==，但特殊情境下，手搓超短代码的时候可以靠这种隐式转换省一点空间，就用了

@meteor957 可能我表述得不太清楚 不是只有双等能做得到 而是说双等只在这种情况下值得使用

@ASHYWHISPER 当然是为了兼容性 怎么可能在语言的新版本里更改原来语法的语义呢 这就是所谓的历史包袱重

@craftsmanship 既然如此，=== 依然可以 cover 所有场景且没有太多成本。我刚刚说面试都不应该问的原因是不管是实际开发还是面试都应该默认遵守使用===的规则，当你使用==时本身就引入了不必要的心智负担。

@meteor957 是的 完全赞同

老项目里全是[==]，还好没有出过什么大问题，现在重构了，基本都是[===]

除 == null 或者 == undefined 这两种情况外，全使用 ===

eslint eqeqeq 规则有个 smart 模式

不用 怕别人看出我是前端仔

全是==也挺好

@TimPeake 噢不对，是用。不用 === 。
---------
之前很久了 某个群里 吹牛闲聊，发了 类似 xxxx === xxxx 这样的伪代码，结果群里立马有人回复，“你小子前端仔 ？”

我是直接设置 eslint 警告的，不接受==

现在回想起来以前学 js 。在没有 ai 的年代，简直是在历屎中遨游

肯定是用三等

早期很长一段时间用的 == 因为学编程的时候就是 = 和 ==。
后面业务写的多起来之后才慢慢改成 ===。一些地方该用 _.isNill 之类的就用，而不是自己去写空值判断逻辑。

隐式转换有些时候是好用，但是有一些时候会埋坑。

处理==null 这种问题的唯一正确方式是，if （ valid ）{}else{} 而不是 if （ unvalid ）{}

在我还没怎么写过 js 的时候我就听说过这个表格了：
https://dorey.github.io/Javascript-Equality-Table/

以至于后面真的写起来每次都胆战心惊...

@june4 #12 但 js 中的 null 更多应该指的是未赋值的对象，或者空对象，一般也就 val 是 object 时才会出现 null ，他为什么存在空串，0 的情况？ if(val)完全够用。js 只是没有强约束，但应该也没憨憨就一个变量，一直赋值不同类型值一路使用吧？

@aloxaf 我也觉得是这样，属实是过于担心了

@icyalala 哈哈，这种真值表其实还有 PHP 版的
https://github.com/sentientmachine/php_equality_charts

@SanjinGG 啊，你哪怕是用 ts,就没有见过这种类型 `number | null | undefined` ? 或 `string | null | ndefiend`

禁用==。同时也绝不使用 null, 一律 undefined

@craftsmanship "掌握"了语言设计上的两个 billion dollar mistake 然后沾沾自喜么

@Aliceeeeee 你需要增强阅读理解能力

确实有时候感觉双等号是不是方便点， 尤其奇葩项目中 userId 是 string|number 混用的，
但 AI 写的代码总是用三等号， 搞得我都不好意思要求双等号了，
不过我是纯 ts ，

只要你不用单等号，我都能接受。你要是像我同事一样用单等号做判断，那我就要放狗了

@gorvey 看一次笑一次哈哈

@gorvey 昨天刚遇到了，0.4 / 10000 ，出来结果是 0.39999...

@Aliceeeeee 同时 null 和 undefined 的语义是不一样的 这种 billion dollar mistake 你要不要了解下再写 JS ？

@june4 没见过，初始化大部分也是赋值空字符串，根本不会给 null ，undefined 也只有在开发阶段会出现，到最终上线根本不会让他是 undefined

自己写的代码不用，别人的代码逻辑简单的，能找到类型的就换掉。

没这个胆子用双等号。
顺便，对于你说的这种“判断是否不存在有效值”，我们一般直接!a

有一种情况可以安全使用==，就是判断是否为 null 或 undefined ，这种情况我都是这样做的，没有任何问题。
对于==，null 只 与 undefined 相等，null 不会与任何其他值相等

@evan1 #5 你这个是重大错误，if (value)会导致 0 和空串被判为 false ，比==还危险

无脑用===的遇到后端接口明明规定是 1 实际给'1'，而且不同接口 string 和 number 看心情来，这种的就老实了

都没讲到重点，实际上浏览器的环境有关。

前端表单的内容都是 字符串，当后端数据一起计算拼接的时候， === 就不是很方便，因此 == 就派上用场了。
比如 input 的年龄，if (age == 18) ，这里的 age 实际上是 String, 引擎自己转了，非要用 === 比较，你得 parseInt(age) === 18 ，代码太丑了。

@shintendo #24 eslint 已经弃用了 allow-null ，可以传递一个对象例如 ["error", "always", {"null": "ignore"}] 进行排除。https://eslint.org/docs/latest/rules/eqeqeq
我认为 == null 是个不太好的编程习惯，带有隐式判断
我自己无论何时都会显式编写 if (x === null || x === undefined)
不过也没用上几次，在有了 ?. 和 ?? 后，几乎不存在需要使用 ==null 的场景

@GuguDan #32 这种就是后端太垃圾导致的后果，要吗都用 0 要吗都用“0”， 一会儿这样 一会儿那样， 这种人就是把代码当儿戏，我现在接手的项目里面就是这样，导致出了很多问题，特别恶心人！