（Windows 批处理）if 块内的 Goto 行为非常奇怪
如果我获取以下 Windows 批处理代码片段并运行它：
echo foo
if 1 == 1 (
echo bar
goto asdf
:asdf
echo baz
) else (
echo quux
)我期望的输出是：
foo
bar
baz但我得到的是：
foo
bar
baz
quux如果我注释掉 goto asdf 行，它会给出我期望的输出。 echo quux 行不应该被执行，那么为什么 goto 的存在会导致这种情况发生呢？
更新：对于它的价值，这里有一个解决方法，可以正确执行我最初的意图：
goto BEGIN
:doit
echo bar
goto asdf
:asdf
echo baz
goto :EOF
:BEGIN
echo foo
if 1 == 1 (
call :doit
) else (
echo quux
)但是，这并没有回答我原来的问题。
If I take the following Windows batch code snippet and run it:
echo foo
if 1 == 1 (
echo bar
goto asdf
:asdf
echo baz
) else (
echo quux
)The output I would expect is:
foo
bar
bazBut instead I get:
foo
bar
baz
quuxIf I comment out the goto asdf line, it gives the output I expect. The echo quux line should never be exectuted, so why is the existence of the goto causing that to happen?
UPDATE: For what it's worth, here's a workaround that correctly does what I originally intended:
goto BEGIN
:doit
echo bar
goto asdf
:asdf
echo baz
goto :EOF
:BEGIN
echo foo
if 1 == 1 (
call :doit
) else (
echo quux
)However, this doesn't answer my original question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CALL 或 GOTO 的目标决不能位于括号内的块语句内。这是可以做到的，但正如您所看到的，结果可能不会是您想要的。
整个 IF (...) ELSE (...) 构造在处理任何一个之前都会被解析并加载到内存中。换句话说，它在逻辑上被视为一行代码。解析后，CMD.EXE 期望从 IF/ELSE 构造之后的下一行开始恢复解析。
解析阶段之后，从内存中执行复杂的命令。 IF 子句被正确处理，ELSE 子句被正确跳过。但在 IF (true) 子句中，您执行
GOTO :asdf，因此 CMD.EXE dutifly 开始扫描标签。它从 IF/ELSE 末尾开始扫描到文件底部，循环回到顶部，然后扫描直到找到标签。标签恰好位于 IF 子句内，但标签扫描器对此细节一无所知。因此，当复杂命令从内存执行完毕时，批处理将从标签而不是从复杂 IF/ELSE 的末尾恢复。因此，此时批处理器会看到并执行接下来的几行
baz 被回显，quux 也是如此。但您可能会问，“为什么
) else (和/或)不生成语法错误，因为它们现在不平衡，不再作为较大 IF 的一部分进行解析 如果这是因为
)的处理方式，遇到
)时存在打开的(active)，则)按照您的预期进行处理，但是如果解析器期望一个。命令并在没有活动的打开
(时找到)，则忽略)并且该行其余部分的所有字符都将被忽略实际上，)现在充当 REM 语句。The target of a CALL or GOTO should never be inside a block statement within parentheses. It can be done, but as you see, the results are probably not going to be what you want.
The entire IF (...) ELSE (...) construct is parsed and loaded into memory before any of it is processed. In other-words, it is logically treated as one line of code. After it is parsed, CMD.EXE is expecting to resume parsing starting with the next line after the IF/ELSE construct.
After the parse phase, the complex command is executed from memory. The IF clause is processed properly and the ELSE clause is skipped properly. BUT within the IF (true) clause, you perform a
GOTO :asdf, so CMD.EXE dutifly begins scanning for the label. It starts at the end of the IF/ELSE and scans to the bottom of the file, loops back to the top, and scans until it finds the label. The label happens to be within your IF clause, but the label scanner knows nothing about that detail. So when the complex command finishes executing from memory, batch processing resumes from the label instead of from the end of the complex IF/ELSE.So at this point the batch processor sees and executes the next few lines
baz is echoed, and so is quux. But you might ask, "Why doesn't
) else (and/or)generate a syntax error since they are now unbalanced and no longer parsed as part of the larger IF statement?That is because of how
)is handled.If there is an open
(active when)is encountered, then the)is processed as you would expect.But if the parser is expecting a command and finds a
)when there is not an active open(, then the)is ignored and all characters on the remainder of the line are ignored! Effectively the)is now functioning as a REM statement.一组括号内的任何内容都被视为一行，一次处理、解释和执行。您的脚本到达
goto asdf并跳出该块/行。在标签:asdf处，没有括号，因此它开始逐行读取。它到达了else，但:asdf和else之间没有if，因此它会忽略它。为了防止出现此类问题，我总是在
if和for语句上使用goto或call，而不是块。这解决了进一步的 goto 语句的问题，也解决了变量的许多问题。使用
goto：或使用
call：Anything inside a set of brackets is considdered to be a single line, processed, interpreted and executed in one hit. Your script reaches
goto asdfand jumps out of that block/line. At the label:asdf, there is no bracket, so it starts reading lines one by one. It reacheselse, but there's noifbetween:asdfandelseso it ignores it.To prevent issues like this, I always use
gotoorcallonifandforstatements, rather than blocks. This sorts out issues with furthergotostatements and also sorts out a lot of problems with variables too.To use
goto:Or to use
call:在这种情况下，事实证明它与 IF 语句内的循环嵌套和结构不佳有关，正如 https:/ 所清楚解释的那样上面的/stackoverflow.com/users/1012053/dbenham。
也就是说，由于这个问题，我想到了另一个类似的考虑......
请在这里查看以下问题和后续解决方案：
”。此时出乎意料”从批处理脚本行 'if exit [file] (... 生成)
解决方案只是对 '(' 和 ')' 进行处理IF 语句块内的 ECHO 行
FOR）语句进行故障排除时，请考虑将特殊字符视为问题的可能根源。
要点是，在对 IF（可能还有
In this case it turns out to be related to the poor nesting and structure of a loop inside an IF statement, as clearly explained by https://stackoverflow.com/users/1012053/dbenham above.
That said, I figured out another similar consideration due to this problem...
Please take a look a the following problem and subsequent solution here:
". was unexpected at this time" generated from batch script line 'if exist [file] (...
The solution was simply the treatment of '(' and ')' on ECHO lines inside an IF statement block.
The point is, do consider treatment of special characters as a possible source of a problem when troubleshooting IF (and possibly FOR) statements.
HTH