Scratch 3 图形化编程避坑：坐标、广播与克隆体实操

发布时间：2026/10/29 23:02:00

带过几批人从零开始摸 Scratch 3 之后，我发现一个挺有意思的现象：真正把新手卡住的，几乎从来不是"想不出要做什么作品"，而是软件操作层面的一堆小动作——角色挪到舞台上一跑就飞出边界、点了绿旗角色还赖在上一局的位置、明明写了广播另一个角色就是不响应、克隆体越点越多最后画面卡成幻灯片。这些问题在各类教程里通常一句"把积木拖过去就行"就带过了，可实际操作里，恰恰是这些被一笔带过的细节在消耗时间。

Scratch 3 是一款面向图形化编程的积木式软件，用拖拽积木代替敲代码，能做小游戏、动画、互动故事、甚至简单的模拟工具。它的门槛低到你打开就能拖几块积木让角色走路，但它的"隐性知识点"一点都不少——坐标系、图层、帧率、克隆体上限、变量作用域、文件格式，每一样都能让一个看起来没问题的作品跑出意料之外的结果。这篇内容面向的是已经装好软件、能拖几块积木、但总觉得"哪里不对劲"的使用者，也适合准备带别人上手、需要把操作细节讲透的人。下面全部按我实际用下来踩过的顺序讲，从界面到造型，从积木取用到坐标、广播、克隆、保存，一个一个拆。

1. 打开软件先别急着拖积木，五个区域的职责先划清

很多人第一次启动，注意力会全部被中间那一大片彩色积木吸走，直接开始拖。拖了十几分钟发现角色不动，才回头去找舞台在哪。这种情况我见过不止一次。先把界面分区认清楚，后面所有操作都会顺很多。

1.1 舞台、角色列表、积木区、代码区各自的职责边界

Scratch 3 的主界面可以拆成五块，每块负责的事完全不同，混着用就容易出问题。

左上角那块带白色背景的方框是舞台，尺寸固定为 480 像素宽、360 像素高，所有角色最终呈现的画面在这里。舞台上方有三个小按钮：绿旗（开始运行）、红色八边形（停止全部）、以及一个可以切换舞台显示模式的双向箭头。舞台的显示模式分两种，一种是正常大小，一种是全屏；全屏模式下积木区会被挤掉，只留舞台和一个退出按钮，做演示的时候很实用，但调试阶段别开，容易误以为代码丢了。

舞台左下角是角色列表，每个角色以缩略图形式排列，右下角有个圆形加号按钮用来添加角色。这里有个容易被忽略的细节：角色列表里显示的缩略图是"当前造型"的预览，如果你切换了造型但没在代码区看到变化，多半是因为当前选中的角色不是你以为的那个。角色列表高亮框选中的那个，才是代码区正在编辑的对象。

中间偏右的大片区域是代码区，积木拖进来之后拼装的地方。代码区左上角会显示当前编辑的角色名，这个名字很重要——它决定了你写的这段代码属于谁。很多"代码写了没反应"的问题，追根到底就是代码写在了 A 角色身上，但你盯着 B 角色看。

最左边竖排的彩色圆点是积木分类区，一共九个大类：运动、外观、声音、事件、控制、侦测、运算、变量、自制积木。点一下圆点，中间会展开对应的积木抽屉。分类区的最下方还有一个"添加扩展"按钮，用来加载画笔、音乐、文字朗读这类额外模块。

剩下的顶部菜单栏管的是文件级别的操作：语言切换、文件保存与加载、编辑（恢复和小舞台模式）、教程入口。这五块区域的分工记住一句话就够了：舞台看结果，角色列表选对象，代码区写逻辑，积木区取素材，菜单栏管文件。调试时眼睛在舞台和代码区之间来回扫，手在积木区取件，中间不要跳步。

1.2 顶部菜单里几个低频但救命的按钮

菜单栏那几个选项平时点得少，但真出事的时候能省不少事。

"编辑"菜单里有个恢复功能，撤销上一步操作。这个功能只保留最近一次，不是无限撤销，所以拖错积木之后要立刻按，晚了就找不回来了。同一个菜单里还有小舞台模式，勾选之后舞台会缩到左上角一个小窗口，代码区能腾出更多横向空间，写长脚本的时候特别舒服，尤其是那种嵌套四五层的条件判断，正常模式下看得眼睛疼。

"文件"菜单里有三样东西值得记住：从电脑中上传、保存到电脑、加载示例项目。上传和保存是一对，前者把本地的 .sb3 文件读进来，后者把当前作品存成本地 .sb3。示例项目那一栏我个人建议新手都翻一遍，不用全看，挑两三个结构完整的（比如带克隆体的、带列表的）打开，直接读别人的积木排列方式，比看文字教程快得多。

语言切换在菜单栏最左边那个地球图标里，中英文可以随时切。切换语言不会影响作品内容，但会影响积木上的文字显示——如果你在网上找到的教程截图是英文的，切换一下对照着看会方便很多。

提示：菜单里的"恢复"只有一步，重要节点建议手动保存一次副本，尤其是准备大改结构之前。改坏了回不去的感觉，比想象中难受。

2. 角色和造型：中心点、图层、大小这三件事决定角色听不听话

角色拖进舞台之后看起来差不多，但内部有三个属性在悄悄决定它的行为：中心点、图层、大小。这三个不搞清楚，后面写移动、碰撞、显示隐藏的代码会一路别扭。

2.1 造型编辑器里的中心点到底在控制什么

选中一个角色，点角色列表上方的"造型"标签，就进了造型编辑器。编辑器中间那个角色图上会有一个十字准星，这就是中心点。它是整个角色所有位置计算的基准。

这件事的具体影响是：当你在代码里写"移到 x: 0 y: 0"，软件做的是把中心点放到舞台正中央，而不是把角色的外框中心放过去。如果中心点在角色左下角，那么执行完这条积木，角色会整体往右上偏移，看起来像"跑偏了"。同理，"面向 90 方向移动 10 步"也是以中心点为轴。

中心点的位置可以手动拖：在造型编辑器里选中角色图，直接拖动十字准星到想要的位置。做横版游戏的角色，我一般把中心点放在脚底正中间，这样角色站在地面上时位置计算最直观，跳跃高度也容易算——y 坐标加多少就是跳多高，不用再减去半个身位。做道具或者 UI 元素，中心点放正中间更省事。

还有一处容易忽略：切换造型之后中心点可能不一致。如果一个角色有两套造型，一套的中心点在中间、一套在左上角，那么切换造型的瞬间角色会"跳"一下。这不是 bug，是两套造型的中心点没对齐。解决办法是在造型编辑器里逐套检查，把准星统一到同一个相对位置。

2.2 图层顺序错乱导致角色"消失"的排查

角色列表的排列顺序就是图层顺序，列表越靠上的角色越靠前显示。新添加的角色默认排在最上面，也就是最前面。

实际会出现的情况是这样的：你做了一个背景板角色铺满舞台，然后加了一个主角，结果主角不见了。原因很可能是背景板是后加的，压在主角上面。把角色列表里背景板那一项往下拖，或者干脆在代码里给主角加一块"移到最前面"，问题就解决了。

外观分类里有四块图层积木，作用各不相同：

这里有个新手常犯的混淆："移到最前面"和"移到 x y"是完全不同的两类积木。前者在"外观"分类里管图层，后者在"运动"分类里管位置。两块积木名字都带"移到"，拖的时候看一眼分类颜色，运动是深蓝色，外观是紫色，看颜色就能分辨。

注意：图层顺序只在同一层级内比较有效，角色很多的时候频繁调整顺序很乱。我的习惯是固定的几层结构——最上面放 UI 和提示文字，中间放主角，下面放可交互物件，最底层放背景板。新加角色先拖到对应层，后面就很少再动。

2.3 大小积木是百分比，不是像素

"将大小设为 100"这条积木里的 100 指的是100%，也就是造型的原始尺寸。"将大小增加 10"是在当前基础上加 10 个百分点，不是加 10 像素。

这个区别在需要精确控制的时候很关键。举个例子：一个 60 像素宽的角色，你希望它变成 120 像素宽，得把大小设成 200，而不是设成 120。如果角色本身是从矢量图形导入的，放大不会糊；如果是从位图图片导入的，放大超过 200% 之后锯齿会非常明显，这种情况下宁可重新画一套更大的造型，也不要硬拉。

大小还会影响"碰到"判定。角色缩放之后，碰撞检测用的是缩放后的外框轮廓（实际上是基于造型的包围区域近似计算），所以小尺寸角色的碰撞会比视觉上更"宽容"一点，贴着边缘擦过去可能不触发。做精度要求高的游戏，别指望碰撞判定百分之百准，留一点容错空间反而稳。

3. 积木取用与代码区操作：把拖拽效率提上去

Blocks 拖得多了，手速就成了效率瓶颈。Scratch 3 在代码区里藏了不少快捷操作，知道和不知道，做一个中等规模作品的耗时能差出三四成。

3.1 积木分类的查找逻辑，以及"找不到积木"的排查路径

九个大类的划分逻辑不是按功能，而是按作用对象，理解了这一点找积木会快很多。

找积木的时候先想清楚"我要动的是谁"：动位置找运动，动样子找外观，动流程找控制，动数据找变量。按这个思路基本不会翻错抽屉。

如果确定在某类里但就是找不到，有三条排查路径。第一条，检查是不是在"扩展"里——画笔、音乐、文字朗读这些不在默认九类中，得先点左下角"添加扩展"加载出来。第二条，检查是不是被折叠了——某些版本的积木抽屉是分组显示的，往下滚一段才能看到全部。第三条，用积木区顶部的搜索框，直接输关键词，比如输"克隆"能立刻定位到相关积木，这条路径最快，熟练之后我基本都用搜索。

3.2 右键菜单、框选、整理积木这些隐藏操作

代码区里的右键菜单是被严重低估的功能。

在任何一块积木上点右键，会弹出几个选项：复制、添加注释、删除积木、帮助。"复制"直接生成一份带子积木的完整副本，做相似逻辑的时候能省一半拖拽量。"添加注释"会在积木旁边贴一张黄色便签，写清楚这段是干什么的，隔几天回来改代码的时候非常有用。"帮助"会跳转到这块积木的说明页，遇到不确定行为的积木，先看帮助比试错快。

在代码区的空白处点右键，会出现整理积木和清理。整理积木会把散落的积木堆自动排成整齐的竖列，间距拉开，找起来清爽很多。清理则是把没有连接到任何触发积木上的孤立积木全部删掉——这个功能要谨慎用，因为有些积木可能只是暂时放在旁边待用，清理掉就得重新拖。

还有几个手感层面的操作：鼠标滚轮可以缩放代码区，积木堆很长的时候缩到 50% 能一眼看到全貌；按住空白处拖动可以平移视野；从积木堆顶部拖住能整体搬走一整段，包括它下面挂着的所有子积木。这几条组合起来用，改长脚本的时候会顺手很多。

提示：拖动积木时如果只是轻轻点一下，很容易误触发"删除"（把积木拖回抽屉区）。手抖的人可以在代码区边缘留一块空白地带，临时放置的积木先扔那儿，别贴着抽屉。

4. 坐标与移动：角色跑偏、贴边、穿墙的根因

坐标是 Scratch 里最基础也最容易出错的一环。看起来只是两个数字，实际上舞台的坐标范围、角色的旋转方式、移动积木的落点规则三者叠加，能组合出一堆反直觉的现象。

4.1 舞台坐标范围和"移到 x y"的实际落点

Scratch 舞台的坐标原点在正中央，横轴 x 从左到右是 -240 到 240，纵轴 y 从下到上是 -180 到 180。这四个数字记住，后面所有位置计算都靠它。

| 位置 | x 坐标 | y 坐标 | | 舞台正中央 | 0 | 0 | | 左边缘 | -240 | 0 | | 右边缘 | 240 | 0 | | 上边缘 | 0 | 180 | | 下边缘 | 0 | -180 | | 左下角 | -240 | -180 | | 右上角 | 240 | 180 |

关键点在于：坐标描述的是角色的中心点位置，不是角色外框。所以一个宽 100 像素的角色，x 坐标设成 240 的时候，它有一半身体在舞台外面看不见。想要角色刚好贴住右边缘，x 得设成 240 减去半个宽度，也就是 190。

这个规则直接影响了"移动到边缘停下"这类逻辑的写法。常见的错误写法是把判断条件写成"如果 x 坐标 > 240 则停止"，实际角色早就跑出去一半了才触发。正确做法是留出角色半宽的余量，比如判断"x 坐标 > 200"就回退。不同宽度的角色余量不一样，我的经验是写成一个变量存起来，后面换角色只改这个变量值，不用满篇找数字。

还有一块积木值得单独说："在 1 秒内滑行到 x y"。它和"移到 x y"的区别是前者有过渡动画，后者是瞬移。滑行过程中角色的坐标是连续变化的，如果同时写了碰撞检测，检测会在滑行的每一帧执行，容易出现"滑行穿过障碍物却没触发碰撞"的情况——因为滑行太快，某一帧还在障碍物左边，下一帧已经到右边了。需要精确碰撞的时候，把滑行拆成小步循环会更可靠。

4.2 三种旋转方式带来的行为差异

角色属性面板里有个"旋转方式"，三个选项：任意旋转、左右翻转、不旋转。这个设置决定了角色在方向变化时的外观表现，也间接影响"面向 90 方向"这类积木的实际效果。

这里最容易踩的坑是横版角色没设成左右翻转。默认是任意旋转，角色往左走的时候整个人会倒过来，脚朝上，看起来非常奇怪。改成左右翻转之后就正常了。

另一个坑是方向值的范围。Scratch 里方向 90 是向右，-90 是向左，0 是向上，180 是向下。这个方向和数学课上的角度定义不一样，是顺时针从上方开始算的，刚接触的人容易记反。判断"角色是不是朝右"的时候条件写"方向 = 90"，别写"方向 = 0"。

还有一处细节：**"面向 90 方向"和"将方向设为 90"**这两块积木效果一样，但前者在拖动时是圆环形状、后者是数字输入框，视觉上不同，功能上等价。用哪个都行，看个人手感。

5. 事件、广播与控制：多角色协作最容易乱的地方

单角色项目怎么写都不会太乱，一旦角色超过三个，事件和广播的时序就成了主要矛盾来源。

5.1 广播和广播并等待，差的是"要不要等"

这两块积木长得很像，名字只差三个字，行为差别却很大，是新手最容易用混的一对。

举一个具体的场景：主角碰到金币，金币角色要播放一个"消失动画"（大概 0.5 秒），然后分数加 1。如果用"广播金币消失"再紧跟着"将分数增加 1"，那么分数会在金币动画还没播完的时候就加上去了，视觉上会有点脱节。换成"广播并等待金币消失"，分数就会等动画结束才加，节奏顺很多。

反过来，如果广播的目的是"通知所有角色开始游戏"，那就不该用"广播并等待"——它会卡在当前脚本上，直到所有接收方跑完，而那些接收方里往往有"重复执行"的循环，永远跑不完，整个流程就卡死了。这种场景必须用普通广播。

还有一个隐蔽点：广播消息的名字是字符串匹配。如果你的代码里用了"开始游戏"这个名字，然后你手动把这个广播重命名成"游戏开始"，软件会弹一个提示问要不要同步更新引用。如果选了"否"，那些旧的接收积木就会变成空白的接收积木，看起来还在但永远不触发。改动广播名之后，最好把相关的接收积木都扫一遍，确认没有变成空白。

5.2 停止全部之后的状态残留，和绿旗重启的初始化

点了红色八边形"停止全部"之后，再点绿旗重新开始，很多人会以为一切归零了。实际上不是。

停止全部会终止所有脚本运行，但角色的位置、造型、大小、可见性、变量值都保留在停止那一刻的状态。也就是说，如果主角在游戏结束时停在舞台右侧、造型是"受伤"、变量"分数"是 37，那么重新点绿旗，主角还是从右侧、受伤造型、分数 37 开始跑。

要真正做到"重新开始"，需要在绿旗触发之后、正式逻辑之前，手动把关键状态重置一遍。我一般会在主角的脚本最上面固定挂一小段初始化：

移到 x: 0 y: 0
将大小设为 100
换成造型「默认造型」
显示
面向 90 方向
将「分数」设为 0
将「生命值」设为 3

这段积木不长，但每次都会写。省掉它，测试的时候就会遇到"第二次运行行为不一样"的诡异现象，排查半天找不到原因。

注意：克隆体不受"停止全部"的完全清理。点停止之后克隆体脚本会停，但克隆体对象本身可能还留在舞台上（取决于版本和操作顺序）。保险做法是在绿旗初始化里加一块"删除此克隆体"这类逻辑，或者用"当作为克隆体启动时"配合一个隐藏加删除的兜底。

6. 变量、列表与克隆体：作用域和上限是两个硬约束

变量和克隆体是 Scratch 从"能玩"跨到"能做出像样作品"的门槛，也是最容易写出隐性 bug 的两块。这里的坑大多不是逻辑错，而是对规则理解不到位。

6.1 全局变量和局部变量，选错就会互相污染

新建变量的时候，会弹出一个对话框让你选"适用于所有角色"还是"仅适用于当前角色"。这两个选项对应全局变量和局部变量。

判断标准很简单：这个数据是不是需要多个角色共同看到。需要，就选全局；不需要，就选局部。

局部变量的价值在于隔离。假设你有五个敌人角色，每个都需要记录"自己还剩多少血"。如果用全局变量，五个敌人共享同一个血量值，打其中一个，五个一起掉血。改成局部变量之后，每个敌人各有一份独立的血量，互不干扰。

这里有个新手常问的问题：局部变量能不能被别的角色读到？答案是不能，代码区里别的角色根本看不到这个变量名。所以如果某段逻辑需要"让别的角色知道"，那它必须是全局的，没有第三条路。

列表的规则和变量一样，也分全局和局部。列表适合存一组数据，比如关卡地图、对话文本队列、随机不重复的抽奖结果。读取列表的积木在变量分类里，主要有"第 n 项"、"项目数"、"删除第 n 项"、"在末尾添加"这几块。做需要"不重复随机"的功能时，标准做法是把候选池放进列表，每次随机取一项然后从列表里删掉，取到列表空了再重新填充，比反复随机加判断要可靠得多。

6.2 克隆体的 300 上限和删除时机

克隆体这块有条硬规则：整个项目中同时存在的克隆体数量上限是 300 个。这里的 300 是整个项目的总数，不是每个角色的配额。超了之后"创建克隆体"这块积木会静默失败，不报错，只是不再产生新的克隆体。

这个规则带来的典型症状是：游戏跑了十几秒之后突然卡住不动，子弹不再发射，敌人生成停止。如果项目里有"重复执行中不断创建克隆体"的写法，几乎肯定是撞上限了。

标准的克隆体结构是三段式：

第一段，触发端：在合适的时机执行"创建克隆体"。第二段，启动端：用"当作为克隆体启动时"开头，写克隆体自己的行为逻辑，比如移动、检测碰撞。第三段，清理端：在克隆体该消失的时候执行"删除此克隆体"。

第三段最容易被漏掉。很多人写完前两段就以为完事了，结果克隆体跑到舞台外面还在那里持续运行，占着数量额度。清理逻辑的判断条件一般是"碰到边缘"或者"坐标超出某个范围"或者"碰到某个目标"。

提示：调试克隆体数量有个土办法——新建一个全局变量，在"当作为克隆体启动时"里加 1，在"删除此克隆体"之前减 1，把这个变量显示在舞台角落。跑起来看一眼数字，就知道当前存活多少个，比盲猜快得多。

还有一处容易忽略：克隆体会继承创建那一刻的所有属性，包括位置、造型、大小、可见性、局部变量值。所以如果母体是隐藏状态，克隆出来也是隐藏的，需要在"当作为克隆体启动时"里显式写"显示"。这个继承特性也可以利用，比如先把母体移到某个位置再创建克隆体，克隆体就会出现在那个位置，省掉一次坐标设置。

7. 声音、保存与迁移：收尾阶段最容易被绊倒的环节

前面几块都跑通了，最后在保存和音频上翻车的情况我见过不少。这两块平时用得少，一旦出问题就特别抓瞎。

7.1 声音积木的几种播放模式，选错会互相打断

声音分类里的积木看起来简单，实际上"播放"这个动作有好几种模式，行为差别不小。

最常用的两块是"播放声音直到结束"和"开始播放声音"。前者会阻塞当前脚本，直到这段音频完整播完才执行下一块；后者是非阻塞，点一下就往下走，声音在后台继续播。做背景音乐用"开始播放声音"配一个"重复执行"循环，做音效配合动作节奏时用"播放声音直到结束"更稳。

这里有个坑：同一时间只能有一个声音在"播放声音直到结束"的通道里。如果两个角色同时执行"播放声音直到结束"，后一个会把前一个打断。想要多个音效叠加，得全部改成"开始播放声音"。

音量和音效也可以调。"将音量设为 X"的范围是 0 到 100，注意这不是系统音量，只影响这个角色自己。"将音效设为"后面可以接几种预设效果，比如"音调"（高低音）、"左右平衡"（左右声道偏向）。做踩到不同地块发出不同音高的音效，改音调比准备多段音频要省事得多。声音编辑器里还能做剪裁、淡入淡出、反转、加快减慢这些处理，导入一段长音频之后先裁掉多余的头尾，能显著减小文件体积。

7.2 sb3 文件的保存、导出和版本迁移的断裂点

保存这件事有一个基本事实：Scratch 3 的作品文件后缀是.sb3，本质是一个压缩包，里面装着项目结构描述文件、角色造型图片、音频文件。知道这一点之后，很多"文件很大""加载很慢"的问题就好理解了——造型和音频是原样打包进去的，图片尺寸越大、音频越长，文件越胖。

保存路径有三条，用途不同：

导出角色这个功能用的人少，但很实用。做了一系列作品之后，某些角色（比如通用的血条、通用按钮）可以单独导出成 .sprite3，新项目里直接导入，不用重画。

版本迁移这块要特别提醒：旧版本项目导入新版本时，部分积木的行为可能和原来不一致。最常见的是音频和造型的处理方式变化，或者是某些积木的参数范围调整。迁移之后不要直接发布，一定要完整跑一遍，重点检查三类地方——所有涉及声音播放的位置、所有涉及坐标边界的判断、所有克隆体逻辑。这三块是历史上出问题频率最高的。

另外养成一个习惯：大改之前另存一份带日期后缀的副本。比如"横版闯关_v3_备份"。Scratch 没有版本历史，在线保存还会直接覆盖，改崩了没有后悔药。这个习惯看起来笨，但它救回来的次数比任何调试技巧都多。

最后分享一个我用了很久的小操作：做完一个作品之后，把所有角色挨个点一遍，看每个角色的代码区里有没有孤立的、没有连到事件积木上的散块。这些散块多半是调试时留下的临时逻辑，跑起来不影响，但会让别人读你的作品时一头雾水，也容易在后续改动时被误触发。整理积木加手动扫一遍，五分钟的事，作品的可读性会上一个台阶。