PowerShell中go env -w失效是因执行策略限制和环境变量作用域不匹配：需先以管理员权限运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，再在$PROFILE中手动添加[System.Environment]::SetEnvironmentVariable("GOBIN", "$HOME\go\bin", "User")并重启终端验证。
go env -w 设置在 PowerShell 中失效怎么办
PowerShell 的执行策略（Execution Policy）默认禁止脚本修改环境变量，go env -w 看似成功执行，但重启后 GOBIN 或 GOPATH 仍为空——这不是 Go 的 bug，而是 PowerShell 拒绝持久化写入当前会话外的环境作用域。
- 先运行
Get-ExecutionPolicy，若返回Restricted，必须用管理员权限启动 PowerShell，再执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -
go env -w只写入用户级环境变量注册表项（HKEY_CURRENT_USER\Environment），但 PowerShell 启动时未必自动加载该路径；需手动在$PROFILE中追加[System.Environment]::SetEnvironmentVariable("GOBIN", "$HOME\go\bin", "User") - 验证是否生效：关闭所有终端，新开 PowerShell，运行
go env GOPATH和echo $env:GOBIN，二者必须一致且非空
Chocolatey 安装 Go 后 GOPATH 目录结构不完整
Chocolatey 装的是二进制包，它只配置 GOROOT 和 PATH，但不会创建 $HOME\go\src、bin、pkg 这三个经典子目录——而某些老项目或 CI 脚本仍会硬依赖这些路径存在，导致 go build 报错 cannot find package。
- 手动补全：运行
mkdir $HOME\go\src, $HOME\go\bin, $HOME\go\pkg（PowerShell 语法） - 别跳过
$HOME\go\bin：即使你用模块模式，go install默认仍往这里写可执行文件，缺失会导致命令找不到 - Windows Defender 有时会拦截
go.exe首次运行，弹窗允许后才真正解压工具链；若go version卡住或报“access denied”，检查 Defender 历史记录
go mod init 后 go run 仍提示 cannot find main module
这不是环境变量问题，而是当前目录不在模块根目录下——go run 要求工作目录必须包含 go.mod 文件，且该文件不能是上级目录的子模块的一部分。常见于 VS Code 终端未正确切换到项目根，或用资源管理器双击打开 .go 文件导致终端定位错误。
- 确认方式：运行
go list -m，若输出main或报错not in a module，说明当前目录没被识别为模块根 - 修复动作：cd 到含
go.mod的目录再执行go run；不要在src/xxx/子目录里直接跑 - VS Code 用户注意：
Ctrl+Shift+P → Shell Command: Install 'code' command in PATH必须执行，否则集成终端可能继承错误的父进程工作目录
多个 Go 版本共存时如何避免 PATH 冲突
用 Chocolatey 装了 go1.21，又手动解压了 go1.22，两者 bin 目录都加进了 PATH，但系统总调用旧版本——因为 Windows 按 PATH 顺序匹配，前面的优先。
立即学习“go语言免费学习笔记（深入）”；
- 查清实际调用路径：运行
Get-Command go | Select-Object -ExpandProperty Path，看它指向哪个安装位置 - 删掉冗余 PATH 条目：在系统环境变量中只保留一个 Go
bin目录（推荐 Chocolatey 管理的那个），其余用go install golang.org/dl/go1.22@latest+go1.22 version显式调用 - 模块兼容性陷阱：
go.mod顶部的go 1.21是最低要求，不是锁定版本；但若用了1.22特有语法（如~版本修饰符），在1.21下会直接编译失败
go env 输出和 go list -m 结果——尤其当你的代码要交给别人或跑进 CI，这些看似琐碎的检查，才是阻断“在我机器上能跑”式故障的真正防线。 
