JavaScript运算符易出陷阱：用===替代==避免隐式转换；条件判断禁用赋值运算符=；混合类型运算前显式转换类型；逻辑运算符返回原值，需布尔结果时用!!或??。
JavaScript 运算符看着简单，用起来却容易出人意料——不是报错，而是逻辑悄悄跑偏。避开这些陷阱，关键不是死记规则，而是建立对“隐式行为”和“优先级直觉”的警惕。
别让 == 成为 bug 的温床
宽松相等（==）会自动做类型转换，结果常违背直觉：
-
false == '0'→ true（布尔转数字再比） -
[] == false→ true（空数组转数字是 0） -
null == undefined→ true，但null === undefined→ false
解决方案：一律用 === 和 !==。若真需类型转换，显式写出：Number(str) === 42 或 String(num) === '42'。
赋值运算符 = 误入条件判断
把 = 写成 == 或 === 是高频低级错误：
-
if (x = 5)不是比较，而是把 5 赋给 x，整个表达式返回 5 → 条件恒为真 - 后续的
else if永远不会执行
建议：在条件中避免单个 =；启用 ESLint 规则 no-cond-assign，或把比较变量放左边：if (5 === x)（一旦写成 5 = x 会直接语法报错）。
加号 + 的双重身份最危险
+ 既是加法，又是字符串拼接，谁先谁后全看操作数类型：
-
1 + 2 + '3'→ '33'（先算 1+2=3，再 3+'3'） -
'1' + 2 + 3→ '123'（从左到右，全是拼接） -
[] + {}→ '[object Object]'（空数组转空字符串，对象转字符串）
对策：涉及混合类型时，主动统一类型。数值计算前用 Number() 或一元加号 +str；拼接前用 String() 或模板字面量 `${val}`。
位运算与逻辑运算混用易踩坑
&& 和 || 返回的是操作数本身，不是布尔值：
-
0 || 'hello'→ 'hello'（不是 true） -
'world' && null→ null（不是 false） - 若你期望它作为布尔值参与后续计算（比如
if (a && b) doX()），没问题；但若赋给变量再用于算术，就可能出错
更安全的写法：需要布尔结果时，明确用双重取反：!!(a && b)；需要默认值时，优先用空值合并 ??（只对 null/undefined 生效，不误伤 0 或 ''）。
