1

1

无脑===

2

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

3

13

隐式转换罢了

4

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

5

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

6

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

8

不知道啊 ，我用 ts

9

十几年前好像都是==

10

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

11

太麻烦了，容易出问题

12

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

13

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

14

if(!!val)

15

3

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

16

1

无脑 === ，手动转类型

17

18

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

19

21

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

22

3

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

23

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

24

26

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

30

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

31

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

32

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

33

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

34

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

35

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

36

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

38

我去，开倒车

39

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

41

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

42

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

43

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

44

45

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

47

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

49

1

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

52

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

54

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

55

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

56

eslint eqeqeq 规则有个 smart 模式

57

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

59

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

61

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

62

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

64

65

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

67

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

70

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

71

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

74

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

75

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

78

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

79

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

80

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

81

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

82

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

83

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

84

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

85

87

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