Scratch 3.0指令大全：九大模块索引与核心积木实战避坑指南

简介：面向少儿编程及图形化编程初学者，这份《Scratch 3.0 指令大全》是一份PDF电子手册。它系统梳理了Scratch 3.0中的九大类、123个指令及3个创建按钮，同时覆盖官方扩展与第三方扩展。内容按“运动”“外观”“声音”等类别逐条讲解，对每个指令的名称、用途、参数设置都做了明确说明，并对重点指令补充了使用技巧。无论用于课堂辅助还是自学查阅，都能帮助零基础读者快速理解图形化积木的用法，减少盲目试错时间。

资源包仅包含1个PDF文件，大小约1015KB，轻量易保存，可离线随时查看，文件类型纯粹、无多余内容，下载后即可直接打开阅读。目前已有676人学习使用。通过这份手册，读者可以清晰掌握从坐标移动、方向旋转、反弹设置，到造型切换、大小调整、显示隐藏等核心技能，也能理解事件触发、条件判断、变量运算等逻辑概念，理清各模块指令间的协作关系，为后续独立创作动画、游戏或交互式作品奠定扎实基础。

1. Scratch 3.0 指令到底该怎么看：先建立索引，再谈背积木

拿到一个 Scratch 3.0 项目，打开积木区，第一反应往往不是“这个游戏真好玩”，而是“这一百多个积木到底按什么逻辑拼在一起”。Scratch 3.0 的指令（官方叫“积木”）数量不少，但日常项目里真正反复用到的不超过 40 个。所以这份指令大全的意义，不在于让你背全所有积木的名称，而在于建立一套自己的索引习惯：看到需求先归类到模块，再找到对应积木，最后确认参数。这篇文章就用这个思路，把模块逻辑、组合套路和常见翻车点一次讲清楚。适合刚带学生做项目的老师，也适合自己啃官方文档啃不下去的自学者。

2. 指令体系先立住：九大模块与“按需索引”思路

2.1 九大模块的设计逻辑：颜色、形状与参数槽

在 Scratch 3.0 里，指令区的积木按功能分成了九大模块，扩展里还有一些特殊功能块。第一层索引靠颜色：深蓝色是运动，紫色是外观，粉色是声音，黄色是事件，橙色是控制，浅蓝是侦测，绿色是运算，深橙色是变量，粉色渐变是自制积木。颜色看对了，需求也就定位到了模块。

第二层看形状。帽子块带圆弧顶，只能放在脚本最上方，比如“当绿旗被点击”；堆叠块上下有卡口，只能夹在脚本中间；C 型块像张开的嘴，能把一整套积木包在肚子里，所以循环和条件都长这样；布尔块是六边形，只能嵌在条件槽里，比如“碰到边缘？”；终结块是红色圆头，比如“停止全部脚本”。看到形状就知道这个指令能放在哪，这是排查脚本卡死最常用的判断方式。

第三层看参数槽。数字槽可以填数字，也能从变量区拖一个变量进去；下拉槽必须从列表里选；布尔槽只能接受六边形积木。把这三层看完，一个陌生积木八九不离十能猜出用法。我一般建议学习者别急着背指令名，先拿一个陌生模块的积木练“三层判断”，比逐条背效率高得多。颜色、形状、参数槽这三个维度，就是你手上的指令速查索引。

2.2 核心指令速查：先记这 36 个

指令大全要落地，先得有张够用的速查表。下面这张表是日常项目里出现频率最高的 36 个积木，按模块分组，覆盖了“移动、显示、发声、输入、循环、判断、计算、计数”这几类基本需求。我一般建议新手优先掌握这张表，冷门指令用到再查。

这张表的逻辑是：每个模块先记 2~3 个最常用的，参数只看最关键的，坑只记最容易踩的。等这些指令形成了肌肉记忆，再往冷门方向扩展。拿到一个项目先不急着读全部脚本，而是按模块过滤——只关心和当前需求相关的积木，其他指令暂时忽略。这个习惯能省掉大量无效阅读。

2.3 冷门指令什么时候才用得上

剩下的指令不是没用，而是使用场景更窄。比如“图章”在画笔扩展里，适合做轨迹残留特效；“询问并等待”能做出键盘输入交互；“计时器重置”适合做限时挑战；“视频侦测”需要摄像头参与，适合做体感互动。这些指令在标准课堂上很少用到，但一旦用到，往往就是项目的亮点。我见过一个模拟项目X，学生用“视频侦测”配合“移动”积木，做出了用手挡住小球反弹的效果，那个项目拿了当届的创意奖，靠的就是冷门指令组合。

不过冷门指令有两个共性风险：一是兼容性，文字朗读和翻译类的扩展依赖网络服务，离线环境直接失效；二是性能，视频侦测的积木每一帧都在处理画面，低配设备上会明显掉帧。所以我的建议是：课堂上优先把 36 个核心指令教透，冷门指令作为进阶彩蛋，用在比赛或者展示型项目里。判断一个指令值不值得学，看它在你的项目里有没有不可替代的作用，而不是因为它“看起来炫酷”。

3. 用“接苹果”小项目把指令串起来：从分类到拼搭

3.1 苹果下落：运动、控制、克隆的配合

指令单看起来容易，拼在一起才见功力。我用一个“接苹果”小项目把核心指令串一遍。这个项目的需求是：苹果从舞台顶部随机位置下落，玩家用篮子接住，接住得分，掉到地面游戏结束。逻辑不复杂，但能覆盖运动、外观、控制、侦测、运算、变量六个模块的协作。

先做苹果角色。苹果需要不断从顶部出现，而且不止一个，所以要用到“克隆自己”。脚本分两段：第一段是生成器，第二段是克隆体的行为。生成器就是一个无限循环，每次克隆自己后等待一个随机间隔：

当绿旗被点击 重复执行 克隆自己 等待 随机数 0.5 到 2 秒

这段脚本的逻辑是：绿旗点击后，角色本体变成“生产车间”，每 0.5 到 2 秒生成一个克隆体。随机间隔决定了游戏难度——间隔越短，苹果越密集。注意“克隆自己”的执行者是角色本身，而生成出来的克隆体会立刻触发“当作为克隆体启动时”的脚本。

克隆体的行为脚本是核心：

当作为克隆体启动时 移到 x: 随机数 -220 到 220 y: 180 显示 重复执行直到 碰到 舞台边缘 将 y 增加 -5 END 删除此克隆体

这里有几个关键参数要说明。x 范围控制在 -220 到 220，是为了不超出舞台边界，留出 20 的余量防止苹果半边出界。y 从 180 开始，正好在舞台顶部内侧。下落速度是每帧 -5，这个数值决定了游戏手感，调成 -3 会缓很多，调成 -8 基本来不及接。整个下落过程放在“重复执行直到”里，条件碰到舞台边缘是六边形侦测积木，它一成立就跳出循环，执行删除克隆体。

注意：克隆体删除不及时是性能杀手。很多新手把“删除此克隆体”写在条件外面，结果克隆体掉出舞台还继续占内存，几百个后项目直接卡死。正确做法是让删除操作待在下落的循环体内，条件一旦满足立刻清理。

3.2 计分与胜负判定：变量、侦测、运算的分工

苹果会掉了，篮子得能接住。篮子角色跟随鼠标横向移动，可以用一个极简脚本实现：

当绿旗被点击 重复执行 将 x 设为 鼠标的 x 坐标 END

这段不用写循环次数，重复执行会一直跑。“将 x 设为”这个指令直接改变角色横坐标，不需要“移动 10 步”那种增量方式，所以篮子永远和鼠标水平位置同步。如果你想限制篮子不跑出舞台，可以加一个判断：如果 鼠标的 x 坐标 大于 240，那么 将 x 设为 240。但更简单的做法是在舞台边缘留出缓冲，因为鼠标指针本身不会超出舞台范围。

接下来是计分。新建一个变量叫“得分”，作用域选“适用于所有角色”，这样苹果的克隆体和篮子都能访问。在苹果克隆体的下落循环里嵌套一个碰到篮子的判断：

当作为克隆体启动时 移到 x: 随机数 -220 到 220 y: 180 显示 重复执行直到 碰到 舞台边缘 将 y 增加 -5 如果 碰到 篮子 那么 将 得分 增加 1 删除此克隆体 END END 删除此克隆体

“碰到 篮子”是侦测模块的六边形积木，它检测的是克隆体自身和篮子角色的碰撞。一旦碰到，得分加一，然后马上删除这个克隆体，避免同一次碰撞重复计分。这里有个容易踩的坑：如果判断写在“重复执行直到”外层，克隆体碰到篮子后还会继续下落一段才被删除，看起来就像苹果穿透了篮子。把判断嵌套在下落循环内部，才能做到碰撞瞬间就消失。

胜负判定用“得分等于 10”作为胜利条件：

当绿旗被点击 重复执行直到 得分 等于 10 等待 0.1 秒 END 广播 胜利

这个脚本一直在检测得分变量的值，等到 10 就跳出循环并广播胜利消息。“等待 0.1 秒”是为了降低检测频率，避免每帧都判断一次消耗资源。你也许想说直接用“如果 得分 等于 10 那么”嵌套在篮子的重复执行里也行，但那样会把游戏逻辑和角色控制耦合在一起，后面想加暂停功能或者多人模式就麻烦了。

3.3 游戏结束广播：事件模块的消息机制

角色之间传递状态，靠的是事件模块的广播指令。胜利的广播发出去以后，需要一个接收方来显示结束画面。可以新建一个“游戏结果”角色，放两套造型，一套写“你赢了”，一套写“游戏结束”。接收脚本如下：

当接收到 胜利 切换到造型 你赢了 显示 停止全部脚本

“停止全部脚本”是控制模块的红色终结块，它会把所有角色正在跑的脚本全部停掉，包括苹果的生成器和篮子的移动循环。这样就避免出现胜利画面显示之后，苹果还在继续落下的尴尬局面。这个设计思路在指令大全里属于“事件驱动”的典型用法：角色之间不直接访问对方的脚本，而是通过广播消息解耦。

顺带说一下，如果想让失败判定也走同样的流程，可以在苹果掉到舞台边缘时广播“失败”。但注意，苹果的克隆体在 y 小于 -180 时会碰到舞台边缘，此刻如果广播失败，需要确保游戏结果角色已经准备好接收。常见做法是在绿旗点击后先隐藏游戏结果角色，等接收到胜利或失败消息再显示。隐藏用“外观”模块的“隐藏”，显示用“显示”，这两个简单积木配合广播就是用事件控制 UI 状态的常规套路。

4. 指令使用避坑：五个高频翻车现场

4.1 现象：角色明明设了方向 90，却朝斜上方跑

原因：Scratch 3.0 的方向约定和常规坐标系不一样，0 度朝向舞台正上方（12 点钟方向），90 度朝向正右方（3 点钟方向），-90 度朝左。很多新手习惯性认为 90 度是向上，方向一设就歪了。严格来说，这不算指令本身的 bug，而是方向角度和视觉直觉的偏差。

解决：写脚本前先明确“我想让角色朝哪个方向移动”，再换算成角度。向右 90，向左 -90，向上 0，向下 180。如果想偷懒，直接用“面向 鼠标指针”或者“面向 篮球”这类面向某个对象的积木，让积木自己算角度，不用手工填。遇到角色斜着走的项目，先检查“将旋转方式设为”是“任意旋转”还是“左右翻转”，任意旋转下角色会 360 度转，左右翻转则只会左右镜像。

4.2 现象：克隆体越积越多，项目运行到后期变得卡顿

原因：“删除此克隆体”没写在下落循环内部，或者压根没写。Scratch 对克隆体数量没有硬性警告，项目跑到上百个克隆体时，每个克隆体都在执行脚本，CPU 占用很快被吃满。另一个常见原因是生成器的“等待 随机数”时间太短，甚至没写等待，循环以每帧一个的速度疯狂克隆。

解决：先在生成器里加最小间隔，再检查克隆体脚本里有没有“删除此克隆体”收尾。养成一个习惯：每一次“克隆自己”都必须对应一个“删除此克隆体”出口。用“当作为克隆体启动时”写行为时，把删除操作放在重复循环体内，条件成立立刻删除。调试时可以在舞台角落加一个“侦测”“克隆体数量”的显示，实时观察有没有堆积。

4.3 现象：广播了消息，接收角色没反应

原因：广播和“广播并等待”是两回事。普通“广播”只负责发消息，发完立刻执行后面的积木，根本不关心接收方跑没跑完。如果广播后面紧跟着切换背景或者隐藏角色，接收方可能来不及响应就被环境变化打断了。另一个原因是接收方角色被隐藏了，而隐藏角色的脚本照样运行，但“当接收到消息”的帽子块不会在隐藏状态下触发。

解决：需要严格同步的场景用“广播并等待”，它会等所有接收方脚本执行完毕才继续。如果用了“广播并等待”还卡住，检查接收方脚本里有没有死循环，比如“重复执行直到”条件永远不成立。平时写广播消息，名字起得具体一些，比如“游戏开始”“切换关卡 2”，避免两个不同需求的角色收到同一条消息做出冲突反应。

4.4 现象：变量在某个角色里改了，其他角色读到的还是旧值

原因：新建变量时有两个作用域选项：“适用于所有角色”和“仅适用于当前角色”。默认是前者，但如果创建时选成了“仅适用于当前角色”，这个变量就成了该角色的私有变量，其他角色访问到的是自己那份副本，永远不共享。克隆体的情况更特殊，克隆体继承原角色启动时刻的私有变量值，之后各自独立变化。

解决：先确认变量面板里变量名称前面的图标——所有角色共享的变量图标是“全部”，私有变量图标是一个角色的形状。如果项目里需要跨角色计分，务必要用“适用于所有角色”。克隆体之间需要独立状态时（比如每个苹果有自己的速度），反而要用“仅适用于当前角色”的私有变量。这两种作用域没有谁好谁坏，只是适用场景不同，混用才会翻车。

4.5 现象：随机数积木填了“5 到 1”，脚本直接报错变红

原因：Scratch 3.0 的随机数积木要求下限小于上限，填反了就会在编辑器里直接显示为红色错误块，运行到这一句时项目会静默跳过，不会生成随机数。这个坑看似低级，但在参数由变量动态计算时非常容易踩——变量 A 比变量 B 大时，随机数范围就反了。

解决：动态生成随机范围前，先比较两个变量的大小，用“如果”判断保证下限小于上限。另外记住随机数包含两端，“随机数 1 到 10”能取到 1 也能取到 10。想生成 0 到 1 之间的小数，Scratch 的整数随机数做不到，常见做法是“随机数 0 到 100 / 100”，用除法得到小数结果，精度够用。

5. 把指令用活的进阶技巧：自制积木与调试习惯

自制积木是 Scratch 3.0 指令体系里最容易被忽略的进阶功能。它的本质是把你反复使用的一整坨积木封装成一个带名字、可传参的“新指令”，相当于把“下落 5 步”这种多积木组合压缩成一个块。在苹果角色里，我给苹果定义了一个“下落 速度”的自制积木，内部封装了“将 y 增加 速度”和“如果碰到篮子”的判断，之后每次调用只需要填一个速度参数。这样改游戏难度时，不用翻找克隆体脚本内部，直接改调用处的参数就行。自制积木还支持设置“运行时不刷新屏幕”，这个选项在大量计算场景下能明显提升流畅度，代价是屏幕上看不到实时变化，适合批量生成场景时使用。

调试习惯上，我强烈推荐右键点击积木选择“单步执行”，让项目一条积木一条积木地跑，配合“等待”积木可以看清每一句的执行顺序。这个功能在排查广播时序问题时尤其好用——能直观看到广播发出后接收方多久才响应。另一个习惯是用“说”积木临时显示变量值，比如在循环里加一句“说 得分”，运行时会实时弹出当前数值，比盯着变量面板直观得多，排错完再删掉即可。

最后分享一个习惯动作：遇到任何“卡顿”的项目，先查克隆体删除，再查广播等待，排掉这两个最多见的坑后再碰其它逻辑。曾经 A 同学做了一个射击游戏，子弹打到靶子上分数乱跳，我打开他的脚本，发现子弹的克隆体碰到靶子后同时执行了两次计分判断，又因为删除指令写在条件外，同一个子弹连续触发碰撞。把他改成碰到就删除、计分只写一次后，现象立刻消失。从那以后我一直坚持：先看生命周期，再看事件同步，最后才碰计算和变量。这个排查顺序省下的时间，比背熟全部指令多得多。希望帮到你。

本文还有配套的精品资源，点击获取