脚本必须正确配置GOROOT、GOPATH、PATH三变量并校验：GOROOT需指向存在可执行go的bin目录，GOPATH须用$HOME/go并初始化src/bin/pkg，PATH要前置两者bin；GO111MODULE=on和GOPROXY=https://goproxy.cn,direct为默认值，且脚本须提示source执行。
脚本必须处理的三个硬性路径变量
Go环境能跑起来，GOROOT、GOPATH、PATH 这三个变量缺一不可，且顺序和写法稍错就会导致 go version 找不到命令或 go run 报 cannot find module。脚本不能只“设值”，得做校验：
-
GOROOT必须指向真实存在的bin/go文件，否则go命令根本无法执行；脚本里应加[ -x "$GOROOT/bin/go" ]检查可执行权限 -
GOPATH不建议硬写成~/go—— 波浪线在某些 shell（如 dash）中不展开，要用$HOME/go；同时需mkdir -p "$GOPATH/{src,bin,pkg}"初始化目录结构 -
PATH中$GOROOT/bin和$GOPATH/bin都要前置插入，否则系统自带的老版本go可能被优先命中；推荐写法：export PATH="$GOROOT/bin:$GOPATH/bin:$PATH"
GO111MODULE 和 GOPROXY 必须默认开启
Go 1.16+ 默认启用模块模式，但旧系统或 Docker 容器里仍可能 fallback 到 GOPATH 模式，导致依赖拉取失败或 go mod download 卡住。脚本里这两项不能靠用户手动补：
-
GO111MODULE=on是底线，否则go build在非module目录下会报错或行为异常 -
GOPROXY=https://proxy.golang.org,direct要作为默认值；国内用户可加判断：if curl -sfI https://goproxy.cn >/dev/null 2>&1; then export GOPROXY=https://goproxy.cn; fi - 注意：设置
GOPROXY后，GOINSECURE通常不需要——除非你用私有仓库且没配 TLS，否则反而干扰公共模块下载
脚本生效方式决定是否需要重载 shell
直接运行 ./setup_go_env.sh 不会让当前终端生效，因为子 shell 的环境变量无法回传。常见错误是用户执行完脚本就去敲 go version，结果还是报 command not found：
- 正确做法是用
source ./setup_go_env.sh或. ./setup_go_env.sh—— 脚本开头应加提示：“请用 source 命令执行本脚本” - 若想永久生效，脚本末尾可自动追加到
$HOME/.bashrc或$HOME/.zshrc，但必须先检测是否已存在重复行，避免每次source都叠加 PATH - 别忘了提醒用户：改完配置文件后，新开终端或执行
exec "$SHELL"才能全局生效
多版本切换不是“锦上添花”，而是现实刚需
团队协作或维护老项目时，经常要切 Go 1.19、1.21、1.23 —— 光靠一个 GOROOT 不够。简单脚本能支持版本切换，关键不在复杂度，而在路径隔离：
立即学习“go语言免费学习笔记（深入）”；
- 把不同版本解压到独立目录，比如
/opt/go-1.21、/opt/go-1.23，而不是覆盖/usr/local/go - 切换脚本只需改软链接：
sudo ln -sf /opt/go-1.23 /usr/local/go，再重新导出GOROOT - 更轻量的做法是定义函数：
go121() { export GOROOT=/opt/go-1.21; export PATH="$GOROOT/bin:$PATH"; }，用户直接调用函数即可，无需 sudo 权限
~ 展开、[[ 条件判断、数组语法在 dash、bash、zsh 里表现不同。最稳妥的方式是用 POSIX shell 写核心逻辑，再用 #!/bin/sh 开头，别轻易用 bashism。 
