企业官网建设流程全解析

学了六讲Java基础，变量、数据类型、运算符都过了一轮之后，我在第七讲终于遇到了一个让代码真正“活”过来的知识点——分支语句。说实话，前面那些内容就像在厨房备菜，葱姜蒜切好了、肉也腌上了，但还没开火；分支语句就是那个决定“先炒哪个菜、放不放辣椒”的动作。如果你也在自学 Java4Android，这一讲建议你放慢节奏。因为后面做Android界面交互时，按钮点击、输入校验、网络状态判断，几乎每一步都离不开几个if。

分支语句本身不复杂，但它是从“看懂代码”跨到“写对代码”的一道坎。我在这一讲里反复翻车，也总结了不少经验，这篇就当作第7讲的完整自学笔记，把if、else if、switch、三元运算符这些内容一次讲透，顺带记录几个我自己踩过的典型坑。

1. 分支语句：程序里每一条“分岔路”

1.1 为什么学到这一讲必须停下来搞懂分支

前六讲的内容，说到底都是在“准备材料”：变量负责装数据，运算符负责加工数据，输出语句负责展示结果。这些代码的毛病在于——它们永远从上到下按顺序执行，不会根据情况改变路线。就好比一台只能按固定菜单出菜的机器，不管顾客说“不要葱”还是“多点辣”，它都端出同一盘菜。分支语句的出现，就是为了解决这个问题。

Java的分支语句主要分三类：if系列、switch、三元运算符。三者的本质都一样——根据某个条件的真假，决定程序走哪条路。但它们的适用场景、写法和坑完全不同，混着用很容易写出“能编译但行为不对”的代码。

我在初学阶段最大的感受是：分支语句的语法一天就能背下来，真正难的是“条件怎么写才对”。你至少得想清楚：程序在什么情况下该走A路、什么情况下走B路、有没有第三种情况，以及条件判断的顺序会不会影响最终结果。

1.2 分支的本质：一个布尔表达式决定走向

所有分支语句的底层核心，都是布尔表达式（boolean expression）。Java里的布尔表达式最终都会计算出一个true或false的结果。最常见的布尔表达式是由比较运算符构成的，比如：

int age = 18; boolean isAdult = age >= 18; // true

这里的age >= 18就是一个布尔表达式，结果是true，于是isAdult这个变量就存了一个false或true。分支语句做的，就是“看这个结果是true还是false，然后决定执行哪段代码”。

这里有个特别容易忽略的点：布尔表达式不一定是比较运算，它本身可以就是一个boolean变量。比如Android开发里经常会出现这种写法：

boolean isLogin = false; if (isLogin) { // 显示"已登录"的界面 }

if (isLogin)本质上就是在判断isLogin == true。很多新手会画蛇添足写if (isLogin == true)，虽然结果一样，但代码啰嗦，而且一旦手滑写成if (isLogin = true)，那就变成了“把true赋值给isLogin”，这个条件永远成立，程序就跑偏了。这个坑我在后面专门说。

2. if家族解剖：单分支、双分支与多重分支的正确姿势

2.1 最基础的if-else：先想清楚“否则”分支

Java里最基础的分支结构是if，它可以单独使用，也可以和else配对。单独使用时，只有当条件为true才会执行大括号里的代码，条件为false就什么都不做：

int score = 75; if (score >= 60) { System.out.println("及格了"); }

这种写法在“只需要处理一种特殊情况”的场合很合适。但如果你发现程序“不满足条件时”也需要做点什么事情，那就得用if-else了：

int score = 45; if (score >= 60) { System.out.println("及格了"); } else { System.out.println("没及格"); }

我刚开始学的时候，经常犯的毛病是：条件满足时写一堆处理逻辑，条件不满足时就“忘了”加else。结果程序行为缺失了一半。后来我给自己定了一个规矩——凡是写if，先问自己两个问题：第一，条件不满足时程序应该做什么？第二，如果什么都不做，我是故意不处理，还是漏掉了？养成这个习惯之后，分支逻辑就完整多了。

2.2 else if链条的排列顺序：最容易翻车的地方

当判断条件不止两个时，就需要用到else if。最经典的例子是成绩分档：

int score = 85; if (score >= 90) { System.out.println("优秀"); } else if (score >= 80) { System.out.println("良好"); } else if (score >= 70) { System.out.println("中等"); } else if (score >= 60) { System.out.println("及格"); } else { System.out.println("不及格"); }

这段代码的逻辑是从上往下逐条判断，一旦某个条件为true，后面的就不再执行了。正因为这个“一旦匹配，立即退出”的机制，条件顺序就成了关键。

我踩过的一个真实例子是：一开始我把条件写反了，先判断score >= 60，再判断score >= 80。当时以为没关系，结果考了85分的人，第一个条件score >= 60直接命中，程序输出“及格”就结束了，后面的“良好”根本轮不到。所以这里一定要记住一个原则——范围大的条件放在后面，范围小的放在前面，或者反过来用“从窄到宽”的顺序判断。

更稳妥的做法，是先用区间把条件写死：

if (score >= 90 && score <= 100) { // 优秀 }

这样每个分支的边界都清晰，即使顺序调整，逻辑也不会乱。缺点是多写一点代码，但对初学者来说，把边界写明确比省那几个字符重要得多。

2.3 嵌套if的缩进规范与可读性

有时候条件不是一层能说完的。比如判断“用户是否登录”之后，还要进一步判断“用户是否有权限”。这种场景就要用到嵌套if，也就是if里面再套if：

boolean isLogin = true; int level = 2; if (isLogin) { if (level >= 3) { System.out.println("可以进入管理后台"); } else { System.out.println("权限不足"); } } else { System.out.println("请先登录"); }

嵌套if最考验的不是语法，而是缩进和可读性。我见过有人把三四层if写在一坨代码里，不缩进、不加花括号，最后自己都看不懂。这里有两个建议：

第一，每一层花括号都要对齐缩进，这是基本盘。第二，一旦嵌套超过三层，就该考虑用逻辑运算符合并条件，或者用“提前返回”的方式减少嵌套。

比如上面的例子，如果还想加一个“账号被禁用”的判断，嵌套会变成四层。与其继续往下套，不如改成：

if (!isLogin) { System.out.println("请先登录"); return; } if (isDisabled) { System.out.println("账号已禁用"); return; } if (level >= 3) { System.out.println("可以进入管理后台"); } else { System.out.println("权限不足"); }

这种方式在Android的Activity方法里特别常用，先一层层把异常情况拦截掉，剩下的就是正常流程，代码读起来轻松很多。我在第8讲写方法的时候会专门再展开，这里先记住这个思路。

3. switch语句：多值匹配场景下的效率与陷阱

3.1 switch适合什么、不适合什么

else if链条虽然能处理多种情况，但代码会随着分支数量膨胀，而且每个条件都要依次比较，可读性和效率都会下降。如果判断的是“某个变量等于一个固定值”，这时候switch就更合适。

switch的基本结构是这样的：

int day = 3; switch (day) { case 1: System.out.println("周一"); break; case 2: System.out.println("周二"); break; case 3: System.out.println("周三"); break; default: System.out.println("其他"); break; }

switch适合的场景有三个特征：第一，判断对象是“与某个确定值比较”，而不是“一个范围”；第二，分支数量比较多，一般超过三个；第三，判断值可以用整数、字符、枚举或字符串（JDK 7以后支持字符串）。

反过来，如果你要判断的是x > 0这种范围型条件，那就不要用switch，老老实实写if。原因很简单，switch的case只能写“精确值”，没法写区间。我在学习时试过用switch处理成绩分档，结果发现要么写出十几个case枚举分数，要么根本写不了，最后还得回到if。

3.2 break穿透：踩坑与利用

switch最大的一个坑是break。如果你在某个case后面漏写了break，程序会“穿透”到下一个case继续执行，直到遇到break或者switch结束。这就是所谓的“穿透”（fall-through）。

我举个例子，下面这段代码没有break：

int day = 2; switch (day) { case 1: System.out.println("周一"); case 2: System.out.println("周二"); default: System.out.println("其他"); }

运行结果会输出“周二”和“其他”，因为day等于2时，匹配到case 2，执行完打印后没有break，代码继续往下穿，把default也执行了。如果这里是Android里的按钮点击分支，结果会相当诡异——点击一个按钮触发了两段逻辑。

不过穿透也不全是坏事，有时候它是刻意为之的。比如想对多个值做相同的处理，可以直接叠case：

switch (day) { case 1: case 2: case 3: case 4: case 5: System.out.println("工作日"); break; case 6: case 7: System.out.println("周末"); break; }

这种写法比较简洁。但我还是建议，在case块的最后要么写break，要么写return，要么写注释说明这里故意不写break。否则三个月后你自己回来改代码，根本分不清是漏写还是故意。

3.3 Android开发中的switch注意事项

在Android开发里，switch最常用的场景之一是根据控件的id判断是哪个按钮被点击：

Button btnLogin = findViewById(R.id.btn_login); Button btnRegister = findViewById(R.id.btn_register); // 在OnClickListener里 switch (view.getId()) { case R.id.btn_login: // 登录逻辑 break; case R.id.btn_register: // 注册逻辑 break; }

这里有个关键注意点：case后面跟的必须是编译期常量。像上面这种R.id.btn_login在编译时就能确定数值，所以合法。但如果你写case view.getId():这种运行时才能得到值的写法，编译器会直接报错，因为case标签要求是常量表达式。

另外一个容易被忽略的地方是：Android的switch在使用字符串时，JDK 7以后才支持，如果你的项目配置里Java版本较低，编译会报错。不过现在主流的Android开发环境基本都支持了，配置正常的话不用担心，但我在自学早期确实被这个坑卡过一段时间，提醒一句总没有坏处。

4. 三元运算符：一行代码代替简单分支

4.1 语法与执行逻辑

除了if和switch，Java还提供了一种非常紧凑的分支写法——三元运算符（ternary operator）。它的语法是：

条件 ? 条件为true时的值 : 条件为false时的值

一个典型例子是判断一个数是正数还是负数：

int num = -5; String result = num >= 0 ? "非负数" : "负数";

这段代码等价于：

String result; if (num >= 0) { result = "非负数"; } else { result = "负数"; }

三元运算符最大的优点就是省代码，尤其适合“根据条件给同一个变量赋不同的值”这种场景。在Android里最常见的用法是拼接UI文案，比如：

String statusText = isOnline ? "在线" : "离线";

一行代码搞定，不需要写四到五行if-else，代码干净不少。

4.2 过度使用的反面教材

三元运算符虽好，但别滥用。我从网上看到过一些代码，把多个三元运算符嵌套在一起，看起来非常酷，但读起来就像解谜。比如这种：

String result = a > 0 ? (b > 0 ? "正正" : "正负") : (b > 0 ? "负正" : "负负");

这段代码逻辑本身没错，但可读性极差。在一行里面塞了三个判断条件，别人看代码时还得先在心里拆括号，浪费时间也容易出错。

我的建议是：三元运算符只用于“简单的二选一赋值”。如果是二选一但逻辑较长，或者条件超过两个，就老老实实写if-else。代码是给人看的，首先是可读，其次才是简洁。

另外注意，三元运算符是有“副作用”的执行逻辑：它只会执行被选中的那一边的表达式。比如：

int x = 5; int y = (x > 10) ? (x++) : (x--);

x大于10不成立，所以只执行x--，结果是x从5变成4。如果你在三元运算符两边放了有副作用的调用，一定要清楚只有一边会真正执行，不要指望“两边都跑一下”。我在学习时就因为没注意这一点，调试了很久才发现问题。

5. 自学过程里踩过的五个典型坑

这一节专门记录我在分支语句自学过程中实实在在遇到过的错误。每一个我都花了不少时间排查，写出来希望你能绕过。

5.1 =与==：赋值和比较根本不是一回事

这是所有Java初学者都躲不过的坑，我自然也不例外。写判断条件时，一不小心就把==写成了=。比如：

int a = 10; if (a = 5) { // 编译错误！ ... }

在Java里，a = 5是一个赋值语句，它的返回值是5，而5不是boolean类型，所以这段代码根本无法通过编译，编译器的报错信息一般是“incompatible types: int cannot be converted to boolean”。

但麻烦的是，在某些情况下这种错误不会直接报编译错误。比如变量本身就声明成boolean：

boolean isOk = false; if (isOk = true) { // 这里一定会执行 }

isOk = true这个赋值表达式的结果是true，所以if条件永远成立，程序行为完全错误，但编译器一声不吭。我实际遇到过一次：点击登录按钮后不管输入什么，程序都提示“登录成功”，排查了半天，最后发现就是if里多写了一个等号。

应对方法很简单：一是写完之后肉眼检查一遍所有if条件；二是条件里是boolean变量时，直接写变量名，不写== true，这样就算手滑也只可能是赋值错误，不太会出现这种情况。当然，最好的办法还是理解区分：单个等号是赋值，双等号是比较，这个在写第一行代码时就该刻进脑子里。

5.2 字符串比较必须用equals

另一个大坑是字符串比较。我刚学Java时想当然地以为字符串也能用==比较，结果程序行为非常诡异。比如：

String str1 = "hello"; String str2 = "hello"; if (str1 == str2) { // 有时候成立，有时候不成立，看情况 }

在Java中，==比较字符串比较的是引用地址，而不是内容。str1和str2指向的对象地址是否相同，取决于它们是不是同一个String对象。如果两个字符串都是字面量，可能指向常量池里的同一个对象，==恰好成立；但如果一个是运行时拼接出来的，地址就不同，==就不成立了。

所以字符串内容比较，正确写法是用equals()方法：

String input = "admin"; if (input.equals("admin")) { // 内容相等才成立 }

在Android里，判断输入的账号密码、获取的用户名时，都要用equals。我还遇到过更隐蔽的一个问题：当input可能是null时，直接input.equals("admin")会抛空指针异常。稳妥的写法是把常量写在前面："admin".equals(input)。这样即使input是null，也只是返回false，不会崩溃。这个习惯养成之后，帮我在后面的Android网络请求处理里少踩了很多空指针的坑。

5.3 短路求值：&&和||的真正威力

逻辑与&&和逻辑或||有一个非常实用的特性，叫短路求值（short-circuit evaluation）。意思是：如果左边已经能决定整个表达式的结果，右边的代码就不执行了。

我最初理解不到位，后来在写Android登录判断时吃了亏。当时写的是：

if (user != null && user.getName().length() > 0) { // 处理逻辑 }

这里user != null是第一个条件。如果user是null，&&左边已经是false了，整个表达式的结果必然是false，所以右边的user.getName()根本不会执行，也就不会因为空指针崩溃。这正是短路求值起作用的地方。

反过来，如果把条件写反了：

if (user.getName().length() > 0 && user != null) { // 报错：空指针 }

user是null时，先执行user.getName()就直接崩了，等不到后面的空判断。所以写&&时，要把“防御性条件”放在左边。这个经验后来成了我的习惯：任何涉及对象的方法调用，先判断对象是否为null，再调用方法。

||也有同样的特性：左边为true时右边不执行。利用这个特性可以做“默认值”逻辑：

String name = getName() != null ? getName() : "默认名";

不过这种情况三元运算符就已经够用了，短路求值的核心价值还是在于避免无效计算、防止空指针。

5.4 边界条件判断的顺序：先高风险后低风险

分支条件的顺序，除了影响逻辑正确性，还可能影响程序是否崩溃。举个我实际遇到过的例子，判断用户输入的年龄是否合法：

String ageText = "abc"; int age = Integer.parseInt(ageText); // 如果字符串不是数字，这里会抛异常 if (age < 0 || age > 150) { System.out.println("年龄不合法"); }

问题在于Integer.parseInt在字符串不是数字时会抛异常。我应该先判断字符串是否匹配数字格式，再执行转换。也就是说，分支判断的先后顺序，本质上是“风险优先级”的排序——先把可能导致异常的高风险条件拦截住，再做后续处理。

写多分支条件时，我建议遵循几个原则：第一，空值、非数字、越界等异常条件优先判断，用提前return或else处理掉；第二，高频出现的分支放在前面，减少判断次数，这在循环里尤其明显；第三，把“正常流程”放在最后，前面都是拦截异常情况。这套思路在Android里非常实用，因为界面上拿到的数据往往是用户输入的字符串，什么奇怪的值都可能出现。

5.5 多分支遗漏else兜底

最后一个坑，不是语法问题，而是思维问题。我在写多个if而非else if时，经常漏掉“所有条件都不满足”时的情况。比如：

boolean hasTicket = false; boolean isVip = true; if (hasTicket) { System.out.println("可以入场"); } if (isVip) { System.out.println("VIP通道进入"); }

如果一个人既没有票也不是VIP，这两段代码都不会执行，程序静默地什么都没做。有些场景里“什么都不做”是可以的，但更多时候需要显式处理这种情况。我的建议是：凡是写多分支判断，最后哪怕什么也不做，也写一个else或注释说明“此处不做处理”，防止后面看代码的人产生疑惑。

用else if串联的多分支，最后一定要有else兜底。switch则要有default分支。这个习惯看起来不起眼，但它能逼着你把所有可能性都想一遍，对初学者提升代码完整度帮助很大。

6. 分支语句在Android实际开发中的映射

学分支语句，最终是要用到Android开发里的。我在第7讲学完之后，回头去看之前写的那些简单例子，才意识到分支语句几乎是每个交互功能的地基。这里举两个典型的Android场景，让你直观感受一下分支语句的落点。

6.1 按钮点击事件中的分支逻辑

Android里最基础的一个场景：界面上有两个按钮，一个“登录”，一个“注册”。通过一个共同的点击监听，用switch根据id分发逻辑：

@Override public void onClick(View v) { switch (v.getId()) { case R.id.btn_login: handleLogin(); break; case R.id.btn_register: handleRegister(); break; default: break; } }

这里用到switch的两个点：一是case分支对应不同按钮id，二是default兜底。如果按钮多了，还可以用if-else处理更复杂的条件，比如“如果用户已登录，点击登录跳转首页；否则弹出登录框”。

你会发现，学Android时写的绝大多数代码，不外乎几件事：拿数据、判断数据、处理数据。而“判断数据”这一步，就是分支语句在起作用。所以现在打好基础，后面学事件处理、状态管理时就会顺畅很多。

6.2 界面状态的判断与空值保护

另一个典型场景是异步回调里的状态判断。比如模拟获取用户信息后，更新界面：

User user = getUserInfo(); if (user != null && user.isVip()) { textView.setText("VIP用户"); textView.setTextColor(Color.GOLD); } else { textView.setText("普通用户"); }

这是一个非常典型的“空值保护 + 分支状态”组合：先用user != null拦截空对象，再通过isVip()决定界面展示。核心思路就是我在第5节里强调的——防御性条件放左边，正常业务分支放后面。

从这一讲开始，我的自学方式也有了变化：不再只是抄代码、跑代码，而是每学一个语法点，就主动问“这个语法在Android的哪个场景会出现”。这个习惯帮助我把Java语法和Android开发真正串了起来。接下来第7讲的下一部分会继续讲循环语句，等循环学完，程序就能处理重复性的任务了，到时候能做的事情就又上一个台阶。

最后分享一个小体会：分支语句看起来只是几个关键字，但它真正考验的是“把所有情况都想全”的能力。我能给出的最大建议就是——多写、多改，写完之后故意把条件顺序打乱、删掉break、把==改成=、把字符串改成和null比较，看看程序怎么崩溃、怎么报错。这些“刻意的错误”反而能让你最快地理解分支语句的行为边界。