Scratch条件执行语句：从选择器本质到状态机实战

学 Scratch 的孩子里，十个有八个卡在同一类问题上：角色能跑能跳能叫，可一旦要它“看情况办事”——碰到东西才反应、分数够了才升级、按键才开门——积木就乱了套。有人把“如果……那么”拖进“重复执行”里，分数一秒涨三十次；有人把判定写在循环外面，动作只发生一次就再也没动静；还有人写了个“等待直到 碰到苹果”，结果苹果都被别的脚本删了，程序还在那儿干等。这些现象背后其实只有一个知识点没吃透：Scratch 控制模块里的条件执行语句，本质上是一个“选择器”而不是“动作指令”。它负责在每一帧里替角色做判断，判断的结果只有一个——走这条路，还是走那条路。

这篇内容面向三类人：刚接触图形化编程的孩子家长，想知道孩子到底在学什么；刚接手少儿编程课的带班老师，需要一份能直接搬到课堂上的讲法和案例；以及已经会用 Scratch 做小游戏、但总觉得自己写的逻辑“能跑但不可靠”的自学者。下面会从条件语句在积木体系里的真实位置讲起，拆开比较运算和逻辑运算的组合规则，重点过一遍条件与循环叠加时最容易翻车的几种情况，最后给一个带钥匙的密码门小项目，完整到可以照着搭。

1. 条件执行语句在Scratch里的真实位置：它管的不是动作而是选择

1.1 从顺序执行说起：为什么孩子写的角色总是“一根筋”

Scratch 的脚本默认是顺序执行的：从上往下，一块接一块。这种结构写“走路—转弯—停下”很顺手，但它有一个根本限制——每一块积木都会被执行，没有商量的余地。孩子想让角色“只有碰到门才开门”，用顺序结构是写不出来的，因为积木不会自己判断该不该执行。条件执行语句补的就是这一块：它把后面的积木包裹起来，变成“有条件的执行”。

我习惯在课上用一个比喻把这层关系说清楚：顺序执行的积木像一条传送带，所有零件依次经过；条件语句像是在传送带上加了一个分拣员，零件能不能往下走，得先过他那一关。孩子理解了这个比喻，就不会再问“为什么我把它放在最后它不执行”这种问题——因为在传送带上，分拣员后面的东西本来就得先过他那关。

需要提前说清楚的一点是：Scratch 里没有“返回值”这个概念，条件积木不能像 Python 那样if之后拿到一个变量。它的全部作用就是决定接下来走哪一条分支，仅此而已。很多孩子把它当成“用来计算的东西”，方向一开始就偏了。

1.2 三块条件积木各自负责什么场景

控制模块里跟条件相关的积木并不只有一块，实际常用的有四块，分工很明确：

“如果……那么”和“如果……那么……否则”这两块，绝大多数孩子十分钟就能拖对位置，真正的难点在后面会讲的“判断时机”。而“等待”和“重复执行直到”经常被混为一谈，这是我在课堂上见过频率最高的概念混淆，后面第 3 节专门拆。

1.3 六边形插槽：条件其实是一个“值”而不是一句话

Scratch 的积木插槽形状是有讲究的：圆角矩形装数字和文字，六边形装布尔值。条件语句后面那个六边形插槽，要求的不是“一句话”，而是一个能算出真或假的表达式。理解这一点非常关键，因为它解释了为什么“碰到 苹果”可以单独塞进六边形，而“移动 10 步”塞不进去。

由此可以推出一个很实用的调试手法：在 Scratch 3 里，布尔积木可以被拖进“说”积木的输出口，运行起来会直接显示true或者false。这相当于给孩子一个免费的探针，不用猜，屏幕上直接告诉你判断结果。我在带班时要求每个孩子遇到“条件好像不生效”的问题，第一步不是改积木，而是把条件拖进“说”里看一眼。十次里有六次，问题当场就暴露了——条件压根就没成立过。

提示：布尔积木拖进“说”之后记得运行完删掉，否则角色会一直顶着false挡在舞台上，后面查画面问题时容易被误导。

2. 把条件写对的底层功课：比较、逻辑与侦测的三方配合

2.1 比较运算符的返回结果和边界

六边形插槽里的内容通常来自三个地方：运算符模块的比较积木（>、<、=）、运算符模块的逻辑积木（与、或、不成立）、侦测模块的各种问句。比较积木看着简单，坑却不少。

第一，Scratch 的“=”是宽松相等。数字10和字符串"10"会被判为相等，字符串比较还不区分大小写，"ABC" = "abc"的结果是 true。做密码门这类项目时，如果密码是纯字母，孩子输入小写也能通过，这在课堂上会引发“老师我的密码失效了”的疑问。解决办法是在比较之前统一处理，或者干脆用数字密码。

第二，浮点数判等基本等于自找麻烦。角色的坐标在经过“碰到边缘就反弹”“移到 x: y:”之后，往往不是整数。你写如果 〈x 坐标〉 = 〈0〉，实际值可能是-0.5或者0.0001，判断永远不成立。正确的写法是给一个容差：

如果 〈绝对值(x 坐标) < 5〉 那么 把 x 坐标 设为 0

这个写法在课堂项目里覆盖率极高，凡是涉及“回到某个位置”“对齐格子”的需求，我都会直接让孩子用容差，而不是赌坐标精确。

第三，比较的一方是变量时要注意类型。变量里存的可能是空字符串，和数字比较时按 0 处理，孩子如果忘了初始化，表现就是“分数莫名其妙是 0”，其实只是没赋初值。

2.2 与/或/不的组合顺序：优先级和括号习惯

三个以上条件叠在一起时，逻辑组合开始变得不可控。“与”和“或”在 Scratch 里是有优先级差异的（“与”先于“或”结合），但绝大多数孩子不会去记这个，结果就是写出来的判断和脑子里想的不一样。

我的做法是强行规定一条书写纪律：只要组合了两个以上条件，一律用嵌套套出视觉括号。具体写法是把“或”作为一个整体先算出来，再和另一个条件“与”，积木的嵌套形状天然就是括号，孩子看得见：

如果 〈〈碰到 钥匙 ?〉 或 〈钥匙数 > 0〉〉 与 〈门的状态 = "关"〉 那么 开门

这个写法虽然积木块数多了一点，但形状一眼就能看出分组，比靠记忆优先级靠谱得多。顺带说一个经验：Scratch 的“与”“或”不保证短路求值，所以不要指望“先判断列表非空再取第一项”这种写法能保护程序。好在 Scratch 的列表越界读取不会报错，返回的是空字符串，所以实际危害不大，但这个习惯要从一开始就纠正，别把别的语言里的思维带进来。

“不成立”这块积木也值得单独说一句。它的作用是给布尔值取反，但孩子很容易写成双重否定：不成立 〈不成立 〈碰到 墙 ?〉〉，绕了一圈等于“碰到墙”。规则很简单——取反只用一次，超过一次就换个说法。比如“没碰到墙”就直接写不成立 〈碰到 墙 ?〉，别再多套一层。

2.3 侦测类条件里最容易失效的两个：颜色判定和坐标判定

侦测模块提供了大量现成的布尔积木，其中两个最容易出问题。

碰到颜色：靠的是像素颜色匹配。角色边缘有抗锯齿，颜色是渐变的过渡色，吸管取到的那个颜色可能只覆盖了几个像素点，稍微移动一点判断就失效了。更麻烦的是背景图压缩之后再缩放，颜色值会发生偏移。我在课堂上遇到这类问题，第一反应是让孩子把判定对象换成一个专门的“判定角色”——用“碰到角色”代替“碰到颜色”。角色碰撞判定按的是轮廓框，稳定性高出一个量级。如果非要用颜色，就把判定色块做成纯色、无渐变、面积大一点。

坐标判定：除了前面说的浮点精度，还有一个隐蔽问题——穿透。Scratch 的舞台刷新大约是每秒 30 帧，角色每次移动的位移如果大于自己的尺寸，判断就会“跳过去”。给一个具体数字：角色直径 20 像素，如果脚本里写“移动 40 步”外加“重复执行”，它一帧走 40 像素，中间没有任何一帧处于“碰到墙”的状态，条件永远不会成立，角色直接穿墙而过。修法是把大步长拆成小步长，每小步判一次：

重复执行 (4) 次 移动 (10) 步 如果 〈碰到 墙 ?〉 那么 移动 (-10) 步 停止 [这个脚本]

这段“分步移动 + 逐步判定”的写法，是做打砖块、跑酷、子弹类项目的基础功，比任何花哨的效果都重要。

3. 条件与循环叠在一起时的四类翻车现场

3.1 判定写在循环外和循环内，结果差一个数量级

这是我见过最多的错误，没有之一。孩子想让角色“一直检查有没有吃到苹果”，写成：

如果 〈碰到 苹果 ?〉 那么 重复执行 把 分数 增加 1

运行结果：分数疯涨，一秒钟几十次。原因很直白——条件只在进入循环前判断了一次，一旦成立，循环里每一帧都在加分，条件再也不看了。正确写法是把条件放进循环里：

重复执行 如果 〈碰到 苹果 ?〉 那么 把 分数 增加 1 删除此克隆体

反过来也有对应的错误：判定放在循环里，但孩子想让它“只触发一次”。比如开门之后一直在播开门音效，因为每一帧条件都成立，每一帧都重新触发。修法有两个：一是动作完成后修改状态变量让条件不再成立，二是动作结束后直接停止这个脚本。

我通常会让孩子们自己在课上做一次实验：同一个判定，放外面跑一次，放里面跑三秒，看分数差多少。亲眼看到数字跳变，比讲十遍原理管用。

3.2 等待直到和重复执行直到：差在“可能一次都不做”

这两块积木长得像、语义完全不同，我用一张表把它们钉死：

“条件一开始就成立时”这一行是关键差异。举个实际例子：让角色“一直走直到碰到墙”。如果用“等待 碰到墙”，角色根本不会移动，因为一开局没碰到墙，条件不成立，脚本就停在那儿等；等它碰到墙了，脚本才继续往下走，但此时它已经贴墙了，再走就穿过去了。而“重复执行直到 碰到墙”是边走边判，边判边走，语义正好对上。

另一个常见误解是“等待会卡住整个程序”。不会。Scratch 里每个“当绿旗被点击”“当接收到消息”都各自是一条独立的脚本线，一条在等，其他照跑。我会让孩子做个验证：一个角色“等待 3 秒”然后变色，另一个角色同时一直旋转，运行起来旋转不停、变色延后——这就证明了等待只阻塞自己。

3.3 条件太灵敏：为什么角色在边界上抖成筛子

用“如果 碰到边缘 那么 移动 -10 步”这种写法做碰撞，角色经常在边界上高频抖动，看起来像在抽搐。原因是判断和修正发生在同一帧的两端：碰到 → 后退 → 下一帧因为惯性又碰到 → 又后退，来回拉扯。

根本原因是判定条件没有 hysteresis（迟滞）。工程上的解法是引入一个“已经触发”的标记变量，触发后先锁住，等角色离开危险区域再解锁：

如果 〈碰到 墙 ? 与 〈撞击锁 = 0〉〉 那么 把 撞击锁 设为 1 把 生命 增加 -1 移动 (-20) 步 如果 〈不成立 〈碰到 墙 ?〉〉 那么 把 撞击锁 设为 0

这段代码多了四行，但把高频抖动和重复扣血两个问题一起解决了。这个“锁”的思路，是我在教条件语句时最想让孩子带走的东西之一，后面第 4 节的状态变量法本质上是同一个思想的升级版。

3.4 多个脚本同时改同一个变量：条件判断的竞态

当一个角色有两条脚本同时跑，一条在“重复执行”里改分数，另一条在判断“分数 > 10 就升级”，就会出现时序问题：判断脚本可能恰好在一连串加分动作的中间读取到分数，导致升级触发时机不可预期。更糟的情况是判等加计数，两条脚本各加一次，孩子以为只加了一次。

处理办法只有两条：变量只让一条脚本负责写，其他脚本只读；需要通知别的脚本时用广播消息，而不是靠共享变量互相“看见”。Scratch 的广播是排队执行的，比变量轮询可靠得多。带班时我会强调一句：变量是数据，不是信号，别拿它当消息总线用。

4. 从扁平判断到状态机：条件语句的结构化写法

4.1 嵌套条件的“深坑”与提前退出技巧

成绩等级判定是讲嵌套条件的经典案例：90 分以上 A，80 到 89 是 B，以此类推。孩子第一版往往写成金字塔：

如果 〈分数 > 89〉 那么 说 [A] 否则 如果 〈分数 > 79〉 那么 说 [B] 否则 如果 〈分数 > 69〉 那么 说 [C] ...

五六层之后，积木已经伸出屏幕外，改一个边界要滚半天。三种优化思路，按难度递增。

第一条路：把大区间改成小区间。用“在 a 到 b 之间”的判断，每个分支只负责一个区间，彼此平行不嵌套：

如果 〈〈分数 > 89〉 与 〈分数 < 101〉〉 那么 说 [A] 如果 〈〈分数 > 79〉 与 〈分数 < 90〉〉 那么 说 [B]

积木变多了，但完全扁平，改边界只动一处数字。

第二条路：提前退出。Scratch 的“停止［这个脚本］”可以模拟其他语言里的 early return。把最容易判的分支放最前面，命中就结束脚本：

如果 〈分数 > 89〉 那么 说 [A] 停止 [这个脚本] 如果 〈分数 > 79〉 那么 说 [B] 停止 [这个脚本]

这样写出来的脚本从上到下读，就像一串“如果……就到此为止”，没有一层嵌套。

第三条路：查表法。把边界和等级做进列表，用循环遍历比对。这条路适合边界很多的情况，但对初学者来说抽象度高，我一般留到进阶课再讲。

4.2 用状态变量替代八层嵌套

嵌套的根源往往是“一个角色同时承担了好几种行为”。角色在“待机”“行走”“受伤”“死亡”四种状态下的反应完全不同，如果全塞进一个“如果……否则”，嵌套必然爆炸。正确的做法是引入一个状态变量，把行为分发出去：

当绿旗被点击 把 状态 设为 [待机] 重复执行 如果 〈状态 = "待机"〉 那么 待机处理 如果 〈状态 = "行走"〉 那么 行走处理 如果 〈状态 = "受伤"〉 那么 受伤处理

这里每一条判断都是平行的，互相不嵌套。状态变量只负责“当前处于哪一种情况”，具体做什么交给各自的处理块。这个结构的好处是扩展性好——新增一个“跳跃”状态，只需要加一条平行的判断，不用动原来的任何一块积木。

对于还没学自定义积木的孩子，可以把“处理块”直接写成一段积木嵌在“如果”下面，效果一样，只是脚本会长一些。等学完自定义积木，再把这些段落抽成积木，整个项目会清爽一大截。

4.3 判定表思路：把规则先写纸上再搭积木

我在课堂上有个硬性要求：动手拖积木之前，先在一张纸上把“什么情况 → 做什么”列成表格。这一步能省掉后面一半的返工。

以“带钥匙的密码门”为例，纸上先写好：

表格列完，代码几乎是照着抄的。更重要的是，孩子在列表格的过程中会自己发现漏洞——比如“门开着的时候还需不需要检查钥匙”，这个问题在积木里很难看出来，在表格里一眼就能发现。

5. 一个可直接复现的课堂项目：带钥匙的密码门

5.1 需求与角色拆分

项目目标：角色能用方向键移动，地图上散布三把钥匙，捡到钥匙后走到门口按键开门，没钥匙则提示，门开之后角色能穿过去。整个项目用到条件语句的三种形态，覆盖了前面讲的大部分知识点。

角色和变量清单：

• 角色：玩家（可用一个方块代表）、钥匙（本体加克隆）、门、提示文字
• 变量：钥匙数（全局）、门状态（全局，取值“开”或“关”）、开门锁（局部，防止一次按键触发多次）
• 舞台：一张有墙和地面的简单背景

拆分角色时有一个细节要注意：钥匙用克隆体来做，三把钥匙由一个角色克隆出三个，位置分别设定。这样捡钥匙的判定逻辑只写一份，不用三次重复。这是克隆体的价值所在，也是初学者容易忽略的优化点。

5.2 关键积木顺序与变量设计

玩家的移动与捡钥匙，可以合在一条脚本里：

当绿旗被点击 把 钥匙数 设为 0 把 门状态 设为 [关] 移到 x: (-180) y: (-100) 重复执行 如果 〈按下 [右箭头] 键?〉 那么 把 x 坐标 增加 5 如果 〈按下 [左箭头] 键?〉 那么 把 x 坐标 增加 -5 如果 〈按下 [上箭头] 键?〉 那么 把 y 坐标 增加 5 如果 〈按下 [下箭头] 键?〉 那么 把 y 坐标 增加 -5 如果 〈碰到 [钥匙] ?〉 那么 把 钥匙数 增加 1 广播 [收集钥匙] 等待 (0.2) 秒

这里有两个值得停下来讲的点。第一，“等待 0.2 秒”是为了防重复拾取——碰到钥匙的瞬间，下一帧可能还碰着，不加等待会连着加两三次。第二，拾取逻辑用广播通知钥匙角色删除自己，而不是在这里直接“删除此克隆体”——因为当前脚本属于玩家角色，删的是玩家自己。这个“谁执行就删谁”的规则，我见过不少孩子踩。

门的判定脚本：

当绿旗被点击 把 门状态 设为 [关] 换成 [关门造型] 重复执行 如果 〈按下 [空格] 键? 与 〈碰到 [玩家] ?〉 与 〈开门锁 = 0〉〉 那么 把 开门锁 设为 1 如果 〈钥匙数 > 0〉 那么 把 门状态 设为 [开] 把 钥匙数 增加 -1 换成 [开门造型] 说 [门开了] (1) 秒 否则 说 [先去捡钥匙] (1) 秒 等待 (0.3) 秒 把 开门锁 设为 0

这段脚本里，外层判断用了“与”把三个条件捆在一起，内层用“如果……否则”分流。开门锁的作用前面说过——防止按一次空格，因为脚本每帧都在跑，开门动作被触发好几遍。

钥匙角色的克隆体脚本：

当绿旗被点击 隐藏 移到 x: (-100) y: (80) 创建克隆体 移到 x: (60) y: (-40) 创建克隆体 移到 x: (150) y: (100) 创建克隆体 当作为克隆体启动时 显示 重复执行 如果 〈碰到 [玩家] ?〉 那么 删除此克隆体 停止 [这个脚本]

克隆体的判定放在“当作为克隆体启动时”下面，每个克隆体各管各的。这一块是初学者最容易漏掉的——把判定写在“当绿旗被点击”里，所有克隆体共享一条脚本，行为完全错乱。

5.3 实测中的调参与常见故障

这套积木搭完之后，课堂上出现的故障基本集中在以下几处，做一个对照表方便排查：

第二行和第三行是新手最容易栽的。关于“门开了怎么让玩家通过”，最稳的做法不是靠造型变化，而是把门的碰撞逻辑挂到门状态变量上：判定脚本第一句先看门状态 = "关"，只有关着才拦人。这样开门就是改一个变量，干净利落，不会出现“看着开了实际没开”的尴尬。

移动速度也要调。5 像素一帧在 30 帧下是 150 像素每秒，舞台宽 480 像素，走完全程三秒多，节奏刚好。有些孩子直接写“移动 20 步”，看着快，但配上分步判定就会频繁卡墙。这个数值建议在课上让孩子自己试出来，比直接给答案印象深。

6. 课堂答疑高频问题与调试手法

6.1 条件永远不成立的五条排查路径

孩子举着电脑说“老师它不判断”，我一般按固定顺序走一遍，八成问题不超出这五种：

第一条，条件本身写错了。把布尔积木拖进“说”看一眼，true还是false，一目了然。这一条能解决一半问题。

第二条，执行顺序错了。判定写在动作之前，而动作还没发生。比如“如果 碰到 苹果 那么 加分”放在“移到苹果位置”之前，永远不成立。

第三条，变量没初始化或者被别处改了。尤其是全局变量，几个角色共用，一个脚本清零、另一个脚本还在用。

第四条，角色层级和碰撞判定。两个角色都是隐藏状态，或者一个是虚像 100，碰撞判定依然有效，但如果对方是克隆体且已被删除，判定就永远不成立。

第五条，坐标系方向搞反。舞台 y 轴向上为正，孩子把“向下”写成正数，角色跑到舞台外，判定自然不成立。这一条在低龄班里出现频率意外地高。

6.2 用“说”积木做临时探针

前面提过一次，这里再强调一下具体用法。布尔积木可以直接接到“说”积木的输入口，Scratch 3 会把它显示成true或false。数值类的排查则用“说 〈变量名〉”，把关键变量实时显示在角色头顶。

我通常让孩子在每个关键判定旁边加一个探针，定位完问题再统一删掉。这个习惯的价值不在 Scratch 本身——等以后写真正的代码时，打印日志排错的思路是一脉相承的。很多孩子学了两年图形化，遇到问题还是靠“删了重写”，就是因为没建立“先观察再修改”的习惯。

探针还有一个进阶用法：把“计时器”接到“说”里，看两段积木之间隔了多少秒。判断循环里到底跑得快不快、有没有被阻塞，用这个方法特别直观。

6.3 克隆体与条件的隔离

克隆体让项目变优雅，也让条件判断复杂化。三个要点记牢：克隆体的“当作为克隆体启动时”脚本，每个克隆体一份，互不干扰；克隆体读取全局变量是共享的，读取“仅适用于当前角色”的变量则是各自独立的；删除克隆体的积木只能由克隆体自己执行，别的角色删不了它。

这三个点组合起来，就能解释课堂上一大半“我的克隆体行为奇怪”的疑问。比如一批子弹克隆体，有的碰到墙就消失、有的不停，八成是因为碰撞判定写在了“当绿旗被点击”里，只有本体在判，克隆体根本没执行到那段。

克隆体数量也要盯着。Scratch 默认上限是 300 个，超了就删不掉新克隆体，而克隆体在不断创建又不删除的情况下，性能会肉眼可见地掉帧。条件语句里加一句“碰到边界就删除此克隆体”，问题基本就堵住了。

最后说个我自己的体会：条件执行语句真正的门槛从来不在积木本身，那四块积木孩子三分钟就能拖对。难的是把“什么时候判断一次、什么时候每帧判断、判断之后要不要改状态”这三件事想清楚。我现在的做法是，每节课留最后十分钟让孩子自己讲一遍“这条判断为什么要放在这里”，讲得出来才算真会，讲不出来就说明他只是在模仿。这个动作比做十个项目都管用。