PowerShell执行策略默认限制导致go env -w失效，需先运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser并重启终端，否则profile中环境变量加载被静默忽略。
PowerShell执行策略不改，go env -w设置就失效
很多用户在PowerShell里执行go env -w GOPATH=C:\mygo后，新开窗口一查还是旧值——根本不是命令写错了，而是PowerShell默认禁止运行本地脚本。它会静默忽略profile里的环境变量加载逻辑。
必须先运行：Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，再重启PowerShell。别用Administrator权限运行，否则go install生成的二进制可能被Windows Defender拦截。
- 验证是否生效：执行
Get-ExecutionPolicy -Scope CurrentUser，输出应为RemoteSigned - 别碰
MachinePolicy或Process作用域，容易引发公司IT策略冲突 - Chocolatey安装Go后，它的
choco profile脚本依赖这个策略才能注入PATH
GOROOT和GOPATH路径含空格或中文，go build直接报exec: "gcc": executable file not found
这不是缺GCC，是Go工具链在解析路径时遇到空格就截断了。哪怕你装的是MSVC，错误信息也会误导你去装MinGW。
标准做法是：把Go安装到C:\Go（不要C:\Program Files\Go），把GOPATH设为C:\Users\YourName\go（别用OneDrive同步目录，go mod download会因文件锁失败）。
立即学习“go语言免费学习笔记（深入）”；
- 检查方式：
go env GOROOT GOPATH，两者的输出路径里不能出现 - 如果已装在带空格路径，重装比改注册表更可靠；
go install生成的.exe文件名里若含空格，某些CLI工具（如subfinder）会拒绝执行 - WSL2用户注意：
/mnt/c/...路径下的Go项目，go run可能因跨文件系统权限失败，优先用原生Windows终端
GO111MODULE=on没开，go get装工具总卡在cannot find module providing package
Go 1.16之后默认启用module，但PowerShell里go env显示GO111MODULE=""，说明没显式开启。这时候go get github.com/projectdiscovery/subfinder/v2/cmd/subfinder会尝试在GOPATH/src找包，而新工具早已不维护src结构。
执行：go env -w GO111MODULE=on，然后确认go env | findstr GO111MODULE输出是GO111MODULE="on"。
- 别信
go mod init能自动开启——它只对当前目录生效，全局工具安装必须靠GO111MODULE=on - VS Code调试时如果报
no Go files in workspace，八成是这个开关没开，导致gopls找不到模块根 - 某些老旧CI脚本硬编码
GO111MODULE=auto，在干净环境里会退化到GOPATH模式，务必检查流水线配置
go install生成的二进制被Windows Defender误杀
从GitHub直接go install的工具（比如dlv、subfinder），签名状态是“未签名”，Defender可能在后台静默隔离%USERPROFILE%\go\bin\*.exe，导致命令行里能which dlv但执行时报access is denied。
临时方案：Set-MpPreference -ExclusionPath "$env:USERPROFILE\go\bin"。长期建议把go\bin加进Defender排除列表，而不是关掉实时防护。
- 验证是否被隔离：打开Windows安全中心 → “病毒和威胁防护” → “保护历史记录”，筛选“阻止”项
- Chocolatey装的Go本身不受影响，但
go install产物独立于Choco管理范围 - 企业环境若禁用
Set-MpPreference，需联系IT申请将go\bin路径加入白名单，别试图给每个.exe单独提交哈希
go version能不能跑出来，而是那些不报错、不提示、只悄悄失效的环节——PowerShell策略、路径空格、module开关、Defender拦截，四者叠加起来，足以让一个熟练开发者花半天时间反复重装。 
