1. 一句话戳穿本质三元是“表达式”if...else是“语句”1.1 先做一个随手就能复现的小实验最近带团队做代码评审几乎每一轮都会遇到同一个问题有人把 if...else 改写成三元被另外的同事驳回理由是“这段逻辑太复杂三元可读性差”也有人把简单赋值写成 if...else 四行八行被批“为什么不一行写完”。争论双方其实都没说错但他们争论的往往不是同一个层面的事。你先看一眼这两段代码// 写法 A用 if...else 赋初始值 let userType ; if (age 18) { userType adult; } else { userType minor; } // 写法 B用三元运算符赋初始值 const userType age 18 ? adult : minor;两段逻辑一模一样但第二段有个隐藏优势userType声明成了const。这是最关键的区别。如果你用 if...else 去给一个变量赋初始值就必须先声明let userType然后等待两个分支之一给它赋值。这段时间里这个变量处于“被声明但未赋值”的中间状态。而在三元写法里声明和赋值在同一个表达式完成变量直接就是最终的确定值后面没人能再改它。这个小小的差别几乎是“为什么高手更爱用三元”这个问题最朴素的答案三元运算符是表达式而 if...else 是语句。表达式有值可以组合可以嵌套在其他表达式里语句只能按顺序执行它的“产物”是副作用而不是一个值。1.2 表达式能组合语句只能排队把“是否有值”这个差异放大来看你会发现表达能力完全不是一个层级。你可以在任何需要值的地方写三元const greeting 你好 (isVIP ? 尊敬的会员 : 访客); setStatus(connection.online ? 在线 : 离线); console.log(用户状态${user.active ? 正常 : 已禁用});三元可以出现在字符串拼接里可以当函数参数可以放进模板字符串。如果换成 if...else这些位置全部塞不进去你只能先把结果存进一个变量再用这个变量。多写几步不说还引入了中间状态。从思维模型的角度看这两者根本不是在干同一件事if...else 描述的是“如果怎样就执行什么动作”三元描述的是“根据什么条件取哪个值”。动作需要排队、需要控制流程取值只需要问一个问题然后拿到结果。这也是为什么 React 的 JSX 里大量出现三元。JSX 本来就是表达式里面不可能直接插一段 if...else{isLoggedIn ? UserPanel user{user} / : LoginButton /}在 JSX 里面写if语句是要报错的你只能写表达式。类似的场景还有模板字符串、函数式编程的链式调用、CSS 变量计算等。这些场景天生只接受“值”不接受“步骤”。1.3 各语言的三元长得不一样但本质相同我在前端团队待得久JavaScript 里的cond ? a : b用得最多。但如果你跳出去看会发现这个“表达式化条件判断”的思路并不是 JS 独有的每个主流语言都有自己的表达方式语言写法说明JavaScript / Java / C / C#cond ? a : b最经典的三元形式Pythona if cond else b顺序反过来了先写真值再写条件Rustlet x if cond { a } else { b };if 本身就是表达式可以返回值SQLCASE WHEN cond THEN a ELSE b END查询里唯一的条件表达式Go没有三元运算符官方刻意不提供要求你写得朴素Python 那种a if cond else b的写法我第一次接触特别不习惯条件跑到了中间。但它本质上仍然是一个表达式只是语序调整成接近自然语言。Rust 的做法更彻底没有单独发明三元符号而是让if本身可以作为表达式返回值。这说明一个道理语言设计者不管用哪种语法解决的都是同一个问题——让条件分支可以产出值而不是只能产生副作用。Go 是这里面的异类它故意不支持三元理由是三元容易写出难读的代码。这个选择值得玩味后面第三章我会仔细讲“什么时候不该用三元”看完你就能理解 Go 团队的担心也不是没道理。提示看一个运算符不要只看它的符号长得怎么样要看它在语言里的“身份”。三元在 JavaScript 里是唯一的“条件表达式运算符”这个身份才是它真正值钱的地方。2. 五个最值得用三元的地方赋值、返回、渲染、兜底、映射2.1 赋值初始化从 let if 到 const 三元最典型、也最推荐无脑用的场景就是变量初始化。拿一个真实例子说之前我在项目里写登录弹窗的文案根据用户是否来自移动端决定按钮文本let buttonLabel 进入电脑版网页; if (isMobile) { buttonLabel 下载 App; }这种写法看着没什么问题但项目里的buttonLabel声明成了let。在一个 300 行的组件里谁敢保证后面没有人手滑把buttonLabel再赋值一次改成三元以后变量直接是const编译器和代码评审的人都能一眼看出这个值声明之后不会变。const buttonLabel isMobile ? 下载 App : 进入电脑版网页;多条件初始化的优势更明显。比如根据会员等级计算折扣// 之前 let discount; if (level 5) { discount 0.8; } else if (level 3) { discount 0.9; } else { discount 1; }这段逻辑已经有三个分支了用三元也有对应的写法const discount level 5 ? 0.8 : level 3 ? 0.9 : 1;说实话三层的链式三元已经不是最优解了我更推荐用查表法这一点在 2.5 里单独展开。但就算这样const discount ...一行把值定死和let discount等待四处赋值前者在代码理解上仍然明显占优。2.2 简化 return本质是按条件返回一个值如果一个函数的作用是根据入参返回结果那它的 return 位置最适合三元。我在写工具函数时几乎不会用 if...else 去返回因为那样会凭空多出几条分支语句function getOrderStatusText(status) { return status paid ? 已支付 : status shipped ? 已发货 : 已取消; }这里链式三元出现了第二次坦白说读起来已经需要一点耐心。所以如果条件超过两个我一般不会继续用三元而是拆映射表后面 2.5 讲。但两个分支的简单返回三元是无悬念的第一选择function getGreeting(name) { return name ? 你好${name} : 你好访客; }有人可能会说if (cond) { return a; } else { return b; }不也挺清晰是清晰但同样的结果你可以对比一下代码行数和缩进层级。在函数体很长的情况下每个分支少一层缩进整体可读性都会提升。还有一类经典场景是“提前返回”和三元配合使用。比如先通过“卫语句”排除异常情况剩下的正常路径再通过三元直接返回一个值function parseDuration(raw) { if (!raw) return 0; return raw.endsWith(s) ? Number(raw.slice(0, -1)) : Number(raw); }把 if...else 变成“卫语句 三元”是我在实际项目里最常用也最推荐的组合方式。卫语句负责排除异常分支主线逻辑保持单层代码像流水一样从上往下读不用来回扫缩进。2.3 JSX 和模板为了让逻辑长在视图上前端领域是三元运算符使用频率最高的地方主要是因为 JSX 不允许在标签内部写 if 语句。你只能这么写div classNameuser-panel {user ? Avatar src{user.avatar} name{user.name} / : p classNameempty-tip请先登录/p} /div如果不用三元最常见的替代方案是回头写一个显示组件或者用短路运算符{user Avatar src{user.avatar} name{user.name} /}短路运算也是一种“隐式条件的值”但它只能处理“满足条件就渲染、不满足就什么都不显示”的场景。如果两个分支都要渲染内容就无能为力了必须上三元。我见过不少同事在 JSX 里该用三元的地方因为嫌“写法乱”而绕路结果绕到别处写if渲染变量let panel null; if (user) { panel UserInfo user{user} /; } else { panel LoginPrompt /; } return div{panel}/div;这种写法当然也能跑但整个组件凭空多了一段“决定 panel 是什么”的流程。实际上panel完全可以根据user直接推导出来根本不需要中间变量。高手看到这种代码条件反射就会拧成一行return div{user ? UserInfo user{user} / : LoginPrompt /}/div;模板语言里也一样。Vue 的模板里推荐用三元做“有值就显示 A否则显示 B”的操作Handlebars 等模板引擎里也常见{{cond ? a : b}}。视图渲染本质上就是“把状态变成为值”三元正好匹配这个心智模型。2.4 空值兜底和 ?? 搭配才是完整用法高手很少单独使用三元做空值兜底更常见的做法是让三元和空值合并运算符??配合。先看一个常见的网络请求场景const nickname response.data.nickname ? response.data.nickname : 匿名;这个三元完全可以用??简化const nickname response.data.nickname ?? 匿名;很多同事分不清两者觉得差不多。实际上有本质区别??只处理null和undefined两种情况而三元可以判断任意条件——比如空字符串、0、false、数组长度等。在大多数“空值兜底”场景里语义就是“如果是空就取默认值”那么??恰好精准匹配如果用三元反而把表达范围扩大以后阅读代码的人会忍不住想为什么这里不直接用??是不是也算空这是个隐藏的语义负担。所以我在项目里总结了规则判断“值是否存在”优先??判断“值满足什么条件才取 A否则取 B”才用三元。比如// 根据是否登录显示不同按钮适合三元 const action isLoggedIn ? 退出登录 : 立即登录; // 可能为空时给默认文案适合 ?? const tips serverTips ?? 暂无提示;两条规则搞明白代码基本不会出现“看不懂为什么选这个运算符”的尴尬。2.5 表驱动映射连链式三元都可以省掉前面说了两次链式三元其实超过两个条件之后我有更喜欢的办法——映射表。这个技巧是从 C 语言的“查表法”迁移过来的也符合“数据驱动”的思路。比如根据状态码返回提示文本const statusText { 200: 请求成功, 400: 请求参数错误, 401: 需要登录, 403: 没有访问权限, 500: 服务器内部错误, }; function getStatusText(code) { return statusText[code] ?? 未知状态; }这段代码既没有三元也没有 if...else逻辑依然清晰。如果你用三元写就等于写一个五层的链式三元任何人看到都会摇头// 千万别这么写 function getStatusText(code) { return code 200 ? 请求成功 : code 400 ? 请求参数错误 : code 401 ? 需要登录 : code 403 ? 没有访问权限 : code 500 ? 服务器内部错误 : 未知状态; }表驱动的好处不只是“短”更重要的是把数据的对应关系独立出来后续加状态码不用改动函数逻辑只加一行表项就行。这正好解释了“高手为什么更爱用 ? :”之外的另一层道理高手的核心策略是找到简单可靠的工具解决问题三元只是其中一件当它不适用时高手会立刻换成映射表而不是硬用。3. 什么情况别用三元高手的“不”比“用”更重要3.1 分支体超过一条语句时前面吹了很多三元的好处但如果你以为高手是“见 if 就用三元替换”那就大错特错了。高手真正厉害的地方是知道什么时候不用。第一个红线是分支体里有多条语句。看这个例子// 正常人写的 if...else if (paymentSuccess) { updateOrderStatus(order.id, paid); sendReceipt(order.owner, order.amount); showToast(支付成功); } else { showToast(支付失败请重试); }如果要硬改成三元可以写成这样// 不要这样写 paymentSuccess ? (updateOrderStatus(order.id, paid), sendReceipt(order.owner, order.amount), showToast(支付成功)) : showToast(支付失败请重试);这种“逗号运算符硬塞多条语句”的写法代码能跑但属于典型的“为了炫技而写”。它把三个动作硬塞进一个表达式里要么靠逗号运算符要么靠 IIFE无论哪种都很难读、很难调试、很难加注释。分支体里是动作而不是值就该老老实实用 if...else。我在代码评审中有一条硬标准如果 if/else 的两个分支体总行数超过三行就别琢磨怎么拧成三元了直接保持 if...else。三行以内的分支还要判断这些行到底是“在计算值”还是“在做动作”做动作的也不能用三元。3.2 分支有副作用的场景什么是副作用在 React 里就是调用 setState、发请求、改外部变量在普通函数里就是 console.log、写文件、修改全局状态。这些动作的结果不是一个返回值而是外部世界发生的变化。把这种逻辑塞进三元等于用一个“取值的表达式”偷偷干了“改变世界”的事语义完全错位。举一个我在线上代码里真实见过的反面例子// 原意是步骤如下showMessage 如果返回 true 就执行 confirm否则执行 cancel if (showConfirmDialog(确定删除吗)) { deleteData(id); } else { cancelAction(); }某个同事图省事改成了showConfirmDialog(确定删除吗) ? deleteData(id) : cancelAction();初看还挺对称但问题在deleteData(id)和cancelAction()的返回值都被丢弃了它们本来就是“做事情”的函数不是“返回值”的函数。如果未来某天deleteData需要返回删除结果给调用方这个三元表达的返回值语义就会变成陷阱。真正的判断依据还是那句话if...else 描述的是流程三元描述的是取值。分支里要执行动作、触发事件、调用有副作用的函数一律 if...else分支里只是根据条件得到一个值才考虑三元。3.3 嵌套三元最多只容忍一层嵌套三元是三元滥用最严重的形态也是很多团队干脆禁用它no-ternary规则的直接原因。来看一个我在实际代码评审里遇到过的“超级嵌套”// 数字含义0-未开始1-进行中2-已完成 const statusText status 0 ? 未开始 : status 1 ? 进行中 : status 2 ? 已完成 : 未知状态;这种代码刚写完的那一刻你觉得自己写得很帅过一个月再看保证要盯着缩进和冒号配对很久。更麻烦的是一旦要插入一个新的中间状态你必须在第四层后面再补一层改完这行整个函数的认知负担又上升一截。我自己的容忍上限是“一层嵌套”也就是cond ? a : b中的b本身是一个简单的三元比如const typeLabel age 60 ? 长者 : age 18 ? 成年人 : 未成年人;这种两个条件三种结果的场景一句话能说完缩进也不需要换行尚可接受。但再往上加我就无条件建议拆表或拆函数了。为了把这条规则落地到团队我通常在项目里直接开启 ESLint 的no-nested-ternary规则编译阶段就拦住这种写法省得评审时一遍遍费口水。3.4 需要写注释的地方就别缩成一行还有一个容易被忽略的判断标准条件本身是否足够“自解释”。翻看老项目里的历史代码你会发现很多 if...else 虽然写得啰嗦但条件上挂着注释“% 7 为 0 说明正好是周日”之类的。这种地方如果强行改成三元注释挂哪里挂在三元那行行尾一行代码右半段全是注释读起来比 if...else 还要费劲。我遇到过的一个例子// 活动时间在秒级时间戳范围内且用户未领取过才允许参与 if (now activity.startAt now activity.endAt !hasClaimed) { allowJoin true; } else { allowJoin false; }这里的条件比较长单靠变量名表达不完背后的业务含义。高手不会把它拧成一行而会先给条件取一个有名字的变量const isActivityActive now activity.startAt now activity.endAt; const hasNotClaimed !hasClaimed; const allowJoin isActivityActive hasNotClaimed ? true : false;等等ternary两个分支返回true/false本身也是一种无意义写法——直接写const allowJoin isActivityActive hasNotClaimed就行。这段演化过程恰好说明与其硬塞三元不如把判断条件抽成命名清晰的布尔变量让代码自己说话。4. 代码评审我怎么判断这一处该不该改成三元4.1 我的第一反应在“选值”还是在“做两件事”在团队里做评审久了我形成了一套几乎不需要过脑的自动判断流程。第一眼看到 if...else我会立刻问自己一个问题这个分支的最终产物是一个值还是两段流程“值”的特征很明确每个分支的核心内容都是往同一个变量赋值或者直接返回某段字面量。这种场景我基本会建议改成三元或映射表理由前面说过用const固定下来变量状态清晰代码行数少。“流程”的特征也很明确分支里有循环、有异步调用、有多个语句、有 try/catch。这种场景我不会提“改三元”提了反而要被反驳。评审不是把代码变成最短形态而是让它最容易维护。举个例子一个解析接口返回的逻辑// 第一个分支返回 304 时重新拉取内容 if (res.code 304) { await refreshContent(); return retryFetch(); } else { return res.data; }如果有人在这里写成三元我会直接驳回await语句和retryFetch()两个都是一系列流程步骤不是单纯取值。if...else 才是正确的工具。4.2 格式只是表象可读性和最小 diff 才重要做评审还有一个容易被忽视的角度改动成本。你会经常在一段老代码里看到这样的情况——原本的type只有一个状态后来加了一个状态代码就变成 if...else 嵌套。如果之前用的是映射表加到哪个字段都只是新增一行改动范围只有一行评审时眼睛扫一下就过了如果之前用的是链式三元改动一行就意味着整条链式结构要重新对齐缩进git diff 刷出一大片变动评审人得重新读一遍整段逻辑心智负担翻倍。所以评审时我从来不只看“这行代码现在写得对不对、好不好”还要想“下周加一个状态改起来痛不痛苦”。从这个角度看简单三元赢了 if...else映射表赢了链式三元而 if...else 赢了“分支逻辑会持续增长的复杂三元”。拿实际的 diff 说- const statusText res.code 200 ? OK - : res.code 400 ? Bad Request - : res.code 500 ? Server Error - : Unknown; const statusTextMap { 200: OK, 400: Bad Request, 500: Server Error, }; const statusText statusTextMap[res.code] ?? Unknown;这一次变更看似重写实际上是把原本的链式三元直接换成映射。改了代码形态但是没改变逻辑。如果一开始就用映射表新增 404、502 的状态每行都只是一行独立改动reviewer 看 MR 时闭着眼都能点通过。4.3 真实评审案例一次三元被驳回的完整过程有次组里的同事写了个促销计算函数大致逻辑是根据用户是否会员、商品是否参加满减、是否有优惠券计算最终价格。他用了两层的链式三元我数了一下一行代码里嵌了三个条件五个分支const total isMember ? product.isOnSale ? price * 0.8 - (coupon ? coupon.discount : 0) : price - (coupon ? coupon.discount : 0) : product.isOnSale ? price * 0.9 - (coupon ? coupon.discount : 0) : price - (coupon ? coupon.discount : 0);这段代码缩进还行但可变因素有三个任意一个组合不同结果都不一样。人肉读这种代码相当于在脑内执行一个三层的判断树。我当时没有直接说“别用三元”而是先问了他一个问题“这函数是在计算什么”他说计算价格。我又问“价格这个值能不能拆成几个小的计算步骤”后来我们把逻辑拆成了一段一段的 if...else 变量叠加let finalPrice price; if (product.isOnSale) { finalPrice * isMember ? 0.8 : 0.9; } if (coupon) { finalPrice - coupon.discount; }结果代码比原来长了三行但每个条件的作用一眼可见。新的方案里甚至还在内部留了一个三元isMember ? 0.8 : 0.9因为它负责的只是“选一个折扣值”。中间变量finalPrice用的是let但它的变化是逐步叠加、每一步都有明确语义这种场景下 if...else 反而是更可靠的选择。这个案例让我总结了一条心得不要为了消灭 if...else 而消灭 if...else。高手爱用三元是真的但用的前提是“这个分支的本质就是选值”如果分支的本质是做累计、做过滤、做流程切换if...else 才是对的样子。把“值的选择”压缩给三元把“步骤的推进”交给语句这才是真正的工程判断而不是风格偏好。4.4 让工具替你守住风格ESLint 与格式化风格问题靠人记忆和评审提醒很容易漏。我在项目里习惯用 ESLint 规则把这些决策固化下来规则作用no-unneeded-ternary禁止无必要的三元比如a ? true : falseno-nested-ternary禁止嵌套三元基本所有团队我都推荐开no-ternary完全禁止三元适合团队风格非常保守的情况prefer-const强制能声明成const就声明成const天然鼓励表达式初始化no-unneeded-ternary是特别实用的规则能抓出一种很常见的坏味道用三元返回布尔值。有的人写const isAdult age 18 ? true : false;这一眼就是废话age 18本身就是布尔值直接赋值就行const isAdult age 18;这种坏味道经常出现在从别的语言迁过来的同事代码里因为有些语言没有自然的布尔表达式语法。工具规则开起来以后这类问题提交前就会被拦截评审压力小很多。Prettier 这类格式化工具也会影响三元的最终形态——当一行三元太长Prettier 会按照自己的规则断开换行。所以同一段代码格式化前后的阅读体验可能完全不同。我建议团队里的 Prettier 配置和信息保持一致不要让格式问题变成评审争议源。5. 为什么“高手”看起来偏爱三元思维模型与风格5.1 用“值”思考的人代码本来就短把高手和普通开发者的代码放在一起对比你会发现高手并不见得刻意追求“短代码”而是他们的思维模型不一样。普通写法是流程式用户进来了 → 判断是不是会员 → 是会员走会员通道 → 不是走普通通道 → 得到价格。这个思维模型把重点放在“做分支决策上”。高手写法是状态推导价格等于“会员折扣 × 基础价”折扣从会员等级推导出来状态文本从状态码映射出来按钮文案从登录状态推导出来。这个思维模型把重点放在“依赖关系上”分支决策被压缩成一次性选择。所以高手更爱用三元表达的是“结果 条件 ? 值A : 值B”这种依赖关系if...else 表达的是“先判条件再做动作”。在大部分业务代码里要理解一个系统最重要的问题是“这个值怎么来的”而不是“这个分支做了什么”。三元直接把“怎么来的”写成一个等式信息密度和阅读效率自然更高。5.2 函数式表达与“最小化可变状态”很多高手调侃自己写代码时在“消灭 let”。这背后是有逻辑的变量一旦可变你在读代码的时候就要时刻跟踪它后续被哪些地方改过。人脑同时跟踪五六个可变变量是极限任何一个漏掉都会导致对程序状态的错误判断。三元帮忙消灭的正是这一类let变量因为表达式是值可以直接赋给const直接 return直接嵌入其他表达式不需要在声明之后等待分支来赋值。每少一个let读代码的人就少一个需要脑内追踪的状态点。我统计过自己写的一个中等规模的前端页面组件把符合条件的三元替换 if...else 后let变量的数量从 14 个降到了 5 个。这不是因为逻辑复杂度下降了而是很多变量从 “先声明后赋值” 变成了 “声明即确定”。对后续维护者来说可跟踪状态少了 60% 以上这比省几十行代码有意义得多。函数式思维还有一个点尽量把函数写成“输入 → 输出”的纯映射。给定输入永远返回同样的输出不依赖外部状态。三元是构造这种纯映射最顺手的语法——条件明明是个输入参数函数内部只需要通过一个表达式算出返回结果。if...else 本身当然也能写纯函数但它的流程属性会让你经常不自觉地在函数里插入步骤、修改中间变量慢慢破坏纯度。5.3 团队风格约定比偏爱更重要讲了这么多最后想说的是风格偏好没有绝对的对错但团队必须有统一约定。如果你在一个“代码里禁止三元”的团队比如一些强调“只用 if...else 以降低心智负担”的传统团队那即便你个人认为某个场景用三元更简洁也应该遵循团队规范。风格的价值在于一致性而不在于选哪种规则。一致性能让代码库看起来像一个人写的降低每条代码的解读成本。反之如果你在一个“鼓励表达式化、函数式”的团队那你就该把本文说的这些场景实践起来而不是每次都用let if...else 拖住整个团队的水平。我在实际项目中落地过一套比较中庸的规范供参考一个条件、两个分支、分支体都只是取值 → 允许三元推荐三元。两个条件、三个结果 → 允许单层嵌套三元但需要写注释更推荐映射表。超过三个条件 → 禁止三元用映射表、switch 或提前 return。分支体内有多条语句或副作用 → 无条件禁止三元。代码评审里提出“改成三元”的要求必须基于上述规则不基于个人喜好。这套规范不偏向任何一方但它让团队里“三元党”和“if...else 党”停止吵架因为他们讨论的边界已经不再是风格而是逻辑类型。回到标题的问题高手更爱用三元不是因为他们会背运算符优先级表而是因为他们习惯了“用值描述世界”。同一段业务高手看到的是等式和映射于是三元成了最顺手的表达新手看到的是步骤和分支于是 if...else 成了最顺手的表达。等你也开始用“这个值是从哪里推导出来的”这种视角去看业务代码你会发现三元只是个自然结果。我在实际项目里最后提醒自己的一句话是能让代码少跳到 if...else 的分支逻辑里就尽量让代码直接表达“值是什么”。但每次准备把 if...else 改成三元之前都先问一句这个分支改完以后考试组同事明天能一眼看懂吗如果答案是犹豫那就别改。工程上没有绝对的高手风格只有在一个特定团队、一段特定代码里哪个写法让别人维护成本最低的问题。
