Android 面试里，流程控制 if-else 与 switch 经常以一道开放题出现："你在项目里是怎么用的？"这道题答不好，往往不是知识不够，而是很少把做过的事按"场景、做法、结果"的结构梳理过。追问起来，第一层问语法，第二层问匹配规则，第三层问为什么这样设计——三层下来，背题的人和真用过的人立刻分层。把来龙去脉和落地场景一起讲清楚，比背一长串定义得分高得多。
先把结论立住：流程控制到底在控什么
一句话：if-else 是按布尔条件选路径，switch 是按一个表达式的等值结果做多路分支。两者解决的都是"下一步走哪条路"，但 switch 在分支多了以后可读性更稳，if-else 在范围判断和组合条件上更灵活。
这里要先立住一个工程前提：卫语句早返回能让主逻辑保持一条直路。一个函数里如果先判空、再判权限、再判状态，每一层都用 if (...) return; 把异常路径挡在外面，正常逻辑就能平铺直叙，不用层层往右缩进。反过来，嵌套层级超过三层就该考虑重构——不是语法不允许，而是人在三层以上的缩进里很容易漏看某个分支的退出条件，bug 往往就藏在那里。
机制拆解：switch 的表达式与匹配规则
Java 的 switch 有两套写法，必须分清楚。传统 switch 语句用 case 值: 加 break，忘了 break 就会"穿透"到下一个 case，这是经典坑。Java 12 引入、Java 14 转正的 switch 表达式用 case 值 -> 结果 的箭头语法，箭头分支默认不穿透，还能直接把值返回给一个变量，写起来更短也更安全。
两个容易被忽略的匹配细节值得单独拎出来。第一，String 的 switch 内部用 equals 比较，传入 null 会直接抛 NullPointerException，而且不会走 default——很多人以为 default 能兜底，结果 null 在匹配阶段就炸了。第二，枚举 switch 漏分支没有任何编译警告，新增一个枚举值后，既有 switch 不会提醒你补 case，运行期才会漏掉处理。这正是为什么用枚举做状态分发时，要么每个 switch 都带 default，要么配对用编译器能检查的穷举。
编译层面，JVM 会根据 case 的密集程度在 tableswitch（连续值，O(1) 跳转）和 lookupswitch（稀疏值，二分查找）之间选择，所以"switch 比 if-else 快"只在分支多且密集时成立，分支少的时候两者几乎没有差别，选型时不必为了这点性能牺牲可读性。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 流程控制：卫语句、switch 表达式、穿透与枚举穷举
String op = "add";
// switch 表达式：箭头语法不穿透，可直接返回值
int r = switch (op) {
case "add" -> 1;
case "sub" -> 2;
default -> 0;
};
// 卫语句早返回，主逻辑保持直路
int grade(int x) {
if (x == null) return -1; // 异常路径先挡掉
if (x > 100) return 0; // 卫语句，不必再缩进
if (x > 80) return 1;
return 2;
}
// 传统 switch 语句：忘记 break 会穿透到下一个 case
int oldStyle(String s) {
switch (s) {
case "a": return 1;
case "b": // 没有 break，会继续落到 "c"
case "c": return 3;
default: return 0;
}
}
// 枚举 switch：新增枚举值不会编译报错提醒补分支
enum Status {
OPEN, CLOSED, PENDING } // 假设日后加 DRAFT
String label(Status s) {
return switch (s) {
// 漏了 DRAFT 编译期无警告
case OPEN -> "开";
case CLOSED -> "关";
case PENDING -> "待处理";
};
}
这段代码值得盯三处：第一处，switch 表达式用箭头返回值，天然规避穿透，比传统写法少写一堆 break；第二处，卫语句把异常路径挡在前面，主逻辑 x > 80 这段不再嵌套，读起来是一条直路；第三处，枚举 switch 漏分支在编译期完全安静，这是运行期隐患的来源。面试讲到这一层，基本就稳了。
最常见的几个坑
最常见的坑是 String 的 switch 传入 null 直接抛空指针，且不会走 default。正确做法是在 switch 之前先判空，或者用 Objects.requireNonNull 把空值挡在匹配阶段之外，default 分支只负责"意料之外的非空值"，不该替 null 兜底。
其次是枚举 switch 漏分支没有编译警告。新增枚举值后，既有 switch 不会提醒你补 case，运行期才漏处理。可用编译器能检查的穷举（如 Java 的增强 switch 表达式在分支不全且没 default 时会报错）来把这类隐患提前到编译期。
还有一个更隐蔽的坑：深层嵌套 if 在热点路径上不只是可读性差，还会影响分支预测。CPU 的分支预测对"总是走同一条路"的卫语句很友好，但对频繁翻转的多层嵌套判断会反复预测失败，带来可观测的性能抖动。能用扁平的卫语句或查表法替代的，优先替代。
再一个是把 switch 当成"性能最优"的默认选择。分支少、条件是非等值范围判断时，if-else 反而更直观；switch 的优势在分支多且等值匹配时才有意义，选型要看场景而不是看传言。
面试中的经典追问
"请简单介绍一下 if-else 与 switch，它们在 Android 开发中起什么作用？"——一句话定位：两者都是按条件选路径的分支结构；一个场景佐证：用卫语句把参数校验、权限判断挡在前面，主业务逻辑保持平铺；一个边界收尾：switch 在等值多分支时可读性更优，范围判断还是 if-else 更合适。按"结论—依据—边界"三步走，比背一长串语法得分高。
"if-else 与 switch 的底层原理是什么？能不能详细说一下？"——别停在语法表层：动机是"按条件选路径"，机制是 switch 在密集分支上用 tableswitch（O(1) 跳转）、稀疏分支上用 lookupswitch（二分），代价是等值匹配的局限和穿透风险；if-else 是顺序求值，条件复杂时灵活但在分支极多时可读性下降。关键处落到实现，面试官会记住你。
"在使用流程控制时遇到过什么问题？"——行为题，拿真实案例说话。比如曾有一个多层嵌套的订单状态判断，某次加状态后在第三层漏了 return，导致两种状态走到了同一段发货逻辑，靠"复现—二分定位引入点—补回归用例"四步收住。讲这种结构比空谈概念有说服力得多。
"switch 和 if-else 相比，优劣在哪？"——先列可选方案：卫语句、查表（Map 分发）、策略模式；再按可读性、性能、可维护性逐项对比，最后给出场景结论：分支多且等值用 switch 表达式，范围判断或条件组合用 if-else，超复杂分发考虑策略模式。把"嵌套过深的可读性代价"摆到台面上再决定。
工程落地：真实项目里怎么用
流程控制不是只在面试题里出现。实际项目里有几个高频落点：一是把所有参数校验、权限判断、状态前置检查写成卫语句，让核心业务函数总是从"合法状态"开始，审阅代码时一眼能看到主路径；二是用 switch 表达式替换传统 switch 语句，彻底消灭穿透类 bug，同时把分支结果直接赋值，减少临时变量；三是把"状态码→文案/动作"这类密集等值分发从一长串 if-else 改成 Map 查表或枚举分发，新增类型时只改一处。
一个稳妥的团队约定：函数开头用卫语句清场，主逻辑不允许超过三层嵌套；等值多分支一律用 switch 表达式而非传统 switch；枚举做状态机时，每个 switch 都必须能编译期穷举或显式 default。把这几条写进代码规范，比靠人记分支靠不靠谱稳得多。
给正在准备面试的你
理解流程控制之后，需要在真实项目里练一遍：找一个你写过的深层嵌套函数，把它改造成卫语句版本，对比两段代码在可读性和行数上的差异；再亲手写一个 switch 表达式，故意漏掉一个 case 看编译器会不会提醒你。这两步做下来，比再读三遍语法文档都管用。
如果只记两句话，就记这两句：第一，卫语句早返回能让主逻辑保持一条直路，嵌套超过三层就该重构；第二，switch 表达式用箭头语法天然不穿透、能返回值，比传统 switch 语句更值得优先使用。把这两句讲顺，流程控制这一关就过了。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android 软件开发面试·从入门到精通」连载系列
上一篇：运算符与表达式：整除、短路、位运算与优先级
下一篇预告：循环-for-while-do-while：遍历与终止的工程课
有任何问题欢迎在评论区留言交流。
