考虑以下批处理文件test.bat（PC01已关闭）：
mkdir \\PC01\\c$\Test || goto :eof
如果我在命令行窗口中运行那个批处理文件：
> test.bat || echo 99
> if ERRORLEVEL 1 echo 55
输出仅为55，没有99。存在一个错误级别，但是|| 运算符没有检测到它。
如果我使用 cmd /c - 运行该批处理文件
> cmd /c test.bat || echo 99
> if ERRORLEVEL 1 echo 55
输出为空白。Errorlevel为0。
如果我移除 || goto :eof，所有内容都将按预期工作 — 即输出将会是:
99 55
有人知道为什么会发生这种半烤不熟的ERRORLEVEL行为吗？
||是检测错误最可靠的方法。但是你遇到了一种罕见的情况，其中ERRORLEVEL有效但||无效。||响应于最近执行命令的返回代码。你认为test.bat是一个单独的"命令"，但实际上它是一系列命令。脚本中执行的最后一个命令是GOTO :EOF，并且执行成功。因此，你的test.bat || echo 99响应于GOTO :EOF的成功。||GOTO :EOF时，那么你的test.bat || echo99会看到失败的mkdir结果。但是，如果你在test.bat的末尾添加一个REM命令，那么test.bat || echo 99将响应于REM的成功，并且错误将再次被掩盖。
test.bat || echo 99之后，ERRORLEVEL仍然不为零，因为像GOTO和REM这样的命令在成功时不会清除任何先前非零的ERRORLEVEL。这是ERRORLEVEL和返回代码并不完全相同的证据之一。这肯定会让人感到困惑。C:\test>call test.bat && echo OK || echo FAIL
FAIL
C:\test>if ERRORLEVEL 1 (echo FAIL2) else echo OK2
FAIL2
CALL命令会临时将控制权转移到所调用的脚本。当脚本终止时，控制权会返回到CALL命令，并返回当前的ERRORLEVEL。因此，||echo 99响应的是CALL命令本身返回的错误，而不是脚本中最后一个命令的错误。CMD /C的问题。
CMD /C返回的代码是执行的最后一个命令的返回代码。C:\test>cmd /c call test.bat && echo OK || echo FAIL
FAIL
C:\test>if ERRORLEVEL 1 (echo FAIL2) else echo OK2
FAIL2
因为CMD /C返回CALL语句返回的ERRORLEVEL。
但这种方法完全失败：
C:\test>cmd /c test.bat && echo OK || echo FAIL
OK
C:\test>if ERRORLEVEL 1 (echo FAIL2) else echo OK2
OK2
CALL时，CMD /C返回最后一个执行命令的返回代码，即GOTO :EOF。 CMD /C还将ERRORLEVEL设置为相同的返回代码，因此现在没有证据表明脚本中曾经出现过错误。||有时会清除ERRORLEVEL。他提供了似乎支持他结论的证据。但情况并不那么简单，事实证明，||是检测错误最可靠（但仍不完美）的方法。help exit或exit /?）。EXIT [/B] [exitCode]
/B specifies to exit the current batch script instead of
CMD.EXE. If executed from outside a batch script, it
will quit CMD.EXE
exitCode specifies a numeric number. if /B is specified, sets
ERRORLEVEL that number. If quitting CMD.EXE, sets the process
exit code with that number.
C:\test>(call ) & set /a 1/0
Divide by zero error.
C:\test>echo !errorlevel!
1073750993
C:\test>(call ) & type notExists
The system cannot find the file specified.
C:\test>echo !errorlevel!
1
C:\test>(call ) & set /a 1/0 && echo OK || echo ERROR !errorlevel!
Divide by zero error.
ERROR 1073750993
C:\test>(call ) & type notExists.txt && echo OK || echo ERROR !errorlevel!
The system cannot find the file specified.
ERROR 1
那么至少有一个命令RD（可能还有其他），以及重定向运算符，当出现错误时触发||，但不会设置ERRORLEVEL，除非使用||。
C:\test>(call ) & rd notExists
The system cannot find the file specified.
C:\test>echo !errorlevel!
0
C:\test>(call ) & echo x >\badPath\out.txt
The system cannot find the path specified.
C:\test>echo !errorlevel!
0
C:\test>(call ) & rd notExists && echo OK || echo ERROR !errorlevel!
The system cannot find the file specified.
ERROR 2
C:\test>(call ) & echo x >\badPath\out.txt && echo OK || echo ERROR !errorlevel!
The system cannot find the path specified.
ERROR 1
||，也不会设置非零的ERRORLEVEL。||或将ERRORLEVEL设为非零。C:\test>(call ) & del readOnlyFile
C:\test\readOnlyFile
Access is denied.
C:\test>echo !errorlevel!
0
C:\test>(call ) & del readOnlyFile & echo OK || echo ERROR !errorlevel!
C:\test\readOnlyFile
Access is denied.
OK
||不会触发，ERRORLEVEL也不会被设置为非零。请参见http://www.dostips.com/forum/viewtopic.php?f=3&t=6881以获取更多信息。CALL，||运算符将响应脚本内执行的最后一个命令。使用CALL，||运算符将响应CALL命令返回的值，这是批处理终止时存在的最终ERRORLEVEL。||，则报告为ERRORLEVEL 1。C:\test>(call ) & InvalidCommand
'InvalidCommand' is not recognized as an internal or external command,
operable program or batch file.
C:\test>echo !errorlevel!
9009
C:\test>(call ) & InvalidCommand && echo OK || echo ERROR !errorlevel!
'InvalidCommand' is not recognized as an internal or external command,
operable program or batch file.
ERROR 1
我不能证明这一点，但我怀疑在命令执行过程中，命令失败的检测和ERRORLEVEL设置为9009发生得非常晚。我猜想，||在9009被设定之前拦截了错误检测，并将其设置为1。所以我认为||并没有清除9009的错误，而是另一种处理和设置错误的替代路径。
这种行为的另一种机制是：无效的命令始终将ERRORLEVEL设置为9009，但返回代码不同为1。随后，||可以检测到1的返回代码并设置ERRORLEVEL以匹配，从而覆盖9009。
不管怎样，我不知道有任何其他情况，其中非零ERRORLEVEL结果因是否使用||而不同。
这就解决了命令失败时会发生什么。但是当内部命令成功时呢？不幸的是，CMD.EXE甚至比错误更不一致。它因命令而异，还可能取决于它是从命令提示符、带有.bat扩展名的批处理脚本还是从带有.cmd扩展名的批处理脚本中执行。
以下所有讨论都基于Windows 10的行为。我怀疑在使用cmd.exe的早期Windows版本中存在差异，但这是可能的。
以下命令始终在成功时将ERRORLEVEL清除为0，而不考虑上下文：
call echo OK下一组命令在成功时永远不会将ERRORLEVEL清除为0，而是保留任何现有的非零值ERRORLEVEL：
EXIT /B 0 可以清除ERRORLEVEL，但是没有值的EXIT /B会保留之前的ERRORLEVEL。此外，这些命令在从带有.cmd扩展名的脚本中调用时，不会清除ERRORLEVEL，但是如果从带有.bat扩展名的脚本或命令行中调用，则会将ERRORLEVEL清除为0。详情请参考https://dev59.com/43VC5IYBdhLWcg3w51ny#148991和https://groups.google.com/forum/#!msg/microsoft.public.win2000.cmdprompt.admin/XHeUq8oe2wk/LIEViGNmkK0J。
无论ERRORLEVEL的值如何，&&操作符都会检测前一个命令是否成功，并且只有在成功时才执行后续命令。 &&操作符忽略ERRORLEVEL的值，永远不会修改它。
以下是两个示例，演示了&&始终在前一个命令成功时触发，即使ERRORLEVEL为非零值。 CD命令是一个清除任何先前ERRORLEVEL的示例，而ECHO命令是一个不清除先前ERRORLEVEL的示例。 注意，我使用(call)强制将ERRORLEVEL设置为1，然后才执行成功的命令。
C:\TEST>(call)
C:\TEST>echo !errorlevel!
1
C:\test>(call) & cd \test
C:\test>echo !errorlevel!
0
C:\test>(call) & cd \test && echo OK !errorlevel! || echo ERROR !errorlevel!
OK 0
C:\test>(call) & echo Successful command
Successful command
C:\test>echo !errorlevel!
1
C:\test>(call) & echo Successful command && echo OK !errorlevel! || echo ERROR !errorlevel!
Successful command
OK 1
在我所有关于错误检测的代码示例中，我都依赖于ECHO从不清除先前存在的非零ERRORLEVEL的事实。但是下面的脚本就是一个例子，说明当在&&或||之后使用其他命令时可能会发生什么。
@echo off
setlocal enableDelayedExpansion
(call)
echo ERRORLEVEL = !errorlevel!
(call) && echo OK !errorlevel! || echo ERROR !errorlevel!
(call) && (echo OK !errorlevel! & set "err=0") || (echo ERROR !errorlevel! & set "err=1" & echo ERROR !errorlevel!)
echo ERRORLEVEL = !errorlevel!
echo ERR = !ERR!
.bat时的输出结果：C:\test>test.bat
ERRORLEVEL = 1
ERROR 1
ERROR 1
ERROR 1
ERRORLEVEL = 1
ERR = 1
当脚本的扩展名为.cmd时，以下是输出结果：
C:\test>test.cmd
ERRORLEVEL = 1
ERROR 1
ERROR 1
ERROR 0
ERRORLEVEL = 0
ERR = 1
&&和||是检测命令成功或失败最可靠的方式，如果您关心ERRORLEVEL值，那么在这些运算符后使用哪些命令就需要小心了。&&和||是检测成功和失败最可靠的方法。&&和||都不会直接修改ERRORLEVEL。但是有一些罕见的例外情况。
||会正确设置ERRORLEVEL，否则RD或重定向失败时可能会错过该值。||在无效命令执行失败时设置不同的ERRORLEVEL，然后如果未使用||，则会发生(1 vs. 9009)。||不会将批处理脚本返回的非零ERRORLEVEL作为错误检测，除非使用CALL命令。if errorlevel 1 ...或if %errorlevel% neq 0 ...来检测错误，那么您可能会错过RD和重定向（等等）可能引发的错误，并且您也可能会错误地认为某些内部命令失败了，而实际上它可能是先前命令失败的遗留问题。要为批处理文件构建一种解决方案，以在使用goto:eof时设置返回代码，您可以稍微更改脚本。
mkdir \\\failure || goto :EXIT
echo Only on Success
exit /b
:exit
(call)
test.bat || echo Failed
唯一的缺点在于丢失错误级别。
在这种情况下，返回代码设置为false，但错误级别始终设置为1，由于无效的(call)
目前我没有找到任何可能的方法来同时设置错误级别和返回代码为用户定义的值。
||在没有CALL的批处理脚本中的响应方式。它让我重新发现了||在没有CALL的情况下响应于脚本中最后执行的命令。这是我以前知道但已经忘记的事情。我已经编辑了我的答案，以正确解释使用CALL和不使用CALL之间的区别。 - dbenhammkdir \\PC01\c$\Test
if "%errorlevel%" == "0" (
echo success
) else (
echo failure
)
编辑：
如果前面的命令不是单个命令，则需要执行更多操作以跟踪错误级别。例如，如果您调用一个脚本，则必须在该脚本中管理将错误级别传递回此代码。
编辑2：
以下是错误级别应为“9009”且其输出的测试场景。
1）无故障管道，使用if逻辑。
setlocal enableDelayedExpansion
mybad.exe
if "!errorlevel!" == "0" (
echo success !errorlevel!
) else (
echo Errorlevel is now !errorlevel!
echo Errorlevel is now !errorlevel!
)
setlocal enableDelayedExpansion
mybad.exe || echo Errorlevel is now !errorlevel!
echo Errorlevel is now !errorlevel!
'mybad.exe'不被视为内部或外部命令、可操作的程序或批处理文件。
错误级别现在为1
错误级别现在为1
3) 失败管道，跳转
setlocal enableDelayedExpansion
mybad.exe || goto :fail
exit
:fail
echo Errorlevel is now !errorlevel!
'mybad.exe' 不被识别为内部或外部命令，可执行程序或批处理文件。
错误等级现在为1
所以如果你只关心"某个东西"失败了，那么好吧。代码1跟其他任何代码一样好。但是如果你需要知道"什么"失败了，那么你不能只是简单地将失败的结果输出并让它覆盖实际结果。
||不会清除ERRORLEVEL，GOTO :EOF也不会。修改后的代码也无法解决问题。 - dbenham
<failed command> || echo %errorlevel%然后下一行echo %errorlevel%，第一个与第二个不同。 - RLHfor /F命令在解析的文件/字符串/命令输出为空的情况下将退出代码设置为非零值，但在这种情况下它不会设置ErrorLevel。这再次证明了退出代码和ErrorLevel是两个不同的概念。 - aschipfl