1. 一个让人抓狂的现象：背景为什么会跑到角色前面去
前阵子有人拿着一个半成品的Scratch作品来问我：“背景坏了不显示前面了，明明画好了山和天空，运行起来整个画面却被一块黑乎乎的东西盖住，角色怎么点都不出现。”我打开项目一看，问题一下就清楚了——那块“黑乎乎”根本不是一个背景，而是一个被导入成“角色”的黑色底板，还执行了“移到最前面”。
这不是个例。Scratch的外观模块里，层次相关的指令看起来很简单，无非是“移到最前面”“移到最后面”“前移N层”“后移N层”，但实际放到作品里，很容易出现类似“背景莫名其妙跑到角色前面”的诡异现象。很多新手第一反应是“背景坏了”，其实背景永远不会坏，真正出问题的是图层顺序。
这类问题我至少见过三四次，表现形式五花八门：
- 做了一个夜晚场景，背景图明明没变，但运行后屏幕全黑，舞台上只剩下一个能移动的主角；
- 照片里的背景图是被当成“角色”上传的，结果这张图把自己当成“最前面的角色”，把真正的角色全挡住了；
- 场景切换时新出现的装饰角色挡住了主角，无论你怎么调“背景”都没反应。
先说一个最根本的结论：Scratch里的“舞台背景”是永远垫底的一块底板，它不可能跑到任何角色前面。那为什么你看到的背景“盖住”了角色？只有一个解释——你看到的并不是背景，而是一个被放在高层级上的角色。把背景图做成角色放进舞台，再误点“移到最前面”，背景自然就成了“天花板”。
搞清楚这一点，我们再回头看那句常见说法：“把背景放到第一个层次，然后设置移到最前面。”这句话只有在把背景当作“角色”来用时才可能存在，而且顺序恰恰说反了——如果背景是个角色，你要做的是把它“移到最后面”，而不是“移到最前面”。按下这个思路，整个层次指令的问题就值得从头好好拆一遍。
2. 拆开“层次指令”：Scratch的图层顺序到底是怎样运作的
2.1 先搞懂“舞台背景”和“角色”的本质区别
Scratch的舞台由两部分组成：背景和角色。背景是那个永远不变的底座，你可以把它理解成画画的纸；角色是画在纸上的一层一层透明胶片。换背景只是换一张纸，角色永远画在纸上，所以你无论如何都不可能让真正的背景遮住角色。
那“层次”到底是指谁的层次？严格说，Scratch里的“层次”几乎只用来描述角色之间的遮挡关系。每个角色在舞台上都占据一个“层”，层号大的显示在层号小的前面。背景在最底下，可以看成是第0层；第一个添加的角色默认在某个基础层上，之后每添加一个新角色，通常会把新角色放在现有所有角色的最前面。
这里有个很容易踩的坑：不少教材说“后加入的角色会显示在最前面”，但Scratch的角色列表面板上缩略图的排列顺序，和层号的大小是挂钩的。你在角色列表里拖动那些缩略图，其实就是在手动调整层次。列表的排列方向在不同版本里略有差异（有的从左到右、有的从上到下），但规律是一致的——越靠某个方向的角色，显示时越靠前。我自己在搭项目时，会把角色列表当成一个“排队顺序表”来看：谁在最前面显示，谁就在列表的相对末端。
2.2 四类层次积木，各自的实用场景
Scratch外观模块里处理层的积木，常见的有四种，不同中文版翻译可能略有差别，但本质功能不变：
| 常见积木写法 | 实际含义 | 典型用途 |
|---|---|---|
| 移到最前面 | 把当前角色提升到所有角色之上 | 临时突出某个角色、对话框、UI提示 |
| 移到最后面 | 把当前角色降到所有角色之下、背景之上 | 把误当成角色的“背景图”压到底层 |
| 前移 1 层 | 层号增加，角色往更靠前的方向移动一格 | 做同层内的微调，比如人物从树后走到树前 |
| 后移 1 层 | 层号减少，角色往更靠后的方向移动一格 | 做遮挡效果、穿插效果 |
还有一类积木是“移动到 [指定] 层”，或者新版本里直接叫“层次”，图标上写着类似“移到 xxx 层”。这个积木不是让你“往前移几格”，而是直接把角色设置到某一个具体层号。比如你希望一个背景式角色永远在第1层，那就可以直接“移到第1层”，无论它之前被谁拖到哪一层，都会立刻回到第1层。
用打牌来类比：角色就是一叠扑克牌，越靠上的牌越先被看到，背景是桌面，永远在牌的最底下。前移/后移就是在这叠牌里向上或向下挪一格；移到最前面就是把这副牌直接放到牌堆顶端；移到指定层就是不管它现在在哪儿，直接插到第N张的位置。
2.3 为什么“指定层次”才是最靠谱的那个积木
如果你只是随便做个五分钟的小演示，用“移到最前面”当然怎么方便怎么来。但一旦项目里有多个角色在不停切换场景、显示隐藏、添加删除，“移到最前面”就会带来很大的灾难。
原因是：层次是一个全局状态。每当任何一个角色执行“移到最前面”，它就会亮出“王牌身份”，盖住所有其他角色。这不是一次性的，只要脚本里还在反复触发，它就会反复干扰其他角色的相对顺序。更麻烦的是，一旦有人又对另一个角色执行了一次“移到最前面”，新的角色反而会成为最顶层的那个。结果就是：你的“主角永远在最前”的愿望，会被后来触发的任何“移到最前面”彻底击穿。
所以我的建议是：凡是那种要长期稳定显示在固定位置的元素——比如背景式角色、地面、装饰物、UI面板——都不要用“移到最前面/最后面”来控制。老老实实用“移到指定层”，给每个角色预设一个固定层号。这就引出了下一个问题：到底应该怎么设这个层号？
3. 用几个小实验把“谁在谁前面”彻底搞明白
很多人对层次指令的理解停留在“点了有效果就行”，但从没有系统地观察过层号变化。我建议你花十分钟，按下面这一组实验把Scratch的层次行为亲手跑一遍，之后所有遮挡问题都会迎刃而解。
3.1 实验一：新建角色的默认顺序
新建一个项目，依次添加三个角色：角色A、角色B、角色C。不要加任何脚本，直接点绿旗。你会在舞台上看到C在A和B的上面，B在A的上面。也就是说，后添加的角色默认显示在最前面。
这个结论为什么重要？因为很多做游戏的场景里，大家习惯先添加背景类角色，再添加主角，再添加装饰，最后发现装饰全盖在主角头上。你以为是“装饰乱入”，其实是默认规则本来就这样——后加入的角色天然更靠前。
3.2 实验二：前移和后移的真实效果
给角色B添加“前移1层”并运行。你会看到B跳到了C的前面。如果再给B加“后移1层”，它又会掉回原来的位置。注意：这里移动的是“相对位置”，不是绝对层号。如果C后来又执行了“前移1层”，它和B的顺序又会再次变化。
前移/后移适合做临时穿插，比如主角走到树后面再走出来的那一下。但如果你在一个重复执行的循环里同时对多个角色做前移后移，顺序会变得非常不可控。
3.3 实验三：移到指定层的数值含义
给角色C添加“移到第1层”，运行后观察：C会沉到最下面，紧贴着背景。再给角色A添加“移到第3层”，运行后A会出现在最前面。这个实验直接说明了层号数值的规则：数字越小越靠近背景，数字越大越靠近观众。在多数Scratch版本中，背景固定在第0层，角色从第1层开始，最大层号通常等于当前角色总数。
这也解释了为什么我强烈建议用“指定层”做初始化：你可以在项目开始时统一把所有角色安排到固定层号，之后即便某些角色被临时搬走，也能通过一条指令回归原位。
3.4 实验四：隐藏、显示和克隆体带来的变数
再试试给角色A添加“隐藏”，再“显示”。惊喜来了——隐藏再显示并不会改变层次，A还是原来那层。这点倒是让人省心。
但克隆体完全不同：克隆体出现时默认显示在最前面，而且没有任何一条积木可以直接给单个克隆体指定层号。这可以说是Scratch层次系统里最坑的一个设计。如果你的项目里大量使用克隆体，你需要提前把“克隆体永远盖住普通角色”这个特点考虑进去。
这四个实验跑完，你就拥有了一套完整的“层次判断力”：看到任何遮挡现象，先不要慌，想想它是不是克隆体、是不是后加入的角色、是不是在循环里反复执行了前移后移。
4. 排错实录：从“背景不显示”到定位成图层问题的完整链路
4.1 第一步：先分清遮挡物到底是不是背景
遇到“背景坏了，角色不显示”这种问题，找原因的顺序比直接改代码更重要。第一件事就是去角色列表里看：那块“黑乎乎”的东西旁边，写的是“舞台”还是某个角色名。
如果是舞台，那根本不可能挡住角色，问题一定出在角色之间的层序上。如果那是一个角色，并且它的造型就是你的背景图，恭喜，这就是最典型的问题：背景图被当成角色导入了。这时候不需要改任何脚本，把这个角色在列表里手动拖到最左侧（或最上方，取决于你的编辑器排列方式），或者给它执行一次“移到最后面”，它就会重新回到背景层附近。
我见过很多人在这一步停留了很久，因为他们一直认为是“背景切换命令写错了”，结果检查来检查去，命令完全没问题，问题出在资源本身就放错了位置。
4.2 第二步：用临时积木确认遮挡关系
当你看不出是谁在遮挡时，最快的办法是给“嫌疑人”角色临时加一段测试脚本：当绿旗被点击，移到最前面。如果加上这条后这个角色马上出现在最上层，那它就是遮挡者；如果加了没反应，说明它本来就不在最上面，真正遮挡者另有其人。
这时候再把这个测试角色改回“移到指定层”，并设置一个较小的层号。通过一轮轮试下来，你很快就能给每个角色找到合理的层号。
4.3 第三步：留意克隆体和重复执行脚本
如果角色排查完了还是乱，不要忽略克隆体。在某项目里，一棵树用克隆体生成了一大片树林，运行后树林把主角完全盖住。我给主角加了“移到最前”发现没用——因为每生成一个克隆体，克隆体都会重新回到最前面，把主角压下去。最后解决方案是：让树的克隆体生成后执行“移到第1层”，把树林统一压到最底层附近，主角就露出来了。
还有一个常见陷阱：某些角色身上有一段循环执行的脚本，每隔0.3秒就执行一次“移到最前面”。这种脚本可能在调试时被人忘记了，导致所有其他角色怎么调顺序都会被瞬间压下去。遇到这种“明明我已经设置了正确层次，一运行又乱套”的情况，一定要全局搜索“移到最前面”这几个字，看看是不是有角色在循环执行。
4.4 第四步：修复的三种做法，按项目复杂度选择
根据我排错的经验，修复方案可以分成三个级别。
- 最简单：手动在角色列表中拖动缩略图，调好顺序后就再也不动层次相关的积木。适合静态演示、动画短片。
- 中等：给容易乱的角色加一条“移到指定层”的初始化积木，在项目开始时设置一次，运行中再去用前移/后移做局部微调。适合一般的小游戏。
- 最稳：全项目统一采用“指定层”管理，每个角色都有一个固定层号，任何要改变层次的操作都通过“移到指定层”完成，绝不使用“移到最前面”。
第三个方案正是那句“把角色放到指定的层次，才能把这个积木正确用起来”的真正含义。层次指令最适合的角色，就是“指定层”这个积木；从前移后移这些相对操作开始用，很容易在复杂项目里失去控制。
5. 让层次长期不乱：项目里的层级规划技巧与习惯
5.1 给整个项目做一张“层次基准表”
我在做稍微复杂一点的作品时，会先画一张层次表，放在项目描述或者纸上，类似这样：
| 层号 | 内容 | 说明 |
|---|---|---|
| 0 | 舞台背景 | 真正切换背景的底板 |
| 1 | 远景装饰（山、云） | 如果这些被做成了角色，统一在此层 |
| 2 | 地面、障碍物 | 角色要走到它们后面时放这层 |
| 3 | 道具、可拾取物 | 和角色互动时做前后穿插 |
| 4 | 主角、NPC | 核心可操作角色 |
| 5 | 对话框、UI提示 | 需要永远显示在前面的信息 |
| 6 | 特效、遮罩 | 全屏渐黑、闪光之类 |
有了这张表，任何新角色加入时，你只需要在它的初始化脚本里写“移到第X层”，而不再纠结“它应该在哪一个相对位置”。这种做法的最大好处是：即使隔了很久再打开这个项目，甚至换一个人来看，也能一眼明白每个角色的层次关系。
5.2 用广播统一调度层次，而不是各自为战
如果项目里有多个场景切换，比如从户外到室内，每个场景都有不同的遮挡需求，我会用一个“场景切换”的广播来统一管理层次。切换场景时，发送广播“场景1”、“场景2”，每个角色收到对应广播后设置自己的层号。
举个例子，在一个校园探索项目里，主角要走到树后、走进教学楼、再走到告示牌前。我让所有建筑和树木在接收“户外场景”广播后统一“移到第1层”，主角在“移到第4层”，告示牌文字在“移到第5层”。这样每次切换场景，层次都会按照预设自动归位，不会再出现“上次调好的层级这次又乱了”的情况。
5.3 写代码时的硬性习惯：禁止乱用“移到最前面”
“移到最前面”不是不能用，而是要明确它的使用边界。我给自己定的习惯是：只有在需要临时提醒用户、弹对话、显示全屏遮罩时，才允许用“移到最前面”，并且用完之后立刻用“移到指定层”恢复原位。平时绝对不用它来“让主角不被挡住”——因为这不是一劳永逸的方案，反而是制造混乱的源头。
这种硬性约束刚开始会有点不习惯，总觉得自己绕了一圈。但实际上，用“指定层”建立秩序，远比反复用“移到最前面”跟其他角色抢位置省心得多。
最后再分享一个小技巧：如果你在调试层次问题时实在找不到遮挡者，可以先“全部隐藏”，然后一个个角色单独“显示”，看哪一个在最上面。这个观察方法比反复改代码快得多。把这些层次习惯养成了，你会发现“背景坏了不显示前面”这类问题，基本不会再在你自己的作品里出现。
