1. 条件执行语句到底在解决什么问题在 Scratch 控制模块里条件执行语句是绝大多数作品从能动跨到会思考的分水岭。我见过太多初学者角色能走能跳、能跟着鼠标跑但一碰到碰到敌人扣血分数到 100 才开门按住上键才能跳这类需求就卡住——不是不会拖积木而是脑子里那套从上往下一条线走到底的执行模型和条件语句要求的走到岔路口先看一眼再决定往哪走完全对不上。这篇文章就把 Scratch 条件执行语句这套东西讲透它是什么、三种形态怎么选、布尔条件怎么写、嵌套和否则如果怎么搭、性能上有什么讲究、出问题怎么查。适合刚接触控制模块的新手也适合已经能做完整小游戏、但条件逻辑写得又长又乱、改一处崩一片的中级玩家。Scratch 里的条件执行语句本质上就是三块积木的组合如果 条件 那么、如果 条件 那么 … 否则以及配套的等待 条件和重复执行直到 条件。它们的共同点是——积木里那个六边形的凹槽只能塞进一个是/否的问题。这个是/否就是布尔值它不返回数字、不返回文字只返回真或者假。理解了这一点条件语句的 90% 困惑就自动消解了不是你在写如果分数大于 100 就开门而是你在问分数大于 100 吗然后系统回答真或假真就走里面的积木假就跳过去。为什么条件执行语句值得单独拿出来讲因为它是 Scratch 里唯一能把状态转成行为的通道。变量、侦测、计时器这些都是原料条件语句是那个开关。没有它角色只能按脚本写好的顺序机械播放有了它角色才能在每一帧重新判断我现在该干什么。这背后其实是游戏开发里最朴素也最重要的东西——状态机。一个能上台面的 Scratch 作品骨子里都是一堆条件在打架谁的判断写在前面、谁的判断嵌套了几层、谁的判断每帧都在重复执行直接决定作品是丝滑还是卡顿、是稳定还是诡异。我在帮人看作品时有个习惯先不看美术直接打开角色脚本数一数它有几个重复执行套着如果。如果屏幕上半部分是几十个平铺的如果下半部分是乱成一团的嵌套那这个作品后期基本改不动了。条件语句写得好不好看的不是能不能跑起来而是三个月后你还敢不敢动它。1.1 条件执行语句和顺序执行的本质差别顺序执行就像照着菜谱做菜切菜、下锅、翻炒、装盘一步一步来中间不会因为你今天心情不好就跳到装盘。Scratch 里没有条件语句的脚本就是这样绿灯一点从头跑到尾跑完就停。问题是现实需求几乎全是带分支的——按下空格才跳没按下就站着碰到地面才允许跳空中再按不算血量归零才结束没归零就继续。条件执行语句做的事是在这条流水线上插了一个岔路口。程序走到岔路口先算一遍条件算出真就从那么里穿过去算出假就整个跳过那么里的内容继续往下。注意跳过这两个字很关键条件为假时里面的积木是完全不执行的不是执行了但没效果是压根没进去。这一点解释了新手最常见的疑惑——我在如果里面改了变量为什么没变因为条件压根没成立那行改变量的代码就没跑过。我做过一个对比演示给学员看同样一个角色用顺序执行写前进 10 步、碰到边缘就反弹再换成条件执行写如果碰到边缘 那么 反弹。前者在角色走到边缘时会先撞出去再被拉回来动作是卡顿的后者在撞到边缘的同一帧就完成判断并转向看起来顺滑得多。差别不在积木数量在于判断发生的时机和位置。1.2 三类条件积木的形态差异与选用原则很多人把这几块积木混着用其实它们的分工非常明确选错了就会出现只执行一次或每一帧都重复触发的毛病。我把它们摆在一起对比一下积木形态执行方式典型场景用错的后果如果 条件 那么单次判断逐帧由外层循环驱动碰撞检测、按键检测、状态刷新放在没有循环的脚本里只会判一次如果 条件 那么 … 否则单次判断二选一开关切换、成功/失败分流两个分支都写相同内容等于白写等待 条件阻塞式条件不成立就一直卡在这行等待点击开始、等待扣血动画播完用了它后面所有脚本全部暂停重复执行直到 条件循环式条件不成立就反复跑里面蓄力条、冷却倒计时、按住加速条件写成永假会死循环作品卡死选用的核心判断只有一句话这件事你要判一次还是要一直判判一次用如果一直判用如果套在重复执行里或者干脆用重复执行直到。而等待是这三种里最容易用出事故的——它是阻塞的一个角色卡在等待 碰到 敌人它的其他脚本还能跑但这个脚本里等待之后的所有内容全部静止。我见过有人把整个游戏主循环都塞在等待 鼠标按下后面结果游戏画面彻底冻住还以为是自己电脑卡。1.3 条件背后的布尔表达式六边形凹槽里能放什么说清楚条件语句必须顺带说清楚那个六边形凹槽里到底能塞什么。Scratch 把它限定得很死只能放返回真/假的积木大致分四类比较类 、 可以比数字也可以比文字按字典序左边右边都能嵌变量和运算积木。逻辑类 与 、 或 、 不成立 用来把多个条件拼起来。侦测类碰到 角色 ?、碰到颜色 颜色 ?、颜色 颜色 碰到 颜色 ?、按下 键 键?、按下鼠标?、响度 数值、计时器 数值、距离 角色 数值等等。状态类任何放在 里的变量配合比较积木使用。这四类有一个共同特征它们问的都是现在这一刻的事实不记录历史。所以分数 100这条判断在分数从 100 变成 101 的那一帧成立、之后一直成立不会自己触发一次就失效。这就是为什么过关这种一次性事件必须自己加锁——用一个已过关变量做闸门过了就置为真条件写成分数 100 与 已过关 假才能保证只触发一次。这个技巧后面还会细说先记住结论条件语句本身没有记忆记忆得靠变量补。2. 条件积木的核心细节与易错点拆解真正把条件语句写崩的往往不是大逻辑而是一些小细节比较运算的类型转换、字符串和数字的混用、逻辑运算的分组顺序、那个不起眼的否则该不该写。这些问题在积木层面上看不太出来跑起来才发现它怎么黑屏了它怎么一直是对的。这一章把这些细节拆开讲都是我在实际带人和改作品时反复碰到的。2.1 比较运算的隐形类型转换Scratch 的比较积木相当宽容10 9这种写法它就当数字比得 10 9 为真但如果你不小心把它写成了abc 9它就会退化成字符串比较按字典序逐位比结果会让你莫名其妙。更隐蔽的是空字符串和 0 的关系变量没赋值时是空字符串变量 0在很多情况下居然是真的因为空串被转成了 0。我曾经帮人查一个开局血量直接归零的 bug查了半小时最后发现是血量变量在初始化之前就被拿去比较了而那一帧刚好又触发了扣血条件。我的习惯是任何参与数值比较的变量在作品开始的第一帧必须显式初始化。用绿旗事件下面第一件事就是将 变量 设为 0一个都不能漏。这看起来是废话但十次数值错乱里有六次是这个原因。另外需要比较小数的时候要特别小心浮点误差0.1 0.2不等于0.3这种事在 Scratch 里一样存在。所以涉及金币数量、生命值这类整数尽量保证运算全程是整数涉及坐标比较别用x坐标 100用x坐标 99.5 与 x坐标 100.5这种区间判断稳得多。2.2 逻辑运算的组合与分组陷阱与、或、不成立这三块积木是可以互相嵌套的Scratch 没有提供括号只能靠物理嵌套来表达优先级。麻烦在于与和或混在一起时人的直觉理解往往和实际执行不一致。比如A 或 B 与 C很多人的本意是A 或 B并且 C但如果你是把B 与 C塞进了或的右边实际执行就是A 或B 且 C一个括号的差别逻辑完全变了。规避方法很土但很有效混用与/或的时候先把最内层的条件拼好再一层层往外套套完读一遍成句的中文。如果读出来和你想表达的不一样就重搭。另外不成立这块积木不要滥用不成立 碰到 敌人实际上是可读的但不成立 A B 或 C D 这种三层往里塞的我自己写完第二天都看不懂。遇到复杂条件正确做法是拆成多个如果或者用变量先把中间结果存下来给变量起个像样名字比死磕嵌套强得多。2.3 那个经常被忽略的否则新手写条件几乎只用单分支的如果 那么遇到相反的情况就再写一个如果 那么把条件取反。这么写能用但有两个隐患一是条件一旦写错两个分支可能同时不成立角色进入一个谁都没处理的黑洞状态卡在那里不动二是两个条件如果都成立比如你忘了取反两块积木会连着跑出现抖动。双分支的如果 那么 否则天然保证了二选一永远有一条路被走到。我在写角色状态切换时几乎全部用双分支如果 速度 0 那么 面向 0 度 否则 面向 180 度。这种结构无论速度是多少角色都一定有一个朝向不会出现贴图消失这种诡异现象。所以我给自己的规矩是只要存在明确的两种可能一律用否则不留空白分支。代价是多拖一块积木收益是排除了一个整类的状态遗漏 bug。2.4 否则如果链的手工搭建方式Scratch 原生没有否则如果多分支只能自己搭。最标准的做法是把下一层如果塞到上一个否则里面形成一个阶梯状的嵌套。以分数评级为例如果 分数 90 那么 将 等级 设为 A 否则 如果 分数 75 那么 将 等级 设为 B 否则 如果 分数 60 那么 将 等级 设为 C 否则 将 等级 设为 D这个结构之所以成立靠的是从高到低依次判断命中即停。因为一旦第一层为真就不会进否则分支后面的判断全部跳过。所以顺序绝对不能乱——如果先判 60那 95 分也会落到 C因为第一层就命中了。这个坑我见过太多次尤其是中途改阈值的时候只改数字不改顺序测试用的分数又刚好避开边界上线就出事。阶梯嵌套的视觉问题是很深四层下去积木就缩成一条线了。我的处理办法是控制在三层以内超过三层就改用变量或自制积木拆开或者干脆把判断写在不同的角色、不同的脚本里。可维护性这件事在 Scratch 里同样是真金白银。3. 从零搭建一套可复用的条件控制实战案例光讲原理容易飘我拿一个最简单的横版小场景来把条件语句跑一遍一个角色左右移动、跳跃落地、撞刺扣血、吃钥匙开门、血量归零结束。这个场景不复杂但几乎覆盖了条件语句所有常见用法把它的骨架吃透其余需求都是在这个骨架上改条件。先说清单。角色两个主角、可碰撞的障碍物用颜色或角色都行这里用角色。变量四个x速度、y速度、血量、钥匙数。再加三个控制用的开关变量已受伤、已过关、在地面。这套变量清单看着多但只要每个变量只承担一件事逻辑就会非常清楚——我强烈建议新手养成一个变量一件事的习惯别搞成状态一个变量装十种含义后面每加一个功能都要改它改着改着就崩了。3.1 主循环骨架把判断分批装进重复执行主角的脚本我通常分成三段每段一个绿旗事件各自独立跑第一段是输入采样只负责读键盘把结果写进变量当 绿旗 被点击 将 x速度 设为 0 将 y速度 设为 0 将 血量 设为 3 将 钥匙数 设为 0 将 已受伤 设为 假 将 已过关 设为 假 重复执行 将 x速度 设为 0 如果 按下 右箭头 键? 那么 将 x速度 设为 5 如果 按下 左箭头 键? 那么 将 x速度 设为 -5这里用两个独立的如果而不是如果 否则是有意的左右同时按下时后一个覆盖前一个角色表现为往左走不会抽搐。如果写成如果 否则同样是后一个覆盖前一个效果一致但二次判断结构更清晰方便以后加同时按下加速这类逻辑。第二段是物理更新负责位置、重力、边界重复执行 将 x坐标 增加 (x速度) 如果 x坐标 220 或 x坐标 -220 那么 将 x坐标 设为 ((x坐标) 和 -220 与 220 之间的夹取)这里 Scratch 没有内置夹取我一般直接用两个条件分别处理如果 x坐标 220 那么 将 x坐标 设为 220 如果 x坐标 -220 那么 将 x坐标 设为 -220这两条之所以分开写是因为边界是两个独立的事实合成一个条件再加分支要写嵌套反而不如两条平铺读起来快。第三段是状态判定扣血、开门、结束都是条件语句的重灾区下面分开讲。3.2 边界反弹与落地判定条件里的前一帧思维落地判定是经典难点。直觉写法是如果 y坐标 地面高度 那么 在地面设为真。但这个写法有个毛病角色从下往上穿的时候也会被判成在地面。正确做法是结合 y 速度判断——只有在下落y 速度小于 0并且脚底已经低于地面高度时才算落地如果 y速度 0 与 y坐标 -80 那么 将 y坐标 设为 -80 将 y速度 设为 0 将 在地面 设为 真 否则 如果 y坐标 -80 那么 将 在地面 设为 假这段代码里在地面变量的真假切换是靠两个分支完成的逻辑上等价于在地面上就是真否则就是假。为什么不用直接赋值将 在地面 设为 y坐标 -80因为 Scratch 里布尔值可以当变量值用但很多初学者不知道而且直接塞进去的可读性差。用显式的条件赋值虽然多两块积木但一眼能看懂。跳跃的条件就需要用到在地面了而且必须加一个y速度 0或者在地面 真的闸门否则空中可以无限跳俗称空中二段跳很多小游戏就是被这个毁掉的如果 按下 上箭头 键? 与 在地面 真 那么 将 y速度 设为 12 将 在地面 设为 假注意这里在地面必须在跳跃瞬间立刻置假否则同一帧内重力还没生效下一帧判断时它还是真就会出现连按连跳。我最初写这个逻辑时就漏了这一句测试时疯狂按上键角色能贴着墙一直往上爬。3.3 受伤与无敌帧用条件给事件上锁碰撞扣血看起来最简单实际是全篇最容易出 bug 的地方。最朴素的写法是如果 碰到 尖刺? 那么 将 血量 增加 -1问题是碰到在每一帧都成立角色只要贴着尖刺血量就会以每秒几十点的速度掉一秒钟就从 3 掉到 -50。这就是典型的条件持续成立事件被重复触发。解决办法就是 1.3 说的加锁用已受伤变量做一个时间闸门如果 碰到 尖刺? 与 已受伤 假 那么 将 血量 增加 -1 将 已受伤 设为 真 重复执行 10 次 将 虚像特效 增加 10 将 虚像特效 设为 0 将 已受伤 设为 假这段的结构值得细看判断是碰到 且 未受伤进入后立刻把锁锁上播完无敌动画再把锁打开。中间那段重复执行 10 次改虚像其实充当了一个简易计时器同时还能做出闪烁效果。这里有个细节坑闪烁循环跑在条件内部这意味着在这 10 次循环期间角色脚本是被卡住的因为这是同一个脚本其他脚本不受影响。如果你希望闪烁期间角色还能移动就把闪烁逻辑拆到另一个脚本里主脚本只负责扣血和上锁。已受伤这个思路可以推广到几乎所有一次性事件过关、拾取道具、触发对话、播放音效。统一模式是条件 且 未触发 → 置为已触发 → 做事情 → 视情况复位。记住这个模板能省掉大量重复思考。3.4 门禁、钥匙与多条件组合集齐钥匙才开门是练习逻辑组合的好例子。条件本身不复杂如果 钥匙数 3 与 已过关 假 那么 将 已过关 设为 真 广播 过关但这里有个设计选择值得说是每次循环都判断一次还是只在吃到钥匙的那一刻判断一次我的做法是放在吃钥匙的脚本末尾吃完立刻判如果 碰到 钥匙? 那么 将 钥匙数 增加 1 删除 钥匙 克隆体 如果 钥匙数 3 那么 广播 开门这么写的好处是不用每帧轮询开销小坏处是如果钥匙数因为别的原因变了比如调试时手动改门不会自动开。对于作品来说前者更重要。真要做成实时响应的那就放回主循环里每帧判代价是每次循环多一次比较——对 Scratch 来说微乎其微取舍看你的具体需求。另一种常见写法是用碰到 门 且 钥匙数 3合成一个条件我一般不建议。因为碰到门和钥匙够不够是两件独立的事合成一个条件后如果玩家钥匙不够又站在门上你没法给出还差几把钥匙的提示。拆成两层判断先判碰到再判够不够中间插一句提示文字体验会好很多。条件语句不只是控制流程它还是给玩家反馈的时机。3.5 用否则链搭一个角色状态机前面都是零散的条件最后把它们串起来就得到主角的状态机。状态机听起来高级在 Scratch 里就是用状态变量 一串否则如果实现如果 血量 0 那么 将 状态 设为 死亡 否则 如果 已过关 真 那么 将 状态 设为 胜利 否则 如果 碰到 尖刺? 那么 将 状态 设为 受伤 否则 将 状态 设为 正常注意顺序死亡优先于胜利胜利优先于受伤最后才是正常。这个顺序不是随便排的它代表了优先级——一个人物同时血量归零和过关时应该显示死亡还是胜利看你的策划但必须明确写死不能让它随机。这就是条件语句顺序的意义它是有语义的不是随便摆的。状态机搭好之后后面所有行为都围绕状态展开比如受伤状态才允许闪烁、死亡状态禁用输入、胜利状态冻结物理。这种结构最大的好处是扩展时不用改原有逻辑只需在链上加一层。我后面再给这个角色加冲刺状态只是插一层判断的事前面那段一个字节都不用动。4. 条件语句的性能与作用域那些运行时才暴露的问题积木搭对了跑起来还是可能不对。Scratch 的执行模型有两件事必须搞明白一是脚本之间的调度顺序二是克隆体的独立作用域。这两块不懂条件语句写得再工整也会出现玄学现象。4.1 轮询频率、帧率与每帧判一次的代价Scratch 默认一秒刷新约 30 次每次刷新里每个重复执行循环会跑一轮。这意味着你的条件判断频率大约是每秒 30 次。对于碰撞检测来说这个频率够用但如果角色速度快、体型小30 次采样就可能穿过障碍物——在两帧之间从障碍物左边飞到右边两帧都没有判定为碰到于是穿墙。这不是条件写错了是采样点太少。解决思路有两条。一是降低速度上限或者给障碍物加宽让角色不可能在两帧之间跨过去。假设角色一次移动 15 像素障碍物厚度至少要到 20 像素以上才稳妥如果速度是 30 像素一帧障碍物就得 35 像素起步。这个参数是可以算出来的别凭感觉调。二是在移动前预判先算目标位置判断目标位置是否碰到障碍物碰到就不移动。这相当于把碰撞检测从事后补救改成事前拦截稳定性好很多将 目标x 设为 ((x坐标) (x速度)) 如果 目标x -220 与 目标x 220 那么 将 x坐标 设为 (目标x)代价是每帧多做几次运算收益是角色不会再出现卡进墙里再被弹出来的恶心现象。4.2 广播与条件的竞态广播和条件语句混用是另一个高频事故点。典型的错误写法是在一个脚本里如果 条件 那么 广播 开始游戏另一个脚本里当接收到 开始游戏直接开始跑结果发现开始游戏跑了两遍。原因往往是这个如果写在一个每帧都跑的循环里条件一旦持续为真广播就每秒发 30 次。修法还是那一条——给广播加锁或者把广播从循环里拿出来只在条件从假变真的那一刻发。判断从假变真需要一个历史变量写法是如果 条件 与 上次状态 假 那么 将 上次状态 设为 真 广播 触发这种边沿触发的写法凡是需要某个状态刚出现时做一次事的场景都能用比每帧发广播要稳得多。提示广播发出后接收脚本的执行时机不一定是立刻它可能排在当前帧的其他脚本之后。如果你在广播之后紧接着判断接收方有没有做完事几乎必然得到错误答案。涉及顺序依赖的用等待或者用一个双方共享的变量做握手别指望广播的时序。4.3 嵌套层级与自制积木的拆分策略条件嵌套超过三层除了难看还有个实际影响调试成本直线上升。你没法单独测试最内层因为它外面套着三层条件。我的经验是超过三层就拆成自制积木把内层逻辑封装进去主流程只保留如果 那么 执行 XX 积木。比如前面那个状态机四层嵌套下去已经很深了。可以拆成三个自制积木判定是否死亡、判定是否胜利、判定是否受伤每个里面只有一层判断返回布尔值主流程写成如果 判定是否死亡 那么 ... 否则 如果 判定是否胜利 那么 ...这样每层逻辑都独立可测主流程也一眼能读完。自制积木在 Scratch 里还支持运行时不刷新屏幕对于纯判断类的积木勾上这个选项能让执行更连贯。不过要注意勾了不刷新之后里面的等待、移动这些需要画面反馈的操作就看不到了这个开关是给纯计算用的。4.4 克隆体中的条件作用域克隆体是条件语句最容易出谜案的地方。核心规则只有一条克隆体的变量分两种全局变量所有克隆共享私有变量每个克隆一份。如果你用了全局变量然后每个克隆都去改它就会出现几十个克隆抢同一个变量结果是一团乱麻。举个真实例子。做一个弹幕每个子弹克隆体在如果 碰到 玩家 那么 广播 扣血结果一碰到就扣几十点血——因为每一个克隆体都有自己的条件判断几十个子弹同时判定成立同时广播。修法是把扣血逻辑收到一个统一的地方子弹只负责碰到后删除自己血量由玩家角色自己判// 子弹克隆体 如果 碰到 玩家? 那么 删除此克隆体 // 玩家角色 如果 已受伤 假 那么 如果 碰到 子弹? 那么 将 血量 增加 -1 将 已受伤 设为 真职责一分开所有并发问题自动消失。我后来的习惯是扣血、加分这类改全局状态的事永远只让一个角色负责其他角色最多发通知。另外克隆体里有一个经典陷阱当作为克隆体启动时下面的脚本和原角色脚本是各自独立的。很多人在克隆体脚本里写重复执行 如果 碰到边缘 那么 删除此克隆体忘了先把克隆体位置设好结果克隆体刚出生在原点就被判碰到边缘删掉了表现为子弹发不出来。排查时要先看克隆体出生那一刻的坐标。5. 常见问题与排查技巧实录条件语句的 bug 有个共同特征它们不会报错只会让行为变得奇怪。所以排查靠的不是看日志而是靠缩小范围、加探针。下面这几类是我遇到频率最高的配上一套我自己的排查顺序。5.1 条件永远成立或永远不成立这是第一大类。现象是角色一直抖、一直扣血、或者该触发的从不触发。排查顺序我固定是四步第一把条件拆开单独测。A 与 B不成立就分别打印 A 和 B看是哪个不对。做法很简单临时建两个变量一个存 A 的结果一个存 B 的结果在屏幕上勾选显示。第二检查变量类型。如果比较对象里有变量先确认它在第一帧被初始化过。空值参与数值比较是万恶之源。第三检查比较方向。10 分数和分数 10在数学上等价但人在改代码时很容易只改一半导致10 分数这种反向写法。数值刚好落在边界另一侧时才会暴露测的时候专挑边界值试。第四检查作用域。如果这个条件写在克隆体脚本里确认它读的变量是私有还是全局克隆之间有没有互相覆盖。5.2 条件只触发一次或疯狂触发第二大类本质是触发频率控制问题。只触发一次通常是因为判断放在了没有循环的脚本里——脚本从头跑到尾跑完就停条件只算了那么一次。疯狂触发则相反判断在循环里、条件又持续为真。现象最可能原因处理方式只生效一次判断没套在重复执行里外套重复执行每秒触发几十次条件持续为真事件无锁加锁变量改边沿触发触发两三次后停循环被停止这个脚本打断检查循环内的停止积木每次运行次数不一样与帧率相关缺时间去重改用计时器做冷却冷却这件事值得单独提。用重复执行 N 次做冷却N 的值其实和帧率绑死机器快慢不同效果就不同。更稳的做法是用计时器如果 计时器 冷却结束时间 与 按下 空格 键? 那么 将 冷却结束时间 设为 ((计时器) 0.5) 发射子弹这样冷却 0.5 秒是真实时间不受帧率影响。这个写法我在做射击类作品时全靠它。5.3 多个条件互相打架第三类最隐蔽条件本身都对但组合起来结果不对。典型是移动脚本和碰撞脚本抢坐标——一个脚本把角色推到墙外另一个脚本又把它拉回来表现为高频抖动。根源是同一帧内两个脚本都在改同一个属性。处理办法是明确谁拥有这个属性。位置只让物理脚本改碰撞脚本只读不改需要改就发一个标志变量由物理脚本下一帧处理。这套思路在正经游戏开发里叫单一职责在 Scratch 里同样适用。我改别人的作品时第一件事就是把所有角色的脚本按改什么分类发现两个角色同时改 x 坐标的一律合并或者拆权。还有一种打架是逻辑上的状态变量一会儿被这条脚本设成受伤一会儿被那条设成正常谁最后跑谁赢。Scratch 的脚本调度顺序不保证所以这种竞争的结果是不确定的。解决办法是只让一个地方写状态其他地方只读。这也是自制积木拆分最大的价值——把写操作收拢到一个入口。5.4 排查速查表与几条硬经验最后给一张速查表我一般贴在显示器旁边出问题先照着过一遍检查项怎么查常见结论变量初始化了吗绿旗脚本第一屏忘了设初值空值参与比较条件在循环里吗看积木外层没套循环只判一次事件加锁了吗找触发后的置位语句持续触发需要锁类型对得上吗单独打印条件两侧字符串和数字混比克隆体作用域对吗看变量是全局还是私有多个克隆抢同一变量是否同一帧被改两次按属性归类脚本两个脚本抢同一属性边界值试过了吗专门用 0、1、最大值测差一错误、方向写反再补三条不在表里的经验。第一先在纸上画条件树再动手搭积木尤其是嵌套超过两层的纸上五分钟积木上半小时。第二每加一个新条件就把旧的测试用例重跑一遍Scratch 没有自动化测试全靠手动回归懒一次就埋一个雷。第三条件里不要写魔法数字把 90、75、60 这些阈值设成变量改的时候一次改完不会漏。我个人在实际做作品时最深的一点体会是条件执行语句写得好的标志不是它能实现多复杂的功能而是你在加新功能时不需要回头改老逻辑。那些能一路迭代下去的作品脚本打开都是清清爽爽的几层判断每个条件只管一件小事锁和状态都摆得明明白白。反过来凡是写成一坨嵌套、改一处崩三处的基本都是把条件当万能胶见缝就贴。把这套骨架吃透剩下的就是往里面填内容——而这件事只有你自己动手搭过几十遍才会真的变成手感。 
长河君 · 2026/11/3 16:26:20 · 阅读 1.2k Scratch条件执行语句详解：从布尔判断到状态机实战
1. 条件执行语句到底在解决什么问题在 Scratch 控制模块里条件执行语句是绝大多数作品从能动跨到会思考的分水岭。我见过太多初学者角色能走能跳、能跟着鼠标跑但一碰到碰到敌人扣血分数到 100 才开门按住上键才能跳这类需求就卡住——不是不会拖积木而是脑子里那套从上往下一条线走到底的执行模型和条件语句要求的走到岔路口先看一眼再决定往哪走完全对不上。这篇文章就把 Scratch 条件执行语句这套东西讲透它是什么、三种形态怎么选、布尔条件怎么写、嵌套和否则如果怎么搭、性能上有什么讲究、出问题怎么查。适合刚接触控制模块的新手也适合已经能做完整小游戏、但条件逻辑写得又长又乱、改一处崩一片的中级玩家。Scratch 里的条件执行语句本质上就是三块积木的组合如果 条件 那么、如果 条件 那么 … 否则以及配套的等待 条件和重复执行直到 条件。它们的共同点是——积木里那个六边形的凹槽只能塞进一个是/否的问题。这个是/否就是布尔值它不返回数字、不返回文字只返回真或者假。理解了这一点条件语句的 90% 困惑就自动消解了不是你在写如果分数大于 100 就开门而是你在问分数大于 100 吗然后系统回答真或假真就走里面的积木假就跳过去。为什么条件执行语句值得单独拿出来讲因为它是 Scratch 里唯一能把状态转成行为的通道。变量、侦测、计时器这些都是原料条件语句是那个开关。没有它角色只能按脚本写好的顺序机械播放有了它角色才能在每一帧重新判断我现在该干什么。这背后其实是游戏开发里最朴素也最重要的东西——状态机。一个能上台面的 Scratch 作品骨子里都是一堆条件在打架谁的判断写在前面、谁的判断嵌套了几层、谁的判断每帧都在重复执行直接决定作品是丝滑还是卡顿、是稳定还是诡异。我在帮人看作品时有个习惯先不看美术直接打开角色脚本数一数它有几个重复执行套着如果。如果屏幕上半部分是几十个平铺的如果下半部分是乱成一团的嵌套那这个作品后期基本改不动了。条件语句写得好不好看的不是能不能跑起来而是三个月后你还敢不敢动它。1.1 条件执行语句和顺序执行的本质差别顺序执行就像照着菜谱做菜切菜、下锅、翻炒、装盘一步一步来中间不会因为你今天心情不好就跳到装盘。Scratch 里没有条件语句的脚本就是这样绿灯一点从头跑到尾跑完就停。问题是现实需求几乎全是带分支的——按下空格才跳没按下就站着碰到地面才允许跳空中再按不算血量归零才结束没归零就继续。条件执行语句做的事是在这条流水线上插了一个岔路口。程序走到岔路口先算一遍条件算出真就从那么里穿过去算出假就整个跳过那么里的内容继续往下。注意跳过这两个字很关键条件为假时里面的积木是完全不执行的不是执行了但没效果是压根没进去。这一点解释了新手最常见的疑惑——我在如果里面改了变量为什么没变因为条件压根没成立那行改变量的代码就没跑过。我做过一个对比演示给学员看同样一个角色用顺序执行写前进 10 步、碰到边缘就反弹再换成条件执行写如果碰到边缘 那么 反弹。前者在角色走到边缘时会先撞出去再被拉回来动作是卡顿的后者在撞到边缘的同一帧就完成判断并转向看起来顺滑得多。差别不在积木数量在于判断发生的时机和位置。1.2 三类条件积木的形态差异与选用原则很多人把这几块积木混着用其实它们的分工非常明确选错了就会出现只执行一次或每一帧都重复触发的毛病。我把它们摆在一起对比一下积木形态执行方式典型场景用错的后果如果 条件 那么单次判断逐帧由外层循环驱动碰撞检测、按键检测、状态刷新放在没有循环的脚本里只会判一次如果 条件 那么 … 否则单次判断二选一开关切换、成功/失败分流两个分支都写相同内容等于白写等待 条件阻塞式条件不成立就一直卡在这行等待点击开始、等待扣血动画播完用了它后面所有脚本全部暂停重复执行直到 条件循环式条件不成立就反复跑里面蓄力条、冷却倒计时、按住加速条件写成永假会死循环作品卡死选用的核心判断只有一句话这件事你要判一次还是要一直判判一次用如果一直判用如果套在重复执行里或者干脆用重复执行直到。而等待是这三种里最容易用出事故的——它是阻塞的一个角色卡在等待 碰到 敌人它的其他脚本还能跑但这个脚本里等待之后的所有内容全部静止。我见过有人把整个游戏主循环都塞在等待 鼠标按下后面结果游戏画面彻底冻住还以为是自己电脑卡。1.3 条件背后的布尔表达式六边形凹槽里能放什么说清楚条件语句必须顺带说清楚那个六边形凹槽里到底能塞什么。Scratch 把它限定得很死只能放返回真/假的积木大致分四类比较类 、 可以比数字也可以比文字按字典序左边右边都能嵌变量和运算积木。逻辑类 与 、 或 、 不成立 用来把多个条件拼起来。侦测类碰到 角色 ?、碰到颜色 颜色 ?、颜色 颜色 碰到 颜色 ?、按下 键 键?、按下鼠标?、响度 数值、计时器 数值、距离 角色 数值等等。状态类任何放在 里的变量配合比较积木使用。这四类有一个共同特征它们问的都是现在这一刻的事实不记录历史。所以分数 100这条判断在分数从 100 变成 101 的那一帧成立、之后一直成立不会自己触发一次就失效。这就是为什么过关这种一次性事件必须自己加锁——用一个已过关变量做闸门过了就置为真条件写成分数 100 与 已过关 假才能保证只触发一次。这个技巧后面还会细说先记住结论条件语句本身没有记忆记忆得靠变量补。2. 条件积木的核心细节与易错点拆解真正把条件语句写崩的往往不是大逻辑而是一些小细节比较运算的类型转换、字符串和数字的混用、逻辑运算的分组顺序、那个不起眼的否则该不该写。这些问题在积木层面上看不太出来跑起来才发现它怎么黑屏了它怎么一直是对的。这一章把这些细节拆开讲都是我在实际带人和改作品时反复碰到的。2.1 比较运算的隐形类型转换Scratch 的比较积木相当宽容10 9这种写法它就当数字比得 10 9 为真但如果你不小心把它写成了abc 9它就会退化成字符串比较按字典序逐位比结果会让你莫名其妙。更隐蔽的是空字符串和 0 的关系变量没赋值时是空字符串变量 0在很多情况下居然是真的因为空串被转成了 0。我曾经帮人查一个开局血量直接归零的 bug查了半小时最后发现是血量变量在初始化之前就被拿去比较了而那一帧刚好又触发了扣血条件。我的习惯是任何参与数值比较的变量在作品开始的第一帧必须显式初始化。用绿旗事件下面第一件事就是将 变量 设为 0一个都不能漏。这看起来是废话但十次数值错乱里有六次是这个原因。另外需要比较小数的时候要特别小心浮点误差0.1 0.2不等于0.3这种事在 Scratch 里一样存在。所以涉及金币数量、生命值这类整数尽量保证运算全程是整数涉及坐标比较别用x坐标 100用x坐标 99.5 与 x坐标 100.5这种区间判断稳得多。2.2 逻辑运算的组合与分组陷阱与、或、不成立这三块积木是可以互相嵌套的Scratch 没有提供括号只能靠物理嵌套来表达优先级。麻烦在于与和或混在一起时人的直觉理解往往和实际执行不一致。比如A 或 B 与 C很多人的本意是A 或 B并且 C但如果你是把B 与 C塞进了或的右边实际执行就是A 或B 且 C一个括号的差别逻辑完全变了。规避方法很土但很有效混用与/或的时候先把最内层的条件拼好再一层层往外套套完读一遍成句的中文。如果读出来和你想表达的不一样就重搭。另外不成立这块积木不要滥用不成立 碰到 敌人实际上是可读的但不成立 A B 或 C D 这种三层往里塞的我自己写完第二天都看不懂。遇到复杂条件正确做法是拆成多个如果或者用变量先把中间结果存下来给变量起个像样名字比死磕嵌套强得多。2.3 那个经常被忽略的否则新手写条件几乎只用单分支的如果 那么遇到相反的情况就再写一个如果 那么把条件取反。这么写能用但有两个隐患一是条件一旦写错两个分支可能同时不成立角色进入一个谁都没处理的黑洞状态卡在那里不动二是两个条件如果都成立比如你忘了取反两块积木会连着跑出现抖动。双分支的如果 那么 否则天然保证了二选一永远有一条路被走到。我在写角色状态切换时几乎全部用双分支如果 速度 0 那么 面向 0 度 否则 面向 180 度。这种结构无论速度是多少角色都一定有一个朝向不会出现贴图消失这种诡异现象。所以我给自己的规矩是只要存在明确的两种可能一律用否则不留空白分支。代价是多拖一块积木收益是排除了一个整类的状态遗漏 bug。2.4 否则如果链的手工搭建方式Scratch 原生没有否则如果多分支只能自己搭。最标准的做法是把下一层如果塞到上一个否则里面形成一个阶梯状的嵌套。以分数评级为例如果 分数 90 那么 将 等级 设为 A 否则 如果 分数 75 那么 将 等级 设为 B 否则 如果 分数 60 那么 将 等级 设为 C 否则 将 等级 设为 D这个结构之所以成立靠的是从高到低依次判断命中即停。因为一旦第一层为真就不会进否则分支后面的判断全部跳过。所以顺序绝对不能乱——如果先判 60那 95 分也会落到 C因为第一层就命中了。这个坑我见过太多次尤其是中途改阈值的时候只改数字不改顺序测试用的分数又刚好避开边界上线就出事。阶梯嵌套的视觉问题是很深四层下去积木就缩成一条线了。我的处理办法是控制在三层以内超过三层就改用变量或自制积木拆开或者干脆把判断写在不同的角色、不同的脚本里。可维护性这件事在 Scratch 里同样是真金白银。3. 从零搭建一套可复用的条件控制实战案例光讲原理容易飘我拿一个最简单的横版小场景来把条件语句跑一遍一个角色左右移动、跳跃落地、撞刺扣血、吃钥匙开门、血量归零结束。这个场景不复杂但几乎覆盖了条件语句所有常见用法把它的骨架吃透其余需求都是在这个骨架上改条件。先说清单。角色两个主角、可碰撞的障碍物用颜色或角色都行这里用角色。变量四个x速度、y速度、血量、钥匙数。再加三个控制用的开关变量已受伤、已过关、在地面。这套变量清单看着多但只要每个变量只承担一件事逻辑就会非常清楚——我强烈建议新手养成一个变量一件事的习惯别搞成状态一个变量装十种含义后面每加一个功能都要改它改着改着就崩了。3.1 主循环骨架把判断分批装进重复执行主角的脚本我通常分成三段每段一个绿旗事件各自独立跑第一段是输入采样只负责读键盘把结果写进变量当 绿旗 被点击 将 x速度 设为 0 将 y速度 设为 0 将 血量 设为 3 将 钥匙数 设为 0 将 已受伤 设为 假 将 已过关 设为 假 重复执行 将 x速度 设为 0 如果 按下 右箭头 键? 那么 将 x速度 设为 5 如果 按下 左箭头 键? 那么 将 x速度 设为 -5这里用两个独立的如果而不是如果 否则是有意的左右同时按下时后一个覆盖前一个角色表现为往左走不会抽搐。如果写成如果 否则同样是后一个覆盖前一个效果一致但二次判断结构更清晰方便以后加同时按下加速这类逻辑。第二段是物理更新负责位置、重力、边界重复执行 将 x坐标 增加 (x速度) 如果 x坐标 220 或 x坐标 -220 那么 将 x坐标 设为 ((x坐标) 和 -220 与 220 之间的夹取)这里 Scratch 没有内置夹取我一般直接用两个条件分别处理如果 x坐标 220 那么 将 x坐标 设为 220 如果 x坐标 -220 那么 将 x坐标 设为 -220这两条之所以分开写是因为边界是两个独立的事实合成一个条件再加分支要写嵌套反而不如两条平铺读起来快。第三段是状态判定扣血、开门、结束都是条件语句的重灾区下面分开讲。3.2 边界反弹与落地判定条件里的前一帧思维落地判定是经典难点。直觉写法是如果 y坐标 地面高度 那么 在地面设为真。但这个写法有个毛病角色从下往上穿的时候也会被判成在地面。正确做法是结合 y 速度判断——只有在下落y 速度小于 0并且脚底已经低于地面高度时才算落地如果 y速度 0 与 y坐标 -80 那么 将 y坐标 设为 -80 将 y速度 设为 0 将 在地面 设为 真 否则 如果 y坐标 -80 那么 将 在地面 设为 假这段代码里在地面变量的真假切换是靠两个分支完成的逻辑上等价于在地面上就是真否则就是假。为什么不用直接赋值将 在地面 设为 y坐标 -80因为 Scratch 里布尔值可以当变量值用但很多初学者不知道而且直接塞进去的可读性差。用显式的条件赋值虽然多两块积木但一眼能看懂。跳跃的条件就需要用到在地面了而且必须加一个y速度 0或者在地面 真的闸门否则空中可以无限跳俗称空中二段跳很多小游戏就是被这个毁掉的如果 按下 上箭头 键? 与 在地面 真 那么 将 y速度 设为 12 将 在地面 设为 假注意这里在地面必须在跳跃瞬间立刻置假否则同一帧内重力还没生效下一帧判断时它还是真就会出现连按连跳。我最初写这个逻辑时就漏了这一句测试时疯狂按上键角色能贴着墙一直往上爬。3.3 受伤与无敌帧用条件给事件上锁碰撞扣血看起来最简单实际是全篇最容易出 bug 的地方。最朴素的写法是如果 碰到 尖刺? 那么 将 血量 增加 -1问题是碰到在每一帧都成立角色只要贴着尖刺血量就会以每秒几十点的速度掉一秒钟就从 3 掉到 -50。这就是典型的条件持续成立事件被重复触发。解决办法就是 1.3 说的加锁用已受伤变量做一个时间闸门如果 碰到 尖刺? 与 已受伤 假 那么 将 血量 增加 -1 将 已受伤 设为 真 重复执行 10 次 将 虚像特效 增加 10 将 虚像特效 设为 0 将 已受伤 设为 假这段的结构值得细看判断是碰到 且 未受伤进入后立刻把锁锁上播完无敌动画再把锁打开。中间那段重复执行 10 次改虚像其实充当了一个简易计时器同时还能做出闪烁效果。这里有个细节坑闪烁循环跑在条件内部这意味着在这 10 次循环期间角色脚本是被卡住的因为这是同一个脚本其他脚本不受影响。如果你希望闪烁期间角色还能移动就把闪烁逻辑拆到另一个脚本里主脚本只负责扣血和上锁。已受伤这个思路可以推广到几乎所有一次性事件过关、拾取道具、触发对话、播放音效。统一模式是条件 且 未触发 → 置为已触发 → 做事情 → 视情况复位。记住这个模板能省掉大量重复思考。3.4 门禁、钥匙与多条件组合集齐钥匙才开门是练习逻辑组合的好例子。条件本身不复杂如果 钥匙数 3 与 已过关 假 那么 将 已过关 设为 真 广播 过关但这里有个设计选择值得说是每次循环都判断一次还是只在吃到钥匙的那一刻判断一次我的做法是放在吃钥匙的脚本末尾吃完立刻判如果 碰到 钥匙? 那么 将 钥匙数 增加 1 删除 钥匙 克隆体 如果 钥匙数 3 那么 广播 开门这么写的好处是不用每帧轮询开销小坏处是如果钥匙数因为别的原因变了比如调试时手动改门不会自动开。对于作品来说前者更重要。真要做成实时响应的那就放回主循环里每帧判代价是每次循环多一次比较——对 Scratch 来说微乎其微取舍看你的具体需求。另一种常见写法是用碰到 门 且 钥匙数 3合成一个条件我一般不建议。因为碰到门和钥匙够不够是两件独立的事合成一个条件后如果玩家钥匙不够又站在门上你没法给出还差几把钥匙的提示。拆成两层判断先判碰到再判够不够中间插一句提示文字体验会好很多。条件语句不只是控制流程它还是给玩家反馈的时机。3.5 用否则链搭一个角色状态机前面都是零散的条件最后把它们串起来就得到主角的状态机。状态机听起来高级在 Scratch 里就是用状态变量 一串否则如果实现如果 血量 0 那么 将 状态 设为 死亡 否则 如果 已过关 真 那么 将 状态 设为 胜利 否则 如果 碰到 尖刺? 那么 将 状态 设为 受伤 否则 将 状态 设为 正常注意顺序死亡优先于胜利胜利优先于受伤最后才是正常。这个顺序不是随便排的它代表了优先级——一个人物同时血量归零和过关时应该显示死亡还是胜利看你的策划但必须明确写死不能让它随机。这就是条件语句顺序的意义它是有语义的不是随便摆的。状态机搭好之后后面所有行为都围绕状态展开比如受伤状态才允许闪烁、死亡状态禁用输入、胜利状态冻结物理。这种结构最大的好处是扩展时不用改原有逻辑只需在链上加一层。我后面再给这个角色加冲刺状态只是插一层判断的事前面那段一个字节都不用动。4. 条件语句的性能与作用域那些运行时才暴露的问题积木搭对了跑起来还是可能不对。Scratch 的执行模型有两件事必须搞明白一是脚本之间的调度顺序二是克隆体的独立作用域。这两块不懂条件语句写得再工整也会出现玄学现象。4.1 轮询频率、帧率与每帧判一次的代价Scratch 默认一秒刷新约 30 次每次刷新里每个重复执行循环会跑一轮。这意味着你的条件判断频率大约是每秒 30 次。对于碰撞检测来说这个频率够用但如果角色速度快、体型小30 次采样就可能穿过障碍物——在两帧之间从障碍物左边飞到右边两帧都没有判定为碰到于是穿墙。这不是条件写错了是采样点太少。解决思路有两条。一是降低速度上限或者给障碍物加宽让角色不可能在两帧之间跨过去。假设角色一次移动 15 像素障碍物厚度至少要到 20 像素以上才稳妥如果速度是 30 像素一帧障碍物就得 35 像素起步。这个参数是可以算出来的别凭感觉调。二是在移动前预判先算目标位置判断目标位置是否碰到障碍物碰到就不移动。这相当于把碰撞检测从事后补救改成事前拦截稳定性好很多将 目标x 设为 ((x坐标) (x速度)) 如果 目标x -220 与 目标x 220 那么 将 x坐标 设为 (目标x)代价是每帧多做几次运算收益是角色不会再出现卡进墙里再被弹出来的恶心现象。4.2 广播与条件的竞态广播和条件语句混用是另一个高频事故点。典型的错误写法是在一个脚本里如果 条件 那么 广播 开始游戏另一个脚本里当接收到 开始游戏直接开始跑结果发现开始游戏跑了两遍。原因往往是这个如果写在一个每帧都跑的循环里条件一旦持续为真广播就每秒发 30 次。修法还是那一条——给广播加锁或者把广播从循环里拿出来只在条件从假变真的那一刻发。判断从假变真需要一个历史变量写法是如果 条件 与 上次状态 假 那么 将 上次状态 设为 真 广播 触发这种边沿触发的写法凡是需要某个状态刚出现时做一次事的场景都能用比每帧发广播要稳得多。提示广播发出后接收脚本的执行时机不一定是立刻它可能排在当前帧的其他脚本之后。如果你在广播之后紧接着判断接收方有没有做完事几乎必然得到错误答案。涉及顺序依赖的用等待或者用一个双方共享的变量做握手别指望广播的时序。4.3 嵌套层级与自制积木的拆分策略条件嵌套超过三层除了难看还有个实际影响调试成本直线上升。你没法单独测试最内层因为它外面套着三层条件。我的经验是超过三层就拆成自制积木把内层逻辑封装进去主流程只保留如果 那么 执行 XX 积木。比如前面那个状态机四层嵌套下去已经很深了。可以拆成三个自制积木判定是否死亡、判定是否胜利、判定是否受伤每个里面只有一层判断返回布尔值主流程写成如果 判定是否死亡 那么 ... 否则 如果 判定是否胜利 那么 ...这样每层逻辑都独立可测主流程也一眼能读完。自制积木在 Scratch 里还支持运行时不刷新屏幕对于纯判断类的积木勾上这个选项能让执行更连贯。不过要注意勾了不刷新之后里面的等待、移动这些需要画面反馈的操作就看不到了这个开关是给纯计算用的。4.4 克隆体中的条件作用域克隆体是条件语句最容易出谜案的地方。核心规则只有一条克隆体的变量分两种全局变量所有克隆共享私有变量每个克隆一份。如果你用了全局变量然后每个克隆都去改它就会出现几十个克隆抢同一个变量结果是一团乱麻。举个真实例子。做一个弹幕每个子弹克隆体在如果 碰到 玩家 那么 广播 扣血结果一碰到就扣几十点血——因为每一个克隆体都有自己的条件判断几十个子弹同时判定成立同时广播。修法是把扣血逻辑收到一个统一的地方子弹只负责碰到后删除自己血量由玩家角色自己判// 子弹克隆体 如果 碰到 玩家? 那么 删除此克隆体 // 玩家角色 如果 已受伤 假 那么 如果 碰到 子弹? 那么 将 血量 增加 -1 将 已受伤 设为 真职责一分开所有并发问题自动消失。我后来的习惯是扣血、加分这类改全局状态的事永远只让一个角色负责其他角色最多发通知。另外克隆体里有一个经典陷阱当作为克隆体启动时下面的脚本和原角色脚本是各自独立的。很多人在克隆体脚本里写重复执行 如果 碰到边缘 那么 删除此克隆体忘了先把克隆体位置设好结果克隆体刚出生在原点就被判碰到边缘删掉了表现为子弹发不出来。排查时要先看克隆体出生那一刻的坐标。5. 常见问题与排查技巧实录条件语句的 bug 有个共同特征它们不会报错只会让行为变得奇怪。所以排查靠的不是看日志而是靠缩小范围、加探针。下面这几类是我遇到频率最高的配上一套我自己的排查顺序。5.1 条件永远成立或永远不成立这是第一大类。现象是角色一直抖、一直扣血、或者该触发的从不触发。排查顺序我固定是四步第一把条件拆开单独测。A 与 B不成立就分别打印 A 和 B看是哪个不对。做法很简单临时建两个变量一个存 A 的结果一个存 B 的结果在屏幕上勾选显示。第二检查变量类型。如果比较对象里有变量先确认它在第一帧被初始化过。空值参与数值比较是万恶之源。第三检查比较方向。10 分数和分数 10在数学上等价但人在改代码时很容易只改一半导致10 分数这种反向写法。数值刚好落在边界另一侧时才会暴露测的时候专挑边界值试。第四检查作用域。如果这个条件写在克隆体脚本里确认它读的变量是私有还是全局克隆之间有没有互相覆盖。5.2 条件只触发一次或疯狂触发第二大类本质是触发频率控制问题。只触发一次通常是因为判断放在了没有循环的脚本里——脚本从头跑到尾跑完就停条件只算了那么一次。疯狂触发则相反判断在循环里、条件又持续为真。现象最可能原因处理方式只生效一次判断没套在重复执行里外套重复执行每秒触发几十次条件持续为真事件无锁加锁变量改边沿触发触发两三次后停循环被停止这个脚本打断检查循环内的停止积木每次运行次数不一样与帧率相关缺时间去重改用计时器做冷却冷却这件事值得单独提。用重复执行 N 次做冷却N 的值其实和帧率绑死机器快慢不同效果就不同。更稳的做法是用计时器如果 计时器 冷却结束时间 与 按下 空格 键? 那么 将 冷却结束时间 设为 ((计时器) 0.5) 发射子弹这样冷却 0.5 秒是真实时间不受帧率影响。这个写法我在做射击类作品时全靠它。5.3 多个条件互相打架第三类最隐蔽条件本身都对但组合起来结果不对。典型是移动脚本和碰撞脚本抢坐标——一个脚本把角色推到墙外另一个脚本又把它拉回来表现为高频抖动。根源是同一帧内两个脚本都在改同一个属性。处理办法是明确谁拥有这个属性。位置只让物理脚本改碰撞脚本只读不改需要改就发一个标志变量由物理脚本下一帧处理。这套思路在正经游戏开发里叫单一职责在 Scratch 里同样适用。我改别人的作品时第一件事就是把所有角色的脚本按改什么分类发现两个角色同时改 x 坐标的一律合并或者拆权。还有一种打架是逻辑上的状态变量一会儿被这条脚本设成受伤一会儿被那条设成正常谁最后跑谁赢。Scratch 的脚本调度顺序不保证所以这种竞争的结果是不确定的。解决办法是只让一个地方写状态其他地方只读。这也是自制积木拆分最大的价值——把写操作收拢到一个入口。5.4 排查速查表与几条硬经验最后给一张速查表我一般贴在显示器旁边出问题先照着过一遍检查项怎么查常见结论变量初始化了吗绿旗脚本第一屏忘了设初值空值参与比较条件在循环里吗看积木外层没套循环只判一次事件加锁了吗找触发后的置位语句持续触发需要锁类型对得上吗单独打印条件两侧字符串和数字混比克隆体作用域对吗看变量是全局还是私有多个克隆抢同一变量是否同一帧被改两次按属性归类脚本两个脚本抢同一属性边界值试过了吗专门用 0、1、最大值测差一错误、方向写反再补三条不在表里的经验。第一先在纸上画条件树再动手搭积木尤其是嵌套超过两层的纸上五分钟积木上半小时。第二每加一个新条件就把旧的测试用例重跑一遍Scratch 没有自动化测试全靠手动回归懒一次就埋一个雷。第三条件里不要写魔法数字把 90、75、60 这些阈值设成变量改的时候一次改完不会漏。我个人在实际做作品时最深的一点体会是条件执行语句写得好的标志不是它能实现多复杂的功能而是你在加新功能时不需要回头改老逻辑。那些能一路迭代下去的作品脚本打开都是清清爽爽的几层判断每个条件只管一件小事锁和状态都摆得明明白白。反过来凡是写成一坨嵌套、改一处崩三处的基本都是把条件当万能胶见缝就贴。把这套骨架吃透剩下的就是往里面填内容——而这件事只有你自己动手搭过几十遍才会真的变成手感。