JavaScript比较运算符有==、===、!=、!==、>、=、
JavaScript 比较运算符有哪些？常见误用在哪
JavaScript 的比较运算符包括 ==、===、!=、!==、>、、>=、。最常出问题的是 == 的隐式类型转换，比如 0 == false 返回 true，'' == 0 也返回 true —— 这不是 bug，是规范定义的行为，但几乎总是意外的。
实际开发中应优先使用 === 和 !==，它们不进行类型转换，只比值和类型都相等才返回 true。例外场景极少，比如明确需要宽松匹配 null/undefined：
if (value == null) { /* 等价于 value === null || value === undefined */ }
-
===在对象比较时只判断引用是否相同，{a:1} === {a:1}是false -
NaN !== NaN，判断是否为 NaN 应用Number.isNaN()，而非==或=== -
Object.is(a, b)可处理-0 === +0和NaN === NaN的边界情况，但日常用不到
逻辑运算符 &&、||、! 怎么用才不踩坑
JavaScript 的逻辑运算符不只返回布尔值，而是返回「最后一个被求值的操作数」。这意味着 && 和 || 常被用作短路赋值或默认值设置，但容易混淆返回类型。
例如：
const name = user.profile && user.profile.name; const fallback = input || 'default';这两行代码能工作，但要注意：
user.profile 是 falsy（如 null、undefined、0、''、false、NaN）时，&& 直接返回它；input 是 0 或 '' 时，|| 也会触发默认值——这可能不符合业务预期。
- 需要区分「空值」和「falsy 值」时，显式检查更安全：
input != null && input !== ''或input ?? 'default'（空值合并运算符） -
!会把操作数转为布尔再取反，![]是false，!{}也是false，因为对象始终是 truthy -
!!x是常见的「转布尔」写法，但多数时候没必要，条件语句本身就会自动强制转换
??（空值合并）和 || 到底该选哪个
?? 只在左操作数为 null 或 undefined 时才使用右操作数；而 || 在任何 falsy 值下都会切换。这是二者本质区别，不是风格偏好。
立即学习“Java免费学习笔记（深入）”；
比如处理 API 返回的可选字段：
const count = data?.items?.length ?? 0; // ✅ 安全：data.items.length 为 0 时，仍保留 0 // ❌ 若写成 data?.items?.length || 0，效果一样；但若字段是 '' 或 false，就错了
-
??不能与&&或||无括号混用，会报语法错误：a ?? b || c不合法，必须写成(a ?? b) || c或a ?? (b || c) -
??是 ES2020 新增，旧环境需 Babel 转译或检查兼容性 - 当字段可能为
0、false、''且这些是有效业务值时，??是唯一合理选择
运算符优先级导致的隐蔽错误
很多人以为 && 一定比 || 先执行，其实它们优先级相同，从左到右结合。所以 a || b && c 等价于 (a || b) && c，而不是 a || (b && c) —— 这和多数直觉相反。
同样，?? 优先级低于 && 和 ||，因此 a ?? b || c 会先算 b || c，再与 a ?? 结合，直接报错。必须加括号明确意图。
- 复杂条件建议拆成变量或加括号，别依赖记忆优先级：
const hasAuth = user?.token && user?.role === 'admin'; - MDN 有完整[运算符优先级表](https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Operators/Operator_Precedence)，遇到不确定时查一下比猜快
- 用 ESLint 规则
no-unsafe-optional-chaining和no-mixed-operators能提前捕获这类隐患
真实项目里，运算符看似简单，但类型隐式转换、falsy 值含义、优先级陷阱这三点，加起来占了调试时间的不小比例。尤其在处理后端返回数据时，一个 || 写成 ??，或者漏掉 ?.length 的可选链，就可能让整个列表渲染异常。
