JavaScript 控制流实战：switch、三元运算符与循环选型

翻到笔记第 20 天那一页上面并排写着三个词switch 语句、三元运算符、循环。当时我把它们当成三个互不相干的语法点照着示例敲一遍能跑通就算学会了。后来真正写业务代码才发现这三样东西其实在回答同一类问题——怎么让程序在分岔路口做选择怎么让同一段逻辑重复执行。区别只在于switch 是按值挑一条分支三元运算符是按真假二选一循环是把一件事重复做若干次。选哪种写法表面看是代码风格往深里看其实是在决定这段代码以后好不好改、好不好测、别人接手时会不会骂人。这篇内容适合三类人看刚把基础语法过完、正处在“能写但写不好”阶段的学习者写了两三年代码、习惯性用嵌套三元把逻辑压成一行的人以及想系统梳理一遍控制流写法、把踩过的坑整理成清单的人。我不会只讲语法怎么用那些文档里都有我要讲的是每个语法点背后的设计意图、什么场景下该用它、什么场景下它是陷阱还有我自己和身边人在真实项目里栽过的跟头。1. switch 到底在比什么值匹配机制与 case 穿透语义1.1 严格相等匹配以及它带来的第一个日常 bug很多人第一次被 switch 坑到都是在处理表单或者 URL 参数的时候。代码大概长这样const status document.querySelector(#status).value; // 用户选了 1 switch (status) { case 1: renderSuccess(); break; case 2: renderFail(); break; default: renderUnknown(); }结果页面永远走default。原因很简单input.value拿到的永远是字符串1而case 1是数字。switch 内部做的是严格相等比较规范里的比较逻辑和一致类型不同直接判不等不会像那样把1转成1。这个设计其实是对的。想象一下如果 switch 用松散比较switch(0)会匹配case falseswitch()也会匹配case 0那种隐式转换带来的混乱比现在这种“不匹配”要可怕得多。所以别抱怨它严格该做的是在入口处就把类型统一好。我现在写这类代码的习惯是拿到外部数据第一件事就是显式转换const status Number(el.value)或者在 switch 之前统一switch (String(code))让 case 里也全是字符串两边对齐。还有一个细节值得记一下switch (NaN)不会匹配case NaN因为NaN NaN是 false最后会落到 default。这种极端情况平时遇不到但在做数据清洗、数值可能是 NaN 的场景里确实会让人愣一下。另外case 后面的表达式是会求值的。写case getStatus()这种函数调用每次比较都会执行一次如果你在函数里干了有副作用的事排查起来会非常痛苦。case 后面老老实实放字面量或者常量这是最省心的做法。1.2 case 穿透是有意设计但九成场景你得写 break忘写break导致的 bug是所有 JS 新手都会经历的一课而且它不报错只是逻辑莫名其妙地多执行了一段排查时特别费劲。我见过一个真实例子一个订单状态处理函数case paid忘了 break结果付款成功的订单同时触发了发货逻辑测试环境因为数据少没发现上线第一天就出了乱子。但穿透本身不是缺陷它是 switch 存在的重要理由之一。多个值要走同一段逻辑的时候把 case 叠起来写比写一串if (a 1 || a 2 || a 3)要清晰得多switch (level) { case low: case medium: notifyNormal(); break; case high: case critical: notifyUrgent(); break; }这种写法表达的是“这几个值归为一类”意图非常明确。关键是要让人一眼看出你是故意的还是有意的。我的做法是两条一是叠在一起的 case 之间不留任何代码视觉上形成连续块二是项目里开启 ESLint 的no-fallthrough规则它会揪出那些“case 里有代码却没有 break”的情况而对空 case 叠放是放行的。这条规则开启成本极低收益极高建议所有新项目都加上。顺便提一句如果 switch 写在函数里return可以完全替代break而且更不容易漏function getLabel(type) { switch (type) { case a: return 甲; case b: return 乙; default: return 未知; } }这种写法我更喜欢因为它把“每个分支都直接结束”这件事变成了语法结构的一部分读者不用去数 break。1.3 default 放哪、switch(true) 值不值得用default 不一定非要放最后规范允许它出现在任意位置匹配时会先找所有 case都不匹配再跳到 default然后从那里继续往下执行。但这种写法几乎没有可读性收益反而会让读者困惑所以我从来不在中间放 default。真正有争议的是switch (true)这种写法switch (true) { case score 90: return A; case score 80: return B; case score 60: return C; default: return D; }它的原理是每个 case 表达式求值后和true做严格比较第一个为 true 的 case 被命中。优点是看起来像一张整齐的分档表比一长串if / else if视觉上更规整而且每行都是“条件 → 结果”的对应关系扫读效率确实高。但我不太推荐在团队代码里大量用它。原因有两个一是初学者读到switch (true)会愣一下需要额外的心智成本去理解二是它为真的时候才匹配没法表达“多个条件同时成立走哪个分支”这类复杂组合一旦逻辑变复杂还是得退回 if。我的判断标准是纯粹的数值分档、且分档边界值很规整的时候可以用其他情况一律 if-else。工具的价值在于降低理解成本如果它反而增加了那就别用。1.4 什么时候该用查表法把 switch 换掉写多了你会发现很多 switch 本质上是一张映射表输入一个值输出一个结果或者执行一个动作。这种时候用对象字面量反而更简洁const actionMap { create: () openCreateDialog(), edit: (id) openEditDialog(id), delete: (id) confirmDelete(id), }; function handleAction(type, id) { const action actionMap[type]; action ? action(id) : console.warn(未知操作, type); }这几种写法各有适用边界我整理了一张对比表写法适合的场景不适合的场景主要风险switch分支数 3~8 个条件都是离散值需要 return 提前结束分支超过 10 个、需要动态扩展忘写 break 导致穿透if-else 链判断条件是范围或复合条件分支很多且都是等值判断层级嵌套过深对象映射表输入值到行为/结果的一一对应需要动态增删需要范围判断、需要复杂的前置校验原型链污染用 Object.create(null) 或 MapMap键不是字符串对象、函数作为键、需要保证插入顺序简单的字符串键需要额外学习 API对象映射最大的好处是可测试性和可扩展性。想加一个分支加一行属性就行不用改动函数结构想单测某个分支直接取出对应函数调用即可。用 Map 还有一个额外优势键可以是任意类型而且不会有原型链上的干扰。用普通对象的时候记得Object.create(null)或者判断时用Object.prototype.hasOwnProperty.call(map, key)否则map[constructor]这种键会拿到意料之外的东西这是个老坑了。2. 三元运算符不是 if 的缩写它的价值在于能产出值2.1 表达式和语句的分界线决定了它该出现在哪新手最容易误解的一点是把三元当成“简写的 if”。其实它俩根本不是一个层级的东西。if 是语句不能放在需要值的位置三元是表达式它自己就是一个值。这个区别才是三元存在的理由。const label isActive ? 启用 : 停用; // 赋值右侧 return count 0 ? render list() : renderEmpty(); // return 后面 console.log(共 ${n} 条${n 1 ? 多条 : 单条}); // 模板字符串里 Button type{isPrimary ? primary : default} / // 属性值这些位置 if 都放不进去。所以判断该不该用三元标准不是“能不能写得更短”而是“我是不是需要在这里产生一个值”。如果需要值用三元如果只是要走不同流程、执行不同动作用 if。这条线划清楚了很多滥用自然就消失了。我见过最别扭的写法是拿三元去执行两个动作、然后丢掉返回值isLogin ? goHome() : goLogin(); // 这行没问题是个表达式语句这种写法其实还行但如果是下面这样就有问题了isLogin ? (doA(), doB(), doC()) : (doD(), doE());用逗号运算符把多个动作串起来塞进三元分支读起来像天书一行里藏了五个副作用。这种情况下 if-else 才是正解省下来的那几行根本不值得。2.2 嵌套几层算过分一个可以量化的判断标准关于嵌套三元社区里争论很多有人说一层都不该有有人说两层还行。我给一个自己的判断标准读这行代码的时候眼睛需不需要往回找配对。const level score 90 ? A : score 80 ? B : C;这行是两层嵌套。因为三元是右结合的实际解析成score 90 ? A : (score 80 ? B : C)整个结构是一条斜向下的阶梯从左往右读一遍就能理解不需要回头。这种我接受。const result a ? b ? c : d : e ? f : g;这行也是两层但因为它同时有真分支和假分支的嵌套读者必须在中间停下来分辨哪个:配哪个?。这种我就不能接受了无论它多短。所以真正的红线不是层数而是“是否存在真分支和假分支同时嵌套”。一旦出现立刻停下来重构。重构的方式有几种按优先级排第一种是提前 return把嵌套拆成多个判断function getDiscount(user) { if (!user.isMember) return 0; if (user.level vip) return 0.8; return 0.95; }第二种是抽成小函数给每段判断起个名字名字本身就是注释。第三种是查表把输入组合映射到结果。这三种方式都比嵌套三元好读而且好调试——你在断点里能清楚看到走到了哪一步。2.3 把副作用塞进三元是问题的高发区三元最常见的隐患是两个分支返回值类型不一致。比如const data res.ok ? res.data : showError(res.message);如果showError没有显式 return那么data在失败时是undefined成功时是个对象。后面如果直接data.list.map(...)失败路径就会报Cannot read property of undefined。这种 bug 特别隐蔽因为成功路径测不出问题只有异常场景才炸。我的经验是三元两个分支的返回值类型必须一致。要么都是字符串要么都是同一种对象要么都是函数。做不到就说明这里不该用三元。这条规则听起来很死板但它挡住的坑比你想象的多。另一个高发区是在三元里做赋值isReady ? (status ok) : (status fail);这行能跑但完全可以用status isReady ? ok : fail表达把赋值提到外面三元只负责产生值。这样职责就清晰了三元负责选值赋值语句负责写入。混在一起的时候一旦条件写错你很难判断到底是选错了值还是赋错了地方。还有短路求值这个特性值得用起来。三元只在被选中的那个分支求值另一个分支完全不执行所以可以用来做保护性访问const name user ? user.profile.name : 匿名;只要user是假值右边根本不会去读profile不会报错。这一点和的逻辑是一致的理解了这个特性很多防御性代码可以写得更短。2.4 和 || 、?? 混用时那些容易忽略的优先级陷阱三元运算符的优先级低于||和高于赋值。这意味着const a x || y ? 1 : 2;实际解析是(x || y) ? 1 : 2而不是x || (y ? 1 : 2)。如果你的意图是后者结果就完全错了。这类错误不会报错只会让逻辑悄悄跑偏。我现在写混合表达式一律加括号不是为了机器是为了下一个读代码的人也包括三个月后的自己。空值合并运算符??还有个特殊规定它不能和||、不加括号直接混用否则直接语法报错a || b ?? c // SyntaxError (a || b) ?? c // 可以虽然逻辑上可能没意义这个限制是语言设计者故意加的因为??和||的语义太接近又不同前者只认 null 和 undefined后者认所有假值混在一起极容易出错干脆让你必须显式表态。顺带说一下三元和??的配合这在处理配置默认值时很好用const timeout config.timeout ?? (isProd ? 3000 : 10000);这里先判断配置里有没有显式给值注意 0 和空字符串是有效值不会被??跳过没有的话再按环境给默认值。如果用||配置里写timeout: 0就会被当成没配置反而走默认值这是个很典型的坑。3. 循环的选择不是风格问题几种写法的语义差异3.1 for / while / do-while步进放在哪决定了出错概率这三种循环的区别用一句话概括就是“控制变量在哪里更新”。for 把初始化、条件、步进全部塞在括号里读者一眼就能看到循环的完整生命周期。这是它最大的优势也是最不容易出错的地方——你不会忘记步进因为它就写在那一行。while 只留条件步进散落在循环体里。它的风险在于如果你在continue之前忘了更新变量就会死循环let i 0; while (i 10) { if (i % 2 0) continue; // 死循环i 永远不增加 i; }而 for 循环里continue之后会照常执行步进表达式不会卡住。这个差异在实际写代码时很关键很多“页面卡死”的事故就是这么来的。do-while 的特点是循环体至少执行一次条件在最后判断。它的适用场景很明确先做一次再决定要不要继续。比如读取数据直到为空、先弹一次确认框直到用户做出选择let input; do { input prompt(请输入内容直接确定结束); } while (input ! null input ! );不过实际项目里 do-while 用得很少因为大多数“至少执行一次”的场景都可以用 for 或者直接写一遍逻辑来表达而 do-while 对读者来说不够直观。我个人的态度是能用 for 就用 for除非逻辑天然符合“先做后判”才考虑 do-while。3.2 for...in 和 for...of一个遍历键一个遍历迭代器这两个是最容易被混用的。名字只差一个字母行为完全不同。for...in遍历的是对象的可枚举属性名包括从原型链继承来的。它返回的键永远是字符串。用它遍历数组的时候有三个隐患一是顺序不保证虽然现代引擎对整数索引基本按序但规范没承诺二是如果数组上挂了自定义属性会被一起遍历到三是拿到的索引是字符串做算术时容易出意外。const arr [10, 20, 30]; arr.extra x; for (const k in arr) { console.log(k, typeof k); // 0 string, 1 string, 2 string, extra string }for...of走的是迭代协议调用对象的Symbol.iterator方法。它能用于数组、字符串、Map、Set、arguments、NodeList、生成器以及任何自己实现了迭代器的对象。它拿到的是值不是键而且可以配合break、continue、return使用。for (const v of arr) { if (v 20) break; console.log(v); // 10, 20 }两者的对比可以列成这样维度for...infor...of遍历内容属性名字符串迭代器产出的值适用对象普通对象、数组不推荐可迭代对象是否含原型链属性是否能否用 break/continue能能数组遍历顺序不保证按迭代器定义通常是索引顺序典型用途遍历对象的所有键、调试时查看属性遍历数组、字符串、Map、Set我的使用原则很简单遍历数组和任何可迭代结构一律for...of遍历普通对象的键要么for...in配合hasOwnProperty过滤要么直接用Object.keys()/Object.entries()转成数组再for...of。后者我更常用因为转成数组之后能得到所有数组方法的支持逻辑更可控。还有个细节for...of在遍历数组时确实有迭代器调用的开销超大数组百万级的紧密循环里用传统 for 会更快。但绝大多数业务场景的数组规模在几千以内这点差异完全被其他开销淹没不用为了性能牺牲可读性。真遇到性能瓶颈先用工具定位别凭感觉优化。3.3 var 到 let 的这个变化改变了循环里闭包的行为这是 JS 里最经典的面试题之一但它的价值远不止面试。看这段代码for (var i 0; i 3; i) { setTimeout(() console.log(i), 0); } // 输出 3 3 3原因在于var是函数作用域整个循环只有一个i三个箭头函数捕获的是同一个变量。等到定时器执行时循环早就结束了i已经变成 3。把var换成let就变成0 1 2。这不是什么语法糖而是规范层面的行为差异let在 for 循环里会为每一轮迭代创建新的绑定并且把上一轮的值复制到新绑定里。所以三个回调捕获的是三个互相独立的变量。for (let i 0; i 3; i) { setTimeout(() console.log(i), 0); } // 输出 0 1 2理解这一点之后很多以前需要靠 IIFE 解决的问题就自然消失了。以前写for (var i...) (function(j){ ... })(i)这种包裹现在完全不需要。同样for...of和for...in里用let声明循环变量也是每轮新绑定行为一致。顺带说一个容易被忽略的点let声明的循环变量在循环体内是不可重新声明的而循环体外也访问不到。这个作用域收窄本身就是一种保护能避免很多“循环结束后变量还残留”的问题。3.4 提前退出break、标签语句和 forEach 的局限单层循环里break和continue用起来很直观。麻烦的是多层嵌套。常见写法是打标记outer: for (let i 0; i 3; i) { for (let j 0; j 3; j) { if (i * j 4) break outer; } }标签语句能用但我很少用。原因有两个一是它会让代码看起来像回到了 goto 时代可读性差二是标签名和变量名共用命名空间容易冲突。更好的做法是把内层逻辑抽成函数用return跳出function findPair() { for (let i 0; i 3; i) { for (let j 0; j 3; j) { if (i * j 4) return [i, j]; } } return null; }这种写法意图清晰而且返回值本身就把“找到的结果”带出来了不用额外维护变量。另一个高频问题是forEach不能中断。forEach的回调里写break直接语法报错写return只是跳过当前这一次等价于continue。如果确实需要在遍历中提前结束有几个替代方案// 方案一some返回 true 时提前终止 arr.some(item { if (item.id target) return true; // 相当于 break return false; }); // 方案二every返回 false 时提前终止 arr.every(item { if (item.id target) return false; return true; }); // 方案三直接换成 for...of语义最清楚 for (const item of arr) { if (item.id target) break; }some和every这两个技巧知道的人不少但我更倾向于直接用for...of。因为用some表达“查找”需要读者在脑子里做一次转换而for...of加break是零转换成本的。代码对不对是一回事读起来累不累是另一回事后者往往决定了它能在项目里活多久。4. 三个语法点合在一起的三个真实场景4.1 状态码到 UI 的映射三种写法的取舍后台系统里最常见的一类需求接口返回一个状态码前端要根据它渲染不同的按钮组、文案和样式。这是 switch 最典型的用武之地。function getActions(status) { switch (status) { case draft: return [{ text: 编辑 }, { text: 删除 }]; case reviewing: return [{ text: 撤回 }]; case published: return [{ text: 下线 }, { text: 复制 }]; default: return []; } }这种写法好在每个分支机构清晰返回什么一目了然加分支只需要加一个 case。缺点是分支多了之后函数会变长而且返回值结构重复。换成对象映射表之后const ACTION_MAP { draft: [{ text: 编辑 }, { text: 删除 }], reviewing: [{ text: 撤回 }], published: [{ text: 下线 }, { text: 复制 }], }; const getActions (status) ACTION_MAP[status] ?? [];这版代码短了很多而且天然带默认值?? []处理了没匹配到的情况。但它是静态的如果按钮的显示条件需要依赖其他变量比如“只有创建人能删除”就得在拿到结果之后再做一层过滤。所以我的实际做法是纯静态映射用对象表带动态条件的用 switch 或者把条件逻辑下沉到按钮配置里。三元在这里的角色通常是处理状态对应的文案或者徽标颜色这种“一个值对应另一个值”的场景const badgeClass status published ? success : default;但要注意别让它蔓延到动作列表这种复杂结构上。我见过写成这样的const actions status draft ? [a, b] : status reviewing ? [c] : status published ? [d, e] : [];三层嵌套读起来要在脑子里配对三组冒号非常痛苦。这种时候 switch 或者对象表才是对的。4.2 数据归一化循环套 switch 是最高频的组合后端返回的数据结构经常是不规整的比如一个列表里混着不同类型、不同字段名的条目前端要先做一轮清洗才能用。这时候循环加 switch 的组合几乎躲不掉。function normalize(rawList) { const result []; for (const raw of rawList) { switch (raw.type) { case text: result.push({ kind: text, value: raw.content ?? }); break; case image: result.push({ kind: image, url: raw.src, width: raw.w ?? 0 }); break; case link: result.push({ kind: link, url: raw.href, text: raw.title ?? raw.href }); break; default: continue; // 未知类型直接跳过不污染结果 } } return result; }这个结构我用了很多次好处是每个分支的转换规则独立成一个 case改一种类型不影响其他类型。default里用continue而不是break是因为未知类型应该被丢弃而不是塞进结果里。这是个容易写错的地方如果用break会跳过后面的 push 逻辑继续下一轮效果其实一样但continue的语义更明确。这里循环用for...of而不是forEach理由是forEach里没法用continue只能写return语义上有偏差。而且for...of在调试的时候可以直接打断点看每一步forEach得进回调里稍微麻烦一点。还要注意??的使用。上面几处用??而不是||是因为空字符串是合法值不能被默认值覆盖。如果后端可能返回content: 表示“确实没有内容”用||会把它替换成看起来没差别但如果默认值是别的比如空用||就会把空字符串误判成缺失显示成占位符。这种细节在联调阶段特别容易翻车。4.3 条件类名三元最正当的用武之地前端写条件样式三元几乎是标配也是最不容易被滥用的场景因为它输出的永远是一个字符串const cls [ item, isActive ? item--active : , isDisabled ? item--disabled : , size small ? item--sm : , ].filter(Boolean).join( );这种写法比一长串字符串拼接要清爽而且每个条件都是独立的加一个样式只需要加一行。用数组加filter(Boolean)的好处是避免了多余的空格也避免了到处判断是否要加前导空格。如果是二选一的互斥样式三元更直接const level score 60 ? pass : fail;但要注意别在一个三元里塞太多东西。我见过写className{a ? b ? x : y : z}的虽然只是两层但左边真分支里又套一层读的时候要分辨?和:的配对关系成本一下就上去了。这种拆成两个变量、或者用数组拼装都会好很多。5. 第 20 天之后这三个点该怎么复习才记得住5.1 做一张只属于自己的对比表语法笔记最容易犯的毛病是抄文档。抄的时候觉得懂了过两周再看跟看别人的笔记一样陌生。我后来改了个习惯不抄定义只记“什么时候会出错”和“什么场景该选哪个”。比如 switch 这一块我的笔记上只有三行case 是严格比较字符串和数字不匹配忘 break 不报错但逻辑错用 ESLint 拦分支超过八个就考虑查表。这三行覆盖了我实际踩过的全部坑比抄十页语法格式有用得多。循环这块的对比表可以按“需求”反查写法需要提前跳出用 for 或 for...of需要拿到值和索引用for...of配entries()需要遍历对象属性用Object.entries()需要保证至少执行一次才考虑 do-while。写表的时候每一行都要配一个自己真实写过的例子没有例子的行就删掉说明那个点你还没用上。5.2 四道自测题答不上来就说明还没吃透第一题switch(1) { case 1: ... }会走进这个 case 吗为什么第二题for (var i 0; i 3; i) { setTimeout(() console.log(i)) }输出什么把 var 换成 let 呢两者的差异在规范层面是怎么实现的第三题有一个嵌套循环内层找到目标后要跳出所有循环有几种写法各自的优缺点是什么第四题const x a ? b : c ? d : e;实际是怎么结合的如果要改成“a 为真且 b 为真走 d”该怎么写这四题能一口气答对说明这三个语法点基本过关了。答不上来的那题回去把对应的章节重看一遍然后动手敲一遍验证别只看。5.3 一个更有效率的练习方式光看笔记和刷题效果都不如去改真实代码。我的建议是找一个自己以前写过的项目专门做一次“控制流重构”——把所有嵌套超过两层的 if 拆开把所有超过两层嵌套的三元改掉把所有forEach里用return当continue的地方换成for...of把所有忘写 default 的 switch 补上。改完之后对比一下行数和可读性。你会发现代码可能变长了几行但读起来顺畅了很多。这个体验很重要它会在你以后想偷懒写嵌套三元的时候把你拉回来。还有一个我一直在用的习惯写完一段带分支的代码隔一天再回来看。如果第二天早上你自己都要花几秒才能看懂昨天写的那行三元那它就是不合格的趁还没提交赶紧改掉。代码是写给人看的机器只是顺便执行一下这个道理在学语法的第 20 天就该记住。