推荐关注 Meteor JSLint - a Javascript code quality tool jsFiddle D3.js WebStorm 推荐书目 Javascript 权威指南第 5 版
Closure: The Definitive Guide
Closure: The Definitive Guide 
写了很多年 js ，都是用三等号。即使类型不匹配也要强制使用 Number String 等方式转换一下再判断。
现在发现双等号直接可以帮你转类型后再比较。
甚至可以这么用: if (a == 0) { ... }, 这里当 a 是 0 / "" / false 时候都成立。
看到很多项目都把双等号给禁了（ eslint eqeqeq ），没仔细研究，但有些情况下还是不错的。
 | 1 aisles1 2 小时 6 分钟前 无脑=== |
 | 2 june4 2 小时 3 分钟前 val == null 应该是 js 基本常识技能吧？那判断为 null 你是怎么做的？ val === null || val === undefined? |
 | 3 gorvey 2 小时 2 分钟前  3 隐式转换罢了  |
 | 4 qiaobeier 2 小时 1 分钟前 十多年前我用这个当面试题来着 |
 | 7 l864494871 1 小时 56 分钟前 @ethusdt 他的意思是当判断是否为 null 时只需要==即可。 |
 | 8 ixixi 1 小时 56 分钟前 不知道啊 ，我用 ts |
 | 9 wu00 1 小时 45 分钟前 十几年前好像都是== |
 | 10 maplezzz 1 小时 44 分钟前 隐式转换设计的太复杂了，不同的类型，各种各样可能的 case ，用的时候很容易出现意料之外的问题 |
 | 11 jydeng 1 小时 40 分钟前 太麻烦了，容易出问题 |
 | 13 MinorN 1 小时 38 分钟前 坚决 === ，我同事曾经用 == 找了 1h 的 bug ，然后叫我帮忙看看哪里出了问题 |
 | 14 cpstar 1 小时 37 分钟前 if(!!val) |
 | 15 masterclock 1 小时 26 分钟前 2 完全不适用 ==，只用 === 不直接使用 if(a)，全部包装成基于业务语义的 isNull isEmpty isValid isGood... |
 | 16 g17 1 小时 17 分钟前 无脑 === ，手动转类型 |
 | 17 aloxaf 1 小时 15 分钟前 > 甚至可以这么用: if (a == 0) { ... }, 这里当 a 是 0 / "" / false 时候都成立。 我觉得代码中就不应该出现 a 有可能是 0 / "" / false 的情况…… |
 | 18 temporary 1 小时 8 分钟前 如果需要展示的情况，0 需要展示，而 "" NaN null undefined 大概率要展示成 - |
 | 19 ethusdt OP @june4 #12 哦，我明白了，就是判断某个值是 null ，而非 0/空字符串/false 之类的具体值。但是业务场景下，这些都是一样效果，用户没有填一个值那就给默认 false/0/空字符串，除非有特殊需求默认成其他值。 我想到的就这点了。能再举几个例子场景么。 |
 | 20 craftsmanship 1 小时 2 分钟前 via Android @masterclock 是个提升代码可读性和健壮性的好习惯 |
 | 21 crocoBaby 1 小时 0 分钟前 卧槽,我一直偷懒用的==,确实遇到 0 和 false 和 null 的问题 |
| 22 craftsmanship 59 分钟前 via Android 总有人说 JS 简单 结果在双等和三等上面都分不清楚适用场景，，，也分不清 falsy value 和 nullish value 真特么菜。 |
| 23 craftsmanship 54 分钟前 via Android JS 是个由于初期设计太过垃圾而导致引入过多不必要的复杂性的语言 有大量细节需要记忆 由于不规范导致的灵活性让人可以玩花活 写出来的代码难读难维护 反直觉的设计让不熟悉这门语言的人踩很多坑 很多使用者根本意识不到自己在干什么 看看上面的回复就知道了 从改善这些缺点来讲 TS 是大救星 |
 | 24 shintendo 52 分钟前 ESLint 关于===的规则（"eqeqeq"）里，有个选项开关就是允许==null 。 此外早年流行的几个 JS 代码规范，StandardJS, Airbnb, Google Style Guide, 全都是“禁止使用==，但==null 例外”，算是通行做法。   |
| 25 craftsmanship 51 分钟前 via Android @maplezzz 不是设计得太复杂了 而是当初压根没有设计 完全 PL 外行拍脑袋搞出来的垃圾 |
| 26 craftsmanship 49 分钟前 via Android @shintendo 我原来就是遵守这个规范 但现在感觉#15 的做法更好 完全避免 JS 的那些隐式语义 包成 util 不费劲而且一目了然 让所有人都能读懂意图 |
 | 27 tonytonychopper 46 分钟前 @crocoBaby 这还能偷懒吗，出 bug 了就老实了 |
| 28 tonytonychopper 45 分钟前 @craftsmanship #23 是的，但是这些设计问题变成了面试题来拷打从业者…… |
 | 29 meteor957 42 分钟前 @tonytonychopper ===和== 甚至面试都不应该问，完全没有使用 == 的理由，默认===就行。 |
| 30 craftsmanship 38 分钟前 via Android @tonytonychopper 怎么说呢 为了八股而八股的话 完全没必要 属于做题大国的坏习惯 但八股里考察的点 其实是有意义的 只是以八股的形式出现很恶心 比如隐式转换就能看出使用者对 JS 的熟悉程度 也是非常常见的坑点 想全记住规则并不现实 因为确实太复杂 但这个都不了解的话 那完全不合格 然而所有这些在 AI 时代已经不重要了… |
| 31 craftsmanship 35 分钟前 via Android @meteor957 有 #24 已经提过了 再具体点说就是 唯一使用双等的场景 就是用来判断 nullish value 面试时值得问的点太多了 隐式转换确实不合适 因为这应该是 JS 基本功 默认是了解的 |
 | 32 GuguDan 34 分钟前 用的，因为有时候接口就是会返回 ‘0’ |
| 33 craftsmanship 30 分钟前 via Android @GuguDan 坏习惯 这种应该 Number(val) === 0 而非偷懒使用双等的隐式转换 想玩花活？没问题 +val === 0 少打几个字母 让代码变得晦涩难读 有意义吗？完全没意义 但很多人这样写 显得自己很 6 这就是 JS |
 | 34 hafuhafu 29 分钟前 以前前端工程化没流行开的时候，只用`==`的人大把，甚至反而很多人都不知道`===`。特别是一些后端顺便写前端的人。 多亏了前端工程化和各种创建项目的脚手架以及开源项目里面用了 ESLint ，倒逼大家去学习一些规范。 说个我感觉很搞笑的事，以前看到有不少人搜 ESlint 报红怎么解决，最后的方案是卸载掉... |
 | 35 gdw1986 27 分钟前 via Android 这种现在交给 AI 应该没什么难度吧 |
 | 36 Shaar 26 分钟前 我刚入行做 cocos-js 开发的时候，根本不知道===这个东西，一直用== 直到出现了一个隐形 bug ，查了非常久才知道有==和===的问题，十年了，我都无法忘怀这个东西 |
| 37 crocoBaby 24 分钟前 @tonytonychopper 借机跟测试小妹说话 |
 | 38 lueluev 22 分钟前 我去，开倒车 |
 | 39 wangtian2020 13 分钟前 我只用 == 很少用严格===。 项目我一个前端没人管我。 == 能没问题的地方 === 一定没问题。=== 会出现问题的地方 == 可能反而没问题。 通常情况下只有会 string number 之类的在进行比较，其他一切比较情况都是写法有问题 |
| 40 wangtian2020 11 分钟前 @aloxaf 动态类型转换为 false 的我直接 if(a){} 了 |
 | 41 woodcutter 9 分钟前 小程序页面穿参会把 number 转成 string ，一般我想省事就用==，懒得再转了。 |
 | 42 akakidz 几秒前 双等号就是邪修，TC39 委员会的人，也不能把双等号在项目里用明白 太复杂了！下一个维护项目的人，难道要在脑子里跑一遍所有场景下状态机 预判前人写的双等号可能要处理的业务逻辑？ |
Select Language