条件判断是JavaScript中最基础也最高频的语法结构，但恰恰是这块看似简单的区域，藏着大量容易被忽视的坑。很多诡异的线上bug，追根溯源都是一行看似无害的if语句。与此同时，DOM操作作为浏览器端最昂贵的操作之一，如果和不当的条件判断结合在一起，性能问题会被进一步放大。这篇文章把两块内容放在一起聊，先拆解条件判断的陷阱，再给出DOM操作的优化实践。
一、隐式类型转换：相等判断的最大陷阱
先看一段经典的代码：
console.log(0 == ''); // true
console.log(0 == '0'); // true
console.log('' == '0'); // false
console.log(false == '0'); // true
console.log(null == 0); // false
console.log(null == undefined); // true
前两行还能勉强用类型转换规则解释，第三行就彻底让人懵了：既然0等于空字符串，0又等于字符串'0'，为什么空字符串不等于'0'？原因在于==的比较规则：当数字和字符串比较时，字符串会被转成数字；空字符串转数字是0，所以0 == ''为true。但两个字符串比较时不发生转换，直接逐字符比较，所以'' == '0'为false。这种不一致的规则是大量bug的源头。
工程实践中的一致性建议很简单：始终使用===和!==。唯一的例外是判断变量是否为null或undefined时，可以写成x == null这一种简写形式，因为它恰好同时覆盖了两种情况且不会触发其他转换。除此之外，任何使用==的场景都应该停下来想一想是否存在更安全的写法。
另外一个隐蔽的坑是数组和对象的比较。[1,2] == '1,2'返回true，因为数组调用toString后再比较；而[] == false也为true。如果代码中出现这样的判断，结果几乎完全不可预测。严格相等虽然不能比较对象内容，但至少行为是确定的：两个引用只有指向同一个对象时才相等。
二、假值列表与边界条件
if语句会把表达式的值转为布尔值，而JavaScript中的假值只有固定的几个：false、0、-0、0n、''、null、undefined、NaN。除此之外的一切都是真值，包括空数组、空对象、字符串'0'和'false'。
这里最容易踩坑的是空数组的判断：
const list = [];
if (list) {
console.log('永远会执行到这里');
}
// 正确判断数组是否有内容
if (list.length > 0) { ... }
另一个高频场景是处理用户输入。表单拿到的值永远是字符串，用户输入0时，如果写成if (input)就会误判为空。这种问题在数字输入框、年龄、数量等字段上非常常见。正确的做法是显式判断if (input !== '')或者先做类型转换再判断。
还有一个容易被忽略的点：NaN !== NaN。任何值与NaN比较都返回false，包括NaN自己。判断NaN必须使用Number.isNaN()，而不是全局的isNaN()，后者会先把参数转成数字，导致isNaN('abc')为true，这可能不是你想要的语义。
三、短路求值与逻辑运算符的正确用法
&&和||的短路特性很实用，但也容易写出难以察觉的漏洞。比如：
// 想给变量设置默认值
function setCount(count) {
this.count = count || 10; // 传入0时会意外变成10
}
// 正确的写法
function setCount(count) {
this.count = count ?? 10; // 只在null或undefined时使用默认值
}
||会在所有假值上触发默认值，而ES2020引入的空值合并运算符??只在null和undefined时才使用右侧的值，语义精确得多。类似的还有可选链?.，可以安全地访问深层属性而不必层层判断，替代传统的&&链式写法。
条件赋值时还要注意运算符优先级。a || b && c等价于a || (b && c)，因为&&的优先级更高。遇到复杂条件时，加括号永远是性价比最高的投资，既避免歧义也方便阅读。
四、DOM操作的性能优化实践
谈完判断逻辑，再来看DOM。浏览器中一次DOM修改可能触发重排和重绘，这两个过程的代价远高于普通JavaScript计算。优化的核心思路只有一个：减少DOM的读写交替次数。
第一招是使用文档片段批量插入节点：
const fragment = document.createDocumentFragment();
for (let i = 0; i < 1000; i++) {
const li = document.createElement('li');
li.textContent = `item ${i}`;
fragment.appendChild(li);
}
ul.appendChild(fragment); // 只触发一次重排
第二招是避免在循环中交替读写DOM属性。读取offsetWidth、scrollTop这类属性会强制浏览器同步计算样式，如果循环里先读后写，每次迭代都会触发强制重排。正确做法是先集中读取，再集中写入。
第三招是事件委托。与其给几百个子元素分别绑定事件，不如在父元素上监听一次，通过event.target判断事件来源：
ul.addEventListener('click', (e) => {
const li = e.target.closest('li');
if (li && ul.contains(li)) {
console.log('点击了', li.textContent);
}
});
这种写法不仅减少了监听器的数量，还能自动支持动态添加的子元素，和上面的条件判断技巧结合起来，就是一套可靠又高效的事件处理方案。
五、总结
条件判断的坑主要来自语言的隐式行为：==的类型转换、假值列表的边界、短路运算的语义偏差。DOM优化的关键则是理解浏览器的渲染机制，把零散的操作合并成批处理。两方面的共同点在于：显式优于隐式，明确写出你的意图，比依赖语言的默认行为要安全得多。把这些习惯落实到日常代码里，能省掉不少排查诡异bug的时间。
JavaScript条件判断DOM操作隐式类型转换修改时间：2026-09-15 11:04:37