go env 命令可导出全部生效的 Go 环境变量，生成带日期的备份文件（如 go-env-backup-20260723.txt），包含 GOROOT、GOPATH、GOPROXY、GO111MODULE 等关键项；但 PATH 和 VS Code 的 gopls 配置需单独备份，还原后须用 go version、go env、go list -m 交叉验证。
go env 输出结果就是最简备份
你不需要手动记一堆环境变量，go env 命令本身就能导出当前所有生效的 Go 环境配置。它比你手写的笔记更准，也比截图更可靠——因为有些变量（比如 GOPROXY、GO111MODULE）是运行时生效的，可能和系统环境变量不一致。
执行以下命令即可保存当前状态：
go env > go-env-backup-$(date +%Y%m%d).txt
这会生成一个带日期的文本文件，内容包含 GOROOT、GOPATH、GOBIN、GOPROXY、GO111MODULE 等全部关键项。重装系统或换机器时，你可以对照这个文件逐条还原。
PATH 和 shell 配置文件必须单独备份
go env 不会告诉你 go 命令是怎么被找到的——那是 PATH 的事。而 PATH 来自你的 shell 配置文件，这部分必须手动备份，否则即使还原了 go env 里的变量，go 命令也可能找不到。
立即学习“go语言免费学习笔记（深入）”；
- macOS / Linux：检查并备份
~/.zshrc、~/.bash_profile或~/.profile中跟 Go 相关的行（通常含GOROOT、GOPATH、PATH=...） - Windows：导出系统环境变量（用 PowerShell）：
Get-ChildItem Env: | Where-Object Name -match '^(GO|GOROOT|GOPATH|PATH)$' | Export-Csv go-env-vars.csv -NoTypeInformation
- 别只信“安装器勾选了添加到 PATH”——重启终端后
which go（macOS/Linux）或Get-Command go（Windows）没输出，说明 PATH 没真生效
VS Code 的 gopls 配置容易被忽略
编辑器层面的配置不会出现在 go env 里，但一旦丢失，gopls 就可能启动失败，表现为代码无提示、跳转失效、保存不自动格式化。
需要备份的 VS Code 设置项包括：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
"go.goroot"（如果显式指定过） -
"go.gopath"（仅旧项目或特殊工作流才需） -
"go.useLanguageServer": true（必须开启） - 工作区级别的
.vscode/settings.json（尤其当项目有定制化gofmt或golint参数时）
注意：gopls 依赖项目根目录下存在 go.mod 且 go 命令可用——备份配置后，若新开项目没运行 go mod init，这些设置也不会生效。
代理和模块开关属于“静默失效型”配置
GO111MODULE 和 GOPROXY 是典型“改了不报错、但行为大变”的配置。比如：
-
GO111MODULE=off时，go mod init会静默失败或生成错误 module 名 -
GOPROXY=""（空值）会导致国内用户go get卡住十几分钟甚至超时，但命令本身不报错
所以备份时不能只看是否设置了，还要确认值是否合理：
推荐用这两条命令验证并记录实际值：
go env GO111MODULE<br>go env GOPROXY
常见合理值：on、https://goproxy.cn,direct 或 https://mirrors.aliyun.com/goproxy/,direct。如果输出是空或 auto，就说明没设稳，得补上 go env -w GO111MODULE=on。
真正麻烦的不是备份动作本身，而是还原时漏掉某个看似无关的配置——比如 PATH 没恢复导致 go 找不到，或者 GOPROXY 被清空导致依赖拉不下来。每次还原后，务必跑一遍 go version、go env、go list -m（在任意模块目录下）来交叉验证。
