CMD中嵌套pushd未被popd正常恢复，此现象是否为Bug？

结论 #

这不是Bug，完全是Windows批处理中setlocal、pushd/popd的工作机制导致的预期行为。

成因拆解 #

1. setlocal的作用边界 #

setlocal的核心是隔离当前脚本上下文内的环境变量与进程工作目录变更，但它不会干预系统目录栈——而pushd和popd操作的正是这个全局的系统目录栈，栈的状态不受setlocal/endlocal的影响。

2. 原场景的执行流程 #

我们一步步拆解原脚本的执行逻辑：

1. 初始状态：当前目录为C:\ex1，目录栈为空。
2. start.bat执行pushd 111：
   • 将当前目录C:\ex1压入目录栈（栈内容：[C:\ex1]）
   • 当前目录切换至C:\ex1\111
3. 调用1.bat：
   • 1.bat启动时，当前目录为C:\ex1\111
   • 执行setlocal开启本地环境上下文
   • 执行pushd 222：
     • 将当前目录C:\ex1\111压入目录栈（栈内容：[C:\ex1, C:\ex1\111]）
     • 当前目录切换至C:\ex1\111\222
   • 输出目录信息后，1.bat执行结束，自动触发endlocal：
     • 恢复当前目录至setlocal执行前的状态（C:\ex1\111）
     • 目录栈的状态完全保留，仍为[C:\ex1, C:\ex1\111]
4. 回到start.bat执行popd：
   • 弹出目录栈最顶层的C:\ex1\111
   • 当前目录切换至该弹出的目录（C:\ex1\111），这就是你看到的"错误"结果。

3. 为什么修改为cd或直接调用脚本正常？ #

• 用cd 111替代pushd 111：cd仅修改当前进程的工作目录，不操作目录栈。1.bat执行完endlocal后，当前目录回到C:\ex1\111，后续可通过cd ..回到C:\ex1，不会被目录栈的状态干扰。
• 直接call 111\1.bat：start.bat的当前目录始终是C:\ex1，1.bat执行endlocal后会自动恢复到C:\ex1，自然符合预期。

修复方案 #

只需在1.bat中为pushd配对添加popd，保证目录栈的操作对称：

@echo off
setlocal
pushd 222
echo 1.bat says we are in %cd%
popd  // 新增该行，弹出pushd压入的目录

这样1.bat执行完毕后，目录栈会回到调用前的状态，start.bat里的popd就能正确弹出最初压入的C:\ex1，当前目录恢复正常。

内容的提问来源于stack exchange，提问作者Badr Elmers