windows 批处理中，单个 cmd.exe 进程设置的环境变量无法跨进程持久化；若需让第二个脚本访问第一个脚本定义的变量，必须确保二者运行于同一 shell 实例或通过宿主程序（如 go）显式传递环境。
windows 批处理中，单个 cmd.exe 进程设置的环境变量无法跨进程持久化；若需让第二个脚本访问第一个脚本定义的变量，必须确保二者运行于同一 shell 实例或通过宿主程序（如 go）显式传递环境。
在 Windows 批处理开发与自动化部署中，一个常见误区是认为 set VAR=value 在第一个 .bat 文件中执行后，该变量会自动“留存”并被后续独立启动的批处理脚本读取（例如 echo %VAR%）。但实际情况是：每个 cmd.exe 实例拥有独立的、仅限生命周期内有效的环境块。当第一个脚本执行完毕、对应的 cmd.exe 进程退出时，其所有 set 设置的变量即被销毁，不会影响系统级环境或新启动的命令行进程。
✅ 正确方案一：在同一 cmd.exe 实例中顺序执行（推荐）
最简单、最可靠的方式是让第一个脚本主动调用第二个脚本，而非由外部（如 Go 程序）分别启动两次 cmd.exe：
:: script1.bat @echo off set NEWPATH=E:Some echo [script1] NEWPATH set to: %NEWPATH% call script2.bat
:: script2.bat @echo off echo [script2] NEWPATH = %NEWPATH%
⚠️ 注意：
- 使用
call而非直接写script2.bat，否则控制权不会返回script1.bat（虽本例无影响，但属最佳实践）；- 不要加引号包裹路径赋值（
set NEWPATH="E:Some"会把双引号作为值的一部分），正确写法为set NEWPATH=E:Some；set定义的是当前会话局部变量，call启动的子脚本会继承父进程环境，因此%NEWPATH%可正常展开。
✅ 正确方案二：由宿主程序（如 Go）统一管理环境
若脚本必须由外部程序（如 Go 服务）独立调度（例如因权限、路径隔离或安全策略限制无法修改脚本内容），则不能依赖批处理自身机制，而应由 Go 主动捕获并注入环境：
// Go 示例：安全地传递变量给第二个脚本
cmd1 := exec.Command("cmd.exe", "/c", "script1.bat")
var out1 bytes.Buffer
cmd1.Stdout = &out1
if err := cmd1.Run(); err != nil {
log.Fatal(err)
}
// 解析 script1.bat 输出中的 key=value 行（需脚本配合输出）
envMap := parseEnvOutput(out1.String()) // 自定义解析函数
envMap["NEWPATH"] = "E:\Some" // 或从 stdout 提取
// 构造新环境：继承当前进程环境 + 注入变量
env := os.Environ()
for k, v := range envMap {
env = append(env, fmt.Sprintf("%s=%s", k, v))
}
cmd2 := exec.Command("cmd.exe", "/c", "script2.bat")
cmd2.Env = env
cmd2.Stdout = os.Stdout
cmd2.Run()
? 提示：若无法修改
script1.bat添加echo NEWPATH=%NEWPATH%，可改用 管道复用同一 cmd.exe 实例（高级技巧）：
Go 启动cmd.exe /c并保持 stdin 开放 → 先写入script1.bat全部内容 →Flush()→ 再写入script2.bat内容 → 关闭 stdin。两个脚本将在同一个 shell 中顺序执行，共享全部环境变量。
❌ 常见错误与规避
-
setx NEWPATH "E:Some"是系统/用户级永久设置，需重启 cmd 才生效，且存在权限和作用域风险（不推荐用于临时流程）； - 在 Go 中调用
os.Setenv()后再执行exec.Command，仅对后续启动的子进程有效，但无法影响已退出的script1.bat； - 混淆
set（会话级）与setx（注册表级）——二者语义完全不同，切勿混用。
总之，跨脚本共享变量的本质是维持环境上下文的连续性。优先采用 call 链式调用；若架构强制分离，则务必由宿主程序承担环境协调职责，而非寄望于批处理自身的“记忆能力”。
