让我们来逐步分析一下上面的指令出了什么bug，也就是模拟一下游戏运行这条指令的过程。

假设现在整个世界仅仅只有3个实体：一名玩家（最早生成），一位村民和一只羊（最晚生成）。

当这名玩家敲下回车键将指令发送给游戏时，游戏开始对这条指令进行解析并运行：

as子命令让游戏知道，接下来要改变执行者。而目标选择器@e选择了这三个实体，并使得它们按照生成时间的早晚排序，因此游戏根据as @e，先选择了这名玩家作为执行者，然后再选择村民，最后选择羊。

接下来游戏看到了at @e，由于之前已经选择好了执行者，所以游戏根据上文还有这里，得知这名玩家将会依次在玩家的位置、村民的位置和羊的位置分别运行一遍指令，村民和羊同理。

这章没有结束，请点击下一页继续阅读！

最后游戏看到了run以及后面的指令，它已经完全明白接下来要干什么事情了：

①将玩家传送至玩家上方1米的位置（玩家此时抬高了1米）

②将玩家传送至村民上方1米的位置（玩家此时位于村民上方1米）

③将玩家传送至羊上方1米的位置（玩家此时位于羊上方1米）

④将村民传送至玩家上方1米的位置（村民此时位于玩家原本位置上方1米，玩家此时位于羊上方1米）

⑤将村民传送至村民上方1米的位置（村民此时位于村民原本位置上方1米，玩家此时位于羊上方1米）

⑥将村民传送至羊上方1米的位置（村民和玩家此时位于羊上方1米）

⑦将羊传送至玩家上方1米的位置（村民和玩家此时位于羊原本位置上方1米，羊位于玩家原本位置上方1米）

⑧将羊传送至村民上方1米的位置（村民和玩家此时位于羊原本位置上方1米，羊位于村民原本位置上方1米）

⑨将羊传送至羊上方1米的位置（村民、玩家和羊此时都位于羊原本位置上方1米）

最终，三者都跑到了羊原先位置上面1米处，指令运行了3×3=9遍。

太离谱了是不是？但既然写两个@e会造成混乱的话，那么该怎样写呢？

因为第一个as子命令已经更改了执行者，后面的子命令都会按照更改后的来，所以我们只需要：

/execute as @e at @s run tp @s ~~1 ~

将at的@e改为@s即可。

或者说把at放前面，曲线救国一下：

/execute at @e as @e[limit=1，sort=nearest] run tp @s ~~1 ~

这也是可以的。

所以在execute中，各个子命令的顺序十分重要，每个子命令都会影响到后面的子命令。希望你能记住这一点，不然可能会犯一些就像上面这样的严重错误。

我们再来试试结合in和at两个子命令，看看当两个子命令所影响的范围有重合时会发生什么：

/execute at @s in minecraft:the_nether run tp @s ~~~

/execute in minecraft:the_nether at @s run tp @s ~~~

你可以猜一猜，当你运行这两条指令时，效果分别是怎样的？

首先，第一条指令的效果和之前『/execute in minecraft:the_nether run tp @s ~~~』的效果不能说十分相似，只能说是完全一样。at子命令将执行位置和朝向设定为了你的位置和朝向，但由于本来就是这样所以可以去掉。in虽然仅仅会影响到维度，但如果像是地狱这种特殊的维度，在影响到维度位置的同时，in也会对当前的坐标进行设置。所以说是完全一样，并不会说你这样设置可以将你传到地狱而不改变坐标的。

而第二条指令就更不用说了，in刚刚把维度改过去，at又改了回来，所以第二条子命令相当于『/tp @s ~~~』，把自己传送到自己的位置，实际上没有任何效果。

所以说，execute就像是个流水线，指令的三要素从指令开头出发，依次经过各个修饰子命令的洗礼，最终在run子命令『出厂』。采用这种『流水线思维』，我们才能更好地理解更加复杂的execute命令。

本章到此结束。