JavaScript条件语句实战指南：从if/else到短路求值的核心机制

有一次我 review 一段业务代码，看到这样一行：

if (res.code == 200) { ... }

我当时就问同事：“后端这个 code 字段到底返回的是数字，还是字符串？”同事愣了一下，说“好像都有”。问题就出在这。JavaScript 条件语句看似简单，但一个==就足够让整个分支逻辑跑偏。今天我不想重复教科书里的语法定义，而是想从实际项目里摸爬滚打出来的经验出发，把if/else、switch、三元运算符、短路求值这些日常用得最多的条件写法彻底讲透，同时把类型转换、NaN、对象判空、事件监听、表单校验等高频场景里的坑一起填上。无论你是刚入门前端，还是写了几年 JS 想系统梳理一遍，这篇都值得花时间看完。

1. 条件语句的三块基石：if/else、switch、三元运算符该怎么选

1.1 if/else 的条件与真假值判定

if后面括号里的表达式，会被 JavaScript 内部做一次ToBoolean转换。官方维护着一张经典的 falsy 值清单，只有下面这些值会被当成假：

除开这些，其余几乎所有值都是 truthy。这里我最想强调的，是空数组[]和空对象{}在条件判断里是true，不是false。很多新手会下意识以为“空”就是假，这是错误的。比如下面这段代码：

const list = getList(); if (list) { console.log(list.length); }

当list是空数组[]时，if (list)为真，可以正常输出0。但当list为null时，又会进入 else 分支。从业务语义看，这显然不能算是“判断列表是否有内容”，只能算是“判断 list 是否存在”。

类似的场景还经常出现在数字判断上。假如用户积分可能为0，而0是一个合法且有业务含义的数值，就不能写if (points)，因为积分为 0 时会被错误地丢到“没有积分”的分支。正确写法是显式判断是否为null/undefined，再对业务值做大于等于的比较。

else if也要注意分支顺序。它本质上是嵌套的 else，从前往后匹配，一旦命中就退出整个链条。如果多个条件存在包含关系，比如年龄段判断，一定要把范围更小的条件放前面，否则结果会错位。

1.2 switch/case 的严格比较和直落陷阱

switch在匹配 case 的时候用的是严格相等===，不是宽松相等==。这意味着它不会做隐式类型转换：

const x = '1'; switch (x) { case 1: console.log('数字'); break; case '1': console.log('字符串'); break; }

这段代码只会输出“字符串”。很多人把switch的匹配机制理解成“像==一样”，这是一个高频误解。

另外，case后面不只是固定值，也可以是表达式。有人会用switch(true)来做范围判断：

switch (true) { case n >= 90: console.log('优'); break; case n >= 80: console.log('良'); break; }

虽然能跑，但我非常不推荐在业务代码里这么写。switch(true)的阅读成本太高，看到的人要反应一下才能明白你在用 switch 模拟 if/else。既然要做区间判断，老老实实用if/else或者后面的查表法，可读性好得多。

直落（fall-through）是另一个经典陷阱。如果某个 case 末尾没有break或return，执行流会继续走到下一个 case，直到遇到 break 或函数结束。

switch (status) { case 0: case 3: console.log('未开始'); break; case 1: console.log('进行中'); break; default: console.log('其他'); }

这里故意利用直落，让 case 0 和 case 3 共享逻辑，这是合理的用法。但如果你只是忘了写 break，就有可能出现重复弹窗、重复请求之类的问题。我的经验是：如果 switch 是在函数内部，优先在每个 case 里写return而不是break，返回的意图更明确，也不容易漏。

1.3 三元运算符的表达式语义与嵌套上限

三元运算符是表达式，不是语句。这就决定了它不像 if/else 那样“按条件执行一段逻辑”，而是“按条件返回一个值”。所以最常见的用法是赋值和返回值：

const tip = isVip ? '尊享用户' : '普通用户';

如果你发现自己在用三元运算符做多步骤操作，比如里面塞了很多表达式，那就该换成 if/else 了。三元表达式的最佳场景是简单的二选一取值。

三元运算符的嵌套顺序是从右向左结合的：

const level = a ? 1 : b ? 2 : 3;

这行代码实际上等价于a ? 1 : (b ? 2 : 3)。虽然能表达三层条件，但可读性非常差。我和团队定的规矩是：三元最多嵌套一层，超过就用 if/else 或者查表法。代码是写给人读的，不是拿来炫技的，一个让人需要停下来推演的表达式，就是技术债。

2. 五个最容易翻车的条件判断细节：类型转换、NaN、比较运算符、对象判空

2.1 falsy 值清单与隐式转换

这一节要把类型意识刻进骨子里。上一章的 falsy 值清单看着不难，但实际业务里的边界情况要复杂得多。我列过一张完整的判断结果表，供你对照：

注意最后三行。字符串"false"是 truthy，new Boolean(false)因为是个对象，也是 truthy。这两个值经常出现在配置项、接口返回、用户输入里，如果条件判断时没有类型意识，很容易判断错。

我自己的习惯是：写条件之前先问一句，这个字段值可能是哪些类型？比如接口返回的status可能是数字0，也可能是字符串"0"，那if (status === 0)和if (status == 0)的结果完全不同。为了不让这种差异成为隐患，接口规范里就应该固定类型，代码里再用严格的===去判断。

2.2 NaN 判断为何不能用 if (x === NaN)

NaN是 JavaScript 里唯一一个“不等于自身”的值。NaN === NaN是 false，NaN == NaN也是 false。所以你写：

if (x === NaN) { ... }

这段代码是永远进不去的，因为它表达的是一个不可能成立的条件。

正确的判断方式是用Number.isNaN(x)。注意全局函数isNaN和Number.isNaN不一样：isNaN会先把参数转成数字再判断，所以isNaN('abc')返回 true，isNaN(undefined)也返回 true。如果你只是想判断一个值是不是NaN本身，必须用Number.isNaN。

现实里最常见的场景是解析用户输入的数字：

const num = Number(rawValue); if (rawValue.trim() === '' || Number.isNaN(num)) { showError('请输入有效数字'); return; }

这里一定要先判空再转数字，因为Number('')的结果是0，Number(null)也等于0。如果你先做了Number转换再判断，空输入会被当成有效数字 0 给放过去。

2.3 何时该用 ==，何时必须用 ===

==的隐式转换规则是历史上最出名的一堆坑。我把典型结果列出来：

这张表足够说明==的行为不只是“不严谨”，而是引入了一整套你没有主动参与的转换逻辑。所以我给团队定的准则是：默认全部用===，唯一推荐的例外是判断“空值”：

if (value == null) { // 同时匹配 null 和 undefined }

这个写法在很多框架源码里都会看到，因为== null能够同时捕捉null和undefined，又不会把 0、空字符串、false 误判进去，恰好很多场景需要的就是这个语义。

ES6 里的Object.is也值得一提。它在===的基础上修正了两个特例：Object.is(NaN, NaN)为 true，Object.is(-0, +0)为 false。日常开发中用得不多，但如果要做精确的数值相等判断，可以考虑它。

2.4 对象、数组和 null 的判空姿势

这一节是运行时错误的重灾区，我几乎每天都能看到类似的报错：

TypeError: Cannot read properties of null (reading 'length')

根源基本都出在没判空，或者判空条件写得不到位。

对象的判空要分两层。第一层判断对象是否存在，第二层判断对象有没有属性：

if (obj && Object.keys(obj).length > 0) { ... }

注意，Object.keys(obj)在obj为 null 或 undefined 时会直接抛错，所以前面的obj真值判断是必须的。

有时候你还需要区分“自身属性”和“原型链上的属性”。这里有一个经常被问到的基础概念：对象访问obj.method时，会先找自身属性，找不到就去构造函数的prototype对象上找。prototype是函数创建时就存在的对象，和“对象是否 new 完”没有关系，哪怕构造函数执行到一半，只要对象已被创建，访问属性时就会沿着原型链查找。正因为如此，用if (obj.method)判断方法是否存在，得到的不一定是“对象自己拥有这个方法”，它可能来自原型链。如果你想确保是自身属性，用hasOwnProperty：

if (Object.prototype.hasOwnProperty.call(obj, 'key')) { ... }

数组判空不要把希望寄托在if (arr)上，空数组也是 truthy。更可靠的是：

if (Array.isArray(arr) && arr.length > 0) { ... }

字符串判空同样要区分空串和空白串：

if (str.trim() === '') { ... }

用现代语法的话，可选链?.和空值合并??能把一部分判空条件内化到访问链里：

const count = data?.list?.length ?? 0;

这不光省代码，更重要的是语义清晰：链上任何一环为空，结果就是undefined，再通过??变成默认值0。但要注意，??只处理 null/undefined，不处理空字符串和 0，这跟下一章要讲的||有本质区别。

3. 实战重构：从嵌套if到可维护的条件逻辑

3.1 早退模式：把异常情况先抛出

我在做 code review 时，最不喜欢看到的代码是“箭头形”多层嵌套：

if (user) { if (user.status === 'active') { if (user.level >= 1) { // 真正逻辑 } else { showError('等级不足'); } } else { showError('账号未激活'); } } else { showError('未登录'); }

这种三层缩进已经让人很难受了，如果后面再加条件，很容易把大括号放错位置。而且每一层 else 都对应一个前置条件，读代码的人要在脑子里维护一个“当前处于哪个分支”的栈，成本极高。

早退模式的核心思想是：在函数开头把“不满足条件”的路径全部用 return 拦截掉，让函数主体只留下满足所有条件的主流程。

function getVipPage(user) { if (!user) { showError('未登录'); return; } if (user.status !== 'active') { showError('账号未激活'); return; } if (user.level < 1) { showError('等级不足'); return; } renderVipPage(user); }

重构之后缩进层级少了，每个异常情况都有了独立出口，后面的同事想再加一个“黑名单用户”的判断，只需要在最后再加一个 guard 块，不需要动主逻辑。

这个模式在前端组件里也特别常见：先处理 loading、error、empty，最后渲染真正的内容。写早退时要注意一点：return 之后的逻辑一定不要是通用副作用的延续，否则提前退出会跳过不该跳过的代码。

3.2 查表法替代多分支：对象映射、函数映射与合并对象技巧

当条件分支不再是两三个，而是一长串 if/else 或者 5 个以上的 switch case 时，我的第一反应是换成“查表法”。查表法本质上是用键值结构把“条件匹配”变成“属性查找”，代码更短，扩展性也更好。

常见的坏味道是这样的：

function handle(type, params) { if (type === 'add') { addNode(params); } else if (type === 'remove') { removeNode(params); } else if (type === 'update') { updateNode(params); } else if (type === 'query') { queryNode(params); } else { console.warn('unknown type', type); } }

用对象映射改写：

const actions = { add: (params) => addNode(params), remove: (params) => removeNode(params), update: (params) => updateNode(params), query: (params) => queryNode(params), }; function handle(type, params) { const action = actions[type] || (() => console.warn('unknown type', type)); action(params); }

这样做的好处很直接：新增一种操作，只需要在actions里加一行，handle函数本身一行都不用动。当操作种类很多时，还能把各个操作拆到不同模块，按需组合，可维护性会好很多。

查表法也不只是处理枚举值。区间判断可以配合数组的find来做：

const ranges = [ { min: 90, level: '优' }, { min: 80, level: '良' }, { min: 70, level: '中' }, ]; const hit = ranges.find(item => score >= item.min); const level = hit ? hit.level : '待提升';

这种写法比一长串 if/else 清爽，条件规则也变成数据，方便从配置接口下发。

这里顺便说一个和条件判断强相关的场景——合并两个对象。比如：

const defaultConfig = { theme: 'light', pageSize: 10 }; const userConfig = { pageSize: 0, theme: 'dark' }; const merged = { ...defaultConfig, ...userConfig };

...展开运算符会对每个 key 执行覆盖，不管值是什么。假如userConfig.pageSize为 0，你希望它作为合法值覆盖默认值，那没问题；但如果你只想在“用户确实配置了该字段”时才覆盖，就不能写成if (userConfig.pageSize)，因为 0 会被当成 falsy。正确做法是判断值是否为undefined，或者用空值合并：

const pageSize = userConfig.pageSize ?? defaultConfig.pageSize;

这里??只在null/undefined时才取默认值，0 会被保留，正好满足业务需求。

3.3 &&、||、?? 的短路求值：表达式的条件判断

JavaScript 的&&和||有一个容易忽略的特性：它们返回的不一定是布尔值，而是表达式两侧其中一个操作数的值。

短路规则：

• a && b：如果 a 为 falsy，返回 a，不再执行 b；如果 a 为 truthy，返回 b。
• a || b：如果 a 为 truthy，返回 a，不再执行 b；如果 a 为 falsy，返回 b。

所以常见的简洁写法是：

isLogin && showPanel();

这是一个“有条件地执行”的最小表达式。isLogin为 true 时执行showPanel()，为 false 时整个表达式的值就是 false，什么也不做。

||的经典用法是设置默认值：

const name = inputName || '默认名';

当inputName是空字符串、0、false、null、undefined 时，都会取默认值。这在很多场景下很方便，但也隐藏了一个坑：如果inputName为0，而你并不想把 0 替换掉，这个写法就错了。

空值合并运算符??只关心null和undefined：

const count = data.count ?? 0;

当data.count是0或''时，会保留原值；只有当它为null/undefined时才用 0。两种运算符的差异，直接决定了你的条件逻辑是否正确。

&&、||、??这些短路求值本质上就是表达式的条件判断。但短路写法和 if/else 混在一起时，很容易出现优先级问题，这是下一个要聊的坑。

3.4 运算符优先级与括号习惯

运算符优先级这块，我见过太多因为省略括号而翻车的代码。常见的有三类。

第一类是位运算和逻辑运算搞混。&是按位与，&&是逻辑与。写成if (a & b)时，执行的是位运算，结果是一个数字，再被隐式转换为布尔值。数字 1 和 2 进行&的结果是 0，于是条件为 false，但用逻辑与1 && 2则是 true。这类 bug 一旦混进代码里，靠肉眼很难看出来。

第二类是链式相等比较。if (a === b === c)看着像在判断三者相等，实际上先执行(a === b)得到布尔值，再拿这个布尔值和 c 比较。如果 c 是true，那意味着只有当 a 全等于 b 时才进入分支；如果 c 是false，反而 a 不等于 b 时才进入。几乎不可能恰好满足你的本意。

第三类是误把赋值写成相等。if (a = b)会把 b 赋给 a，然后判断赋值的返回值。如果 b 是 0、null、空字符串，条件为 false；如果 b 是对象，条件一定为 true。这个问题相对容易被 ESLint 拦截，建议团队规则里开启no-cond-assign。

我自己的速记优先级顺序，从高到低大概是：括号()、一元运算符、乘除、加减、比较、相等、逻辑与、逻辑或、空值合并、三元、赋值。这里特别提醒：??不能和||、&&直接混用而不加括号，比如：

const x = a ?? b || c;

这在语法上会直接报错。因为规范禁止??与||/&&在同一表达式里不明确拆分。必须写成：

const x = (a ?? b) || c;

我的建议是，在复杂表达式中不要依赖优先级，一律显式加括号。少一行代码的收益，远不如让人一眼读懂的价值大。

4. 条件语句在真实业务场景中的落点：表单、事件、跨端桥接与报错排查

4.1 表单提交中 JS 条件校验与 H5 原生校验的分工

HTML5 表单原生校验确实很强大，required、pattern、maxlength、min、max都是声明式的。浏览器会在表单提交时自动拦截不合法的输入并弹出气泡提示：

<form> <input type="email" required placeholder="邮箱"> <button type="submit">提交</button> </form>

但 H5 原生校验解决不了所有问题。它做不了跨字段联动校验，比如确认密码必须和密码一致；做不了异步校验，比如用户名是否已存在；也做不了复杂的业务规则，比如“勾选企业账号后公司名称必填”。所以真实的业务表单里，JavaScript 条件校验一定会存在。

在 submit 事件里，条件分支的用途非常明确：校验失败就preventDefault()，阻止提交；成功就放行。

form.addEventListener('submit', (e) => { const pwd = document.getElementById('pwd').value; const confirm = document.getElementById('confirm').value; if (pwd !== confirm) { e.preventDefault(); showError('两次密码不一致'); return; } // 继续提交 });

这里有个容易踩的坑：form.submit()方法由 JS 直接调用时，不会触发submit事件。如果你把校验逻辑全部绑在 submit 事件里，然后代码里又调用form.submit()，校验会被完全跳过。更稳妥的思路是把校验逻辑抽成独立函数，在按钮的 click 事件里先校验，再决定调用form.submit()还是直接走 AJAX 提交。

另外，按钮的type也很关键。如果按钮默认是type="submit"，点击后表单会尝试提交。即使 JS 逻辑有问题，也不至于让整个页面刷新。所以我的建议是：能不加type="submit"的按钮就不加，统一用监听器控制提交动作，条件判断的主动权留在代码里。

4.2 事件监听与 void(0)：点击、跳转和防重复绑定的分支设计

<a href="javascript:void(0)">是 JavaScript 早期时代留下的经典写法。void是一个一元运算符，void(0)会返回undefined。把这个结果放在href里，点击链接时表达式结果为 undefined，页面不会发生跳转，于是它成了“占位链接”的常用手段。

在现代前端工程里，这种写法已经不多见了。我们更多是直接在 JS 里监听 click，然后用e.preventDefault()阻止默认跳转行为：

link.addEventListener('click', (e) => { e.preventDefault(); if (isLoggedIn) { openEditor(); } else { jumpToLogin(); } });

事件监听场景下的条件判断，最容易翻车的点有三个。

第一个是元素不存在。如果document.querySelector('#btn')没找到元素，绑定不会报错，但后续访问元素属性时就会出问题。更安全的写法是：

const btn = document.querySelector('#btn'); btn?.addEventListener('click', handler);

第二个是重复绑定。同一个元素被动态渲染或重复初始化时，同一处理函数可能被绑定多次，点击一次就执行多次逻辑。解决办法是在绑定前加一个判定标记：

if (!btn._hasBind) { btn._hasBind = true; btn.addEventListener('click', handler); }

更推荐的是事件代理，把监听器挂到父容器上，一次性处理所有子元素。这样条件判断的粒度放在“目标元素是谁”上，而不是放在“绑定了多少次”上：

document.querySelector('#list').addEventListener('click', (e) => { const target = e.target.closest('.item'); if (!target) return; // 根据 target 的状态走分支 });

事件代理的好处在于内存占用少，也天然规避了重复绑定问题。事件冒泡机制会帮你把子元素的点击统一送到父容器处理，你要做的只是通过条件判断确认目标。

4.3 条件语句运行时报错的完整排查链路：判空、可选链与调试技巧

JavaScript 运行时报错，尤其是类型相关的错误，大部分都能追溯到条件判断没写好。出现频率最高的报错大概是：

TypeError: Cannot read properties of undefined (reading 'xxx') TypeError: Cannot read properties of null (reading 'length')

这类错误出现的原因，是在访问一个可能为null/undefined的对象的属性时，没有先用条件语句做判空。

完整的排查链路可以这样走。

第一步，看错误堆栈。它已经告诉了你文件位置和行号。比如报错在第 15 行，去看那行代码访问了哪个属性。

第二步，打印变量状态。在函数入口先把入参打出来：

function transform(data) { console.log('transform data:', data); const list = data.list; // 第 15 行 }

这样你能立刻确认是 data 为 null，还是 data 存在但没有 list 字段，还是 list 不是数组。

第三步，用条件守卫修正。在实际项目里，我更倾向在入口做精确校验：

function transform(data) { if (!data || !Array.isArray(data.list)) { console.warn('数据格式不正确', data); return []; } return data.list.map(...); }

注意这里!data能挡 null/undefined，但挡不住空对象{}，所以还要判断data.list是否是数组。条件语句的粒度要和后续操作匹配，这是我在长期实践中体会最深的一点。

第四步，如果能用现代语法，用可选链和空值合并化简：

function transform(data) { return data?.list?.filter(item => item.active) ?? []; }

当 data 为 null、data.list 为 null 时，整个表达式返回 undefined，再由??变成空数组。可读性比嵌套 if 好很多。

调试时还有一个技巧：在浏览器 DevTools 或 HBuilderX 里设置条件断点。右键点击断点行号，编辑断点条件，比如输入data === null，这样只有 data 确实为 null 时才停下来。遇到难复现的偶发错误，这种条件断点能帮你省掉大量手动打印和同步等待的时间。

写完条件判断后，强烈建议自测这几个边界用例：正常数据、数据为 null、字段缺失、空数组、空字符串、数字 0。一个条件语句只有经过这些边界测试，才算真正可靠。

4.4 跨端桥接（OC 与 JS 互调）时条件判断的注意点

在 WebView 混合开发里，JavaScript 经常要和 iOS 的 OC（Objective-C）代码互相调用。桥接场景下，条件判断要管的事情比普通页面更多。

首先是调用前的桥可用性判断。JS 调原生方法前，必须先确认桥对象存在：

function callNative(data) { if (window.WebViewJavascriptBridge) { window.WebViewJavascriptBridge.callHandler('share', data, (res) => { if (res && res.code === 0) { showToast('分享成功'); } else { showToast(res?.msg || '分享失败'); } }); } else { showToast('当前环境不支持原生调用'); } }

这里的判断至少有三层：桥对象是否存在、回调结果是否存在、错误信息是否可读。如果桥不存在又不做降级处理，页面会直接抛错，用户什么都看不到。

其次是返回数据的类型判断。原生端回调可能返回字符串、对象，甚至可能是 null。如果拿到的是 JSON 字符串，需要先解析再判断：

bridge.callHandler('getUserInfo', {}, (res) => { if (typeof res === 'string') { try { const json = JSON.parse(res); if (json && json.name) { renderName(json.name); } } catch (e) { console.error('解析失败', e); } } else if (res && typeof res === 'object') { renderName(res.name); } });

这种“先判断类型，再决定下一步处理”的模式，在跨端桥接里非常重要。因为原生端和 JS 端对数据类型、字段约定很难做到处处一致，条件判断就是最后的防线。

不少同事觉得跨端问题很难查，其实很多异常都出在边界没有兜住：桥对象没判断、返回值为 null 没处理、JSON 解析失败没捕获。把条件写严谨，能省掉一大半对接联调的时间。

我自己在实际开发里养成了一个习惯：写条件判断之前，先问三个问题。这个值可能是什么类型？0 或空字符串在这个业务里是不是有效值？如果某一步突然变成 null/undefined，会不会直接抛错？这三个问题一旦有了答案，条件表达式的写法和边界基本就清晰了。做 code review 这么多年，我看到的绝大多数隐蔽 bug，都不是因为开发者写不出 if/else，而是因为类型边界没想清楚。把基础功打扎实，让每个分支都经得起推敲，条件语句才不会成为项目里最容易被忽视的定时炸弹。