学 Java 学到分支语句这里很多人会突然觉得“程序不是从上到下跑吗怎么还要判断”。我踩过的坑是顺序思维一旦固定再看 if、switch 这类代码总会有一种“电路忽然多出岔路”的别扭感。实际上现实里的任何业务流程都充满判断——先看用户登录了没有再看权限够不够最后才决定展示哪块内容。如果不能把代码执行路线想象成一张有岔路和回环的地图后面写 Android 界面逻辑会非常吃力。这一篇自学记录7-1聚焦于分支语句也就是程序的“岔路口”。我会从头梳理 if 的三种形态、switch 的完整用法、三元运算符这些必会内容并且把它们在 Android 场景里最常用的位置也一并提一下。适合处于 Java 入门阶段、正在为 Android 打基础的人读也适合学完语法后想回头补“工程思维”的人翻一翻。1. 分支语句在自学路线里的位置先厘清三个基础概念1.1 顺序、分支与循环为什么分支是第一个分水岭程序有三种基本结构顺序、分支、循环。顺序结构最简单一条指令执行完再执行下一条像按菜谱做菜洗菜、切菜、下锅。分支结构则是“如果土豆坏了就换番茄如果锅热了才倒油”它让程序能够根据当前条件选择不同的执行路径。对刚起步的初学者来说顺序结构几乎没有难度循环结构则更偏向“重复做某件事”的抽象。分支语句恰恰卡在中间它逻辑简单但极易因为条件判断不严谨、大括号省略、else 匹配错位而产生隐蔽 Bug。所以能否把分支语句用得干净、准确直接决定后面能不能顺畅地写登录校验、页面跳转和状态切换。1.2 从“计算”到“决策”分支在改变程序的什么初学者最容易把分支语句理解成一种“计算工具”其实它是“决策工具”。计算解决的是已知条件下得到什么结果决策解决的是不同条件下走哪条路。举一个非常贴近 Android 的例子网络请求返回的时候结果可能有成功、超时、无网络、服务端错误几种。程序需要根据结果选择不同的 UI 展示成功时显示列表失败时显示重试按钮。如果不用分支这段逻辑根本没法表达。也就是说分支语句的价值不在于算出某个数值而在于控制程序后续的状态走向。这一点理解了之后再看 if、switch、三元运算符就不会只停留在“语法长什么样”而是会去想“当前这个场景哪种分支方式更自然地表达了决策逻辑”。1.3 本系列笔记的写作约定这篇记录默认读者已经掌握了变量、基本数据类型、运算符和简单的输入输出。示例代码以 Java 传统语法为主因为 Android 开发中常见的历史代码仍然大量使用传统风格。关于新版 Java 的 switch 表达式我会单独放在后面讲作为“扩展看点”不要求入门阶段立刻掌握。另外代码示例会刻意控制规模能说明问题即可不堆复杂业务。2. if 语句最直觉但也最容易埋雷的结构2.1 if 的条件必须是布尔值没有“约定俗成”if 的语法人尽皆知真正值得反复强调的是括号里的表达式最终结果必须是布尔类型 true 或 false。int age 18; if (age 18) { System.out.println(可以注册); }这段代码里的age 18是布尔表达式。比较运算符的结果一定是布尔值所以可以放在 if 中。但有些语言允许if (age)这种写法Java 不行。Java 编译器会直接报错因为 int 类型不能自动转换为 boolean。这个细节在自学时容易忽略。我见过有人从其他语言转过来后在 Java 里写if (isLogin)如果isLogin本来就是布尔变量没问题但如果是 int就会立刻踩编译错误。尽早形成“条件必须是布尔”的肌肉记忆后面读写代码都会顺畅很多。2.2 else-if 链条的执行顺序命中即停当需要判断多个互斥条件时最常见的写法是 if-else if-elseint score 78; String level; if (score 90) { level 优秀; } else if (score 80) { level 良好; } else if (score 60) { level 及格; } else { level 需要再加把劲; } System.out.println(评价 level);这段代码的关键在于程序从上到下逐条判断一旦某个条件为 true就会进入对应分支并且整个 if-else if 链条结束后续分支不再判断。如果 score 是 95那么直接命中“优秀”不会再去比较score 80。这个特性在实际业务里很常用。比如 Android 登录页校验输入先判断用户名是否为空再判断密码是否为空最后判断格式是否正确。空值校验必须放在最前面因为一旦用户名空后面所有校验都可能基于不完整的数据。还有个隐藏性能点条件判断顺序会影响平均耗时。把最容易命中、计算成本最低的条件放前面可以少吃很多无谓判断。这个习惯养成后写复杂校验逻辑会自然更高效。2.3 大括号永远不要省略Java 允许 if 省掉大括号只包住一行语句。初学时期为了少打字很容易写出这样的代码if (isOk) doSomething();如果这里只测一个方法风险尚可但一旦后续加需求你就会面临一个著名陷阱——else 匹配错位也就是“悬空 else”问题。看这段代码boolean morning false; boolean weekend true; if (morning) if (weekend) System.out.println(去爬山); else System.out.println(继续睡);从缩进看else 似乎对应if (morning)意图是“如果不是早晨就继续睡”。但 Java 语法规定else 总是与最近的 if 配对所以这里实际上匹配的是if (weekend)。当 morning 为 false 时程序什么都不会输出当 morning 为 true 且 weekend 为 false 时反而输出“继续睡”。这和一个正常人基于缩进的阅读直觉完全不同。我的建议很简单一律写大括号。就算分支里只有一条语句也要把{ }写上。这不只是风格问题是在源头上消灭一整类逻辑事故。2.4 分支作用域变量声明的位置决定你能在哪用在 if 块内声明的变量出了块就不存在。if (score 60) { String result 通过; } System.out.println(result); // 编译错误result 不在作用域内初学者老老实实按教程写可能一次通过但改代码时容易踩有人为了让变量在 if 外可访问把声明放在 if 之前这样逻辑上正确可读性也没问题。关键是要理解变量生命周期由大括号限定这也是很多“明明定义了外面却访问不了”的报错根源。3. switch 语句什么时候用它比 if 舒服3.1 switch 能匹配哪些类型传统 switch 可以匹配 int、char、byte、short以及它们的包装类型还有 String 和枚举类型。实际开发中用得最多的是 int 和 String。但有几类情况不能直接用 switch比如直接判断一个浮点数范围switch 做不了。浮点数因为精度问题本身就不适合精确等于判断所以这也不算缺陷。只要把这类需求转换成 if 的范围判断就好。它真正合适的是“某个变量的取值有限、枚举明确”的场景。比如网络请求的错误码、页面状态、消息类型、订单状态。3.2 break 和 fall-through连续 case 是特性也是坑switch 的经典写法是每个 case 后跟 break。如果漏掉 break程序会继续执行下一个 case 的代码这叫“穿透fall-through”。int state 1; String desc; switch (state) { case 1: desc 加载中; case 2: desc 加载完成; break; default: desc 未知; break; } System.out.println(desc);state 为 1 时会先给 desc 赋“加载中”但没有 break于是继续执行desc 加载完成最终输出“加载完成”。这种逻辑错误很难靠肉眼第一时间发现因为代码看起来完全没问题。fall-through 本身也可以成为特性。当一个 case 需要和多个值共用同一段逻辑时可以让 case 连续排列int month 3; String season; switch (month) { case 1: case 2: case 3: season 春季; break; case 4: case 5: case 6: season 夏季; break; default: season 未知月份; break; } System.out.println(season);这种写法是合理的但需要格外保持注释清晰否则后来者很容易误以为是漏了 break。3.3 default 分支的位置和必要性default 相当于 if 里的 else兜住所有没有匹配的情况。它不一定写在最后但为了可读性通常放在最后。入门阶段最好养成每条 case 都写 break 的习惯default 也写。哪怕 default 里什么都不做也可以用注释说明“当前不处理该情况”。这会让代码审计时减少大量猜测。3.4 switch 和 if 怎么选用一张表总结对比点ifswitch适用场景范围、布尔组合、复杂判断值明确、枚举有限可读性条件多且复杂时层层嵌套较难读结构与分支一目了然判断类型任意布尔表达式数值、字符、String、枚举支不支持穿透不存在穿透概念不写 break 会穿透空判断可以直接判 nullString 判 null 要单独防一个非常务实的经验如果判断条件是“一个整数或字符串在几个固定值里选一”优先 switch如果条件是“数值落在某个区间或者多个条件组合”必须用 if。强行把区间判断塞给 switch 会很难受把固定枚举判断全写成 if 链条则显得啰嗦。4. 三元运算符压缩代码的同时别压缩了可读性4.1 语法结构与类型要求三元运算符是 if-else 的简化版语法为条件 ? 值1 : 值2int age 17; String tip age 18 ? 已成年 : 未成年;条件为 true 时取值1为 false 时取值2。这里有一个很重要、但新手容易忽略的点值1和值2的类型必须兼容。String result condition ? 成功 : 100; // 编译错误条件表达式要求两个分支能统一成一个类型。上面这个例子中一个 String、一个 int编译器无法确定 result 类型直接报错。该特性初看简单真正写复杂表达式时很容易引发类型推断问题。4.2 什么时候该用什么时候别用三元运算符适合简单赋值场景尤其是一个条件决定一个值的情况比 if-else 简洁太多。但有一个大忌嵌套三元。String tag a ? A : b ? B : c ? C : D;这行代码看起来短阅读时却要把多个三元的嵌套关系在脑子里一层层解开非常容易出错。团队协作里这种写法往往需要读者反复确认优先级。我的建议是嵌套超过一层立刻改成 if-else if 或 switch。另一个常见的“假简洁”在打印日志里用三元做大量拼接。表面短但字符串串联本身消耗不小代码可读性也没有实质提升。该用 if 的时候不用硬用三元。4.3 三元运算符与短路判断的关系很多人没有意识到三元运算符存在短路效果条件为 true 时只计算值1不会计算值2条件为 false 时则相反。这一点结合方法调用很有价值。String name user ! null ? user.getName() : 匿名;当 user 为 null 时访问 user.getName() 会抛空指针异常但因为条件为 true 时才会计算第二个操作数程序只有在 user 非 null 时才会调用 getName()。这算是三元运算符参与空值保护的一种常见方式不过当逻辑更复杂时还是建议用 if 显式处理意图更清楚。5. 现代 Java 的 switch 表达式先记个轮廓5.1 箭头语法和 yield较新的 Java 版本支持 switch 表达式写法上不再依赖 break 和冒号而是用箭头int day 3; String type switch (day) { case 1, 2, 3, 4, 5 - 工作日; case 6, 7 - 休息日; default - 未知; };这种写法天然避免 fall-through因为每个箭头分支执行完就会退出。如果需要在一个分支里计算一个值可以用 yieldString result switch (code) { case 1 - { String temp 处理中; yield temp 状态; } case 2 - 完成; default - 未知; };对于初学者的意义在于它是 if-else 在“多路取值”场景的强大替代。代码更短分支边界更清晰。不过它的普及需要项目编译环境支持相应 Java 级别。5.2 Android 项目里能不能直接用Android 开发环境和 SDK 对 Java 版本的支持是逐年提升的但实际工程为了兼容和历史代码往往采用较保守的编译级别。所以初学阶段我的建议是认识新语法写代码时优先用传统 switch 和 if。等熟悉了项目构建配置、懂得按需调整编译参数之后再在合适的代码里尝试新版写法也不迟。一个更容易踩的点是在旧版 Android 设备或旧构建链路上某些新语法需要额外配置脱糖处理否则会在运行时出问题。这些配置细节对于刚学分支语句的人而言属于分散注意力的信息。先把核心逻辑写对把 break 和 default 的思维建立好再去考虑语法糖层面的事。6. Android 场景中的分支应用从课堂语法到项目思维6.1 空值守卫判空永远排在业务逻辑前面Android 开发中空指针异常是最常见的崩溃来源之一。很多时候不是数据真的没有而是接口返回的字段在某种情况下为 null代码却直接调用了它的方法。固定的解题思路是先判空再操作。if (user ! null user.getPhone() ! null) { phoneTextView.setText(user.getPhone()); } else { phoneTextView.setText(未绑定手机号); }这里的user ! null ...用到了短路特性user 为 null 时user.getPhone()根本不会执行因此不会抛出空指针。养成把判空写在最前面的习惯比后面学会各种“安全调用”技巧更可靠。6.2 布局和组件的状态切换Android 界面最典型的场景是同一个页面在不同加载阶段显示不同的控件组合。很多新手会写一堆 setVisibility 调用但这里最适合用 switch 来统一管理。int state STATE_SUCCESS; switch (state) { case STATE_LOADING: progressBar.setVisibility(View.VISIBLE); contentView.setVisibility(View.GONE); errorView.setVisibility(View.GONE); break; case STATE_SUCCESS: progressBar.setVisibility(View.GONE); contentView.setVisibility(View.VISIBLE); errorView.setVisibility(View.GONE); break; case STATE_ERROR: progressBar.setVisibility(View.GONE); contentView.setVisibility(View.GONE); errorView.setVisibility(View.VISIBLE); break; default: break; }这样的话状态与 UI 的对应关系集中在一个方法里阅读时能够很快看到每种状态对控件的完整影响。如果改用 if-else if多状态叠加时很容易漏掉某个控件没有恢复默认状态。6.3 点击事件里的分支处理Android 中点击事件通常由监听回调触发但同一页面上可能有多个按钮共用一个监听器需要通过 id 判断。public void onClick(View v) { if (v.getId() R.id.btn_save) { saveData(); } else if (v.getId() R.id.btn_cancel) { finishPage(); } else if (v.getId() R.id.btn_retry) { reloadData(); } }这种写法本身没有问题。不过当按钮很多时用 switch 处理 id 会显得更规整。分支语句的选择会影响代码的长期维护体验这也是为什么我说“工程思维”要尽早建立。6.4 系统版本差异与功能降级Android 系统版本跨度大很多新接口只有高版本可用低版本需要走另一套逻辑。这本质上是一个典型的分支适配问题。if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { // 动态请求权限的代码 } else { // 低版本安装时已授权直接走旧逻辑 }写这段代码时核心是明确“条件边界”。不能随手写成否则正好在边界版本的设备上会走错分支。这种细微差别恰恰是分支语句自测时最容易考察的点。6.5 错误码与回调结果的分支处理网络回调的成功、失败、超时通常用错误码表达。用 switch 处理错误码比用一长串 if 清晰得多switch (errorCode) { case 0: updateList(data); break; case 1001: showToast(参数错误); break; case 1002: showToast(登录过期); break; default: showToast(未知错误); break; }这种模式下新增一种错误码只需要增加一个 case不影响原有逻辑。如果用 if-else if 堆积每加一种情况就要多读一层判断维护成本会明显上升。7. 初学分支语句的常见问题排查实录7.1 症状、原因与对策速查表现象可能原因解决思路代码符合预期变量却“没定义”变量声明在了某个分支内部把声明放到分支之外条件明明为真却不进分支布尔表达式被误写成了赋值或相等判断出错检查与else 表现不符合缩进预期悬空 elseelse 就近匹配全部加上大括号switch 结果总是最后一个分支的值前面 case 漏了 break穿透执行检查每个 case 结尾的 breakswitch 的 String 比较偶尔报空指针判断值本身为 null先做判空或统一转非空默认值程序进入分支后崩溃分支内直接访问了可能为空的引用先判空再访问这是我在排查代码时最常用到的几类问题几乎每条都对应真实场景。初学者遇到问题不要急着改代码先判断这是语法问题、作用域问题还是空值问题排查速度会快很多。7.2 一个案例账号状态判断总是命中第一分支某一次练习里别人写了一段判断账号状态的逻辑int status 2; String desc; if (status 1) { desc 正常; } else if (status 2) { desc 冻结; }问题很明显if (status 1)是赋值表达式。Java 里这个写法在 int 类型下其实不能编译因为赋值表达式的值是 int不是 boolean。但如果我们把 status 换成 boolean则会遇到更隐蔽的问题boolean locked false; if (locked true) { // 永远进入 }这里locked true的值是 true所以条件永远成立。等号误写成赋值危害就在这种“永远走入某一分支”的逻辑错乱上。解决办法很机械条件里的相等判断坚持把常量写在左边而不是变量写在左边。if (true locked)能在误写为时让编译器直接报错。7.3 一个案例switch 忘记 break 导致结果穿透模拟一套费用计算场景0 表示免费1 表示普通价2 表示会员价。某初学者在第一个 case 里忘了 breakswitch (userType) { case 0: fee 0; case 1: fee 10; break; case 2: fee 8; break; }当 userType 为 0 时本来应该免费结果 fee 先赋值为 0随后穿透到fee 10免费用户被收取了普通价。这类问题用调试器看一遍就能发现最有效的手段就是写完后检查每个 case 的 break。我还记得自己初学 switch 时为了减少代码试图把 break 统一放在分支末尾以外的地方。这造成过一次非常诡异的运行成功但结果错误。从那以后我对 break 的态度就是写在 case 内部的最后一行不省略、不早退。7.4 一个案例嵌套 if 引发的可读性问题复杂业务里最常见的反模式是嵌套了好几层 if看起来像这样if (user ! null) { if (user.isVip()) { if (order ! null) { // 处理逻辑 } } }逻辑没错但阅读负担极重。改善方式有两种第一种是提前返回把非法情况逐步排除第二种是把复合条件合并。if (user null || order null) { return; } if (user.isVip()) { // 处理逻辑 }这种写法健康、直白也符合 Android 代码常见的“先校验再执行”风格。分支语句学到最后拼的不是语法而是如何让分支结构保持清晰。8. 自学自测分支语句的练习设计8.1 五个由浅入深的练习题第一个练习输入一个整数用 if-else 判断它是正数、负数还是零。这里不需要复杂逻辑重点在于覆盖三种互斥情况并检查边界值。第二个练习将成绩分数转换为等级用 if-else if 链完成。练习重点是判断顺序必须先判断高分区间再判断低分区间否则逻辑会被高优先级条件吞掉。第三个练习根据用户输入的月份用 switch 输出季节。练习重点是 case 连续排列和 break 的配合。第四个练习模拟一个登录判断用户名为空、密码为空、密码长度不足、全部通过分别给出不同提示。练习重点是空值守卫和判空顺序。第五个练习写一个函数接收一个网络请求状态码用 switch 返回对应的提示文案并且测试 default 分支。练习重点是枚举型判断的覆盖性和穿透风险。8.2 每道题的自查点完成每个练习后我都会按固定问题清单检查条件表达式是否全部是布尔结果每一个 else 是否配对上了正确的 if分支块内声明的变量有没有被外面错误引用switch 的每个 case 是否都有恰当 break是否考虑了默认情况和空值情况嵌套层级是否能进一步简化这套自查清单比单纯把代码跑通更有价值。我身边的同行在评审代码时基本也是按同等项目体检表来检查新人的分支逻辑。养成这套习惯不只是为了通过自学阶段更是为了进入实际 Android 项目后能让别人一眼看懂你的代码路径。分支语句这一节适合反复拆开揉碎了慢慢消化。学的时候不要图快把每个案例都独立写一遍错误也亲手犯一遍比看十遍教程都记得牢。我这个记录就是这么过来的越是早期觉得繁琐的小细节后面越能帮你省下大把调试时间。