Windows pushd在扩展延迟的批处理文件中不工作

我在这里和其他网站上阅读了许多关于pushd的问题和答案，其中绝大多数都涉及UNC路径问题。然而，我有一个不同的问题，我没有看到任何提示

使用Windows 10 x64 Enterprise（版本1809），我正在控制台窗口中执行以下批处理文件：

@echo off
setLocal EnableDelayedExpansion
set DestDir=c:\windows
pushd %DestDir%

我的问题是

pushd

似乎以错误的方式执行，或者根本没有执行。这意味着运行批处理文件时，我不在

c:\windows

中，但仍在运行批处理文件之前所在的目录中

为了理解这个问题，我尝试了几种方法（知道这些测试没有意义）：

• 将

  c:\windows

  放在引号中（

  set DestDir=“c:\windows”

  ）
• 将

  %DestDir%

  放在引号中（

  pushd“%DestDir%”

  ）
• 使用
  而不是

  %

  ，因为延迟扩展已打开，即

  pushd“！DestDir！”

• 启动控制台窗口我以管理员身份从中运行批处理文件

但是，当我不启用延迟扩展时，

pushd

会按预期工作。换句话说，在运行以下批处理文件之后

@echo off
set DestDir=c:\windows
pushd %DestDir%

在运行批处理文件之前，无论我所在的目录如何，我确实已经被传送到了c:\windows中

---

我想我现在很傻，但我一辈子都不能对这件事耿耿于怀。那么，有谁能解释一下，如果延迟扩展处于活动状态，为什么pushd会失败？

您的问题的原因已经在评论中讨论过了，但到目前为止还没有解决方案。
您可以通过显式的

endlocal

解决此问题：

REM @echo off
setLocal EnableDelayedExpansion
set DestDir=c:\windows
endlocal & pushd %DestDir%

---

最后一行是一次性解析的，因此在执行整行之前（在

endlocal

上运行

echo查看），将
%DestDir%
替换为它的值。
解释很简单（但不是直观的）：如果你有
setlocal
，脚本结束时会有一个隐式
endlocal
，这也意味着，有一个
popd
@Stephan:不完全是。。。每个
endlocal
都会还原上一个
setlocal
保存的目录，就像当前目录是环境变量一样！看见同样的行为也发生在
cd
@Stephan谢谢，我没想到。但问题是批处理文件中的目录也没有更改。老实说，这实际上是我的问题（批处理文件的某些代码依赖于位于正确的目录中，并且当前失败）。我将调查您提到的行为是否会以某种方式发生在批处理文件中。除了@Aacinis提示之外，还需要指出的是，在恢复上一个dir时，pushd堆栈不会受到影响。在提示符下查看
$+
，或在没有参数的情况下发布pushd。@Stephan我已经调查过了，你是对的！这是一个很好的例子，为什么过度简化实际问题可能会引入新问题。我已经插入了一些
echo%CD%
，并且看到
pushd
似乎可以工作。我现在必须调查为什么依赖于某个目录的代码失败了。如果你把你的评论作为回答，我会接受的。