go1.21.0安装后需显式调用如go1.21.0 version，不覆盖默认go命令；模块命令行为一致，但实际解析受当前go版本与go.mod中go指令共同影响；WASM构建依赖Go版本，建议固定版本并声明；go run只使用PATH中首个go，无项目级自动版本绑定。
go install golang.org/dl/go1.21.0@latest 装完不生效？
装完 go1.21.0 工具链后，go version 还是显示旧版本，不是安装失败，而是没调用它。
-
go1.21.0是独立二进制，名字带版本号，不会覆盖go命令本身 - 必须显式调用，比如
go1.21.0 version或go1.21.0 build - 想临时切换全局默认，可把
$(go env GOROOT)/bin换成对应工具链的bin/目录（但不推荐长期这么干） - 常见误操作：装完就跑
go version—— 它查的是PATH里第一个go，和你刚装的go1.21.0无关
go mod init 和 go mod tidy 在多版本下行为一致吗？
一致。模块命令本身不依赖 Go 工具链版本，但实际解析和构建行为受当前 go 命令版本影响。
-
go mod init只生成空go.mod，写入module名和默认go 1.x版本（通常是当前go的主版本） -
go mod tidy会按go.mod里声明的go行（如go 1.21）决定 module 兼容性规则，比如是否允许使用泛型、~版本语法等 - 如果用
go1.20.0执行tidy，但go.mod写着go 1.21，会报错：go 1.21 requires go >= 1.21 - 结论：命令能跑，但语义由当前运行的
go二进制和go.mod中的go指令共同决定
GOOS=js GOARCH=wasm go build 失败，和 Go 版本有关吗？
有关。WASM 支持不是“一直有”，而是从 go 1.11 实验性引入，go 1.16 起才稳定，且不同版本对 syscall/js API 有 Breaking Change。
-
go 1.15及更早：不支持GOOS=js GOARCH=wasm直接构建可执行文件（会报build constraints exclude all Go files） -
go 1.16–1.19：支持，但syscall/js的FuncOf、Wrap等函数签名在go 1.20被重命名，老代码会编译失败 - 检查方式：运行
go version后，再查go doc syscall/js输出是否含FuncOf或Wrap—— 如果只有FuncOf，说明是go < 1.20；如果只有Wrap，则是>= 1.20 - 建议：WASM 项目固定一个 Go 版本（如
go 1.21），并在go.mod显式声明go 1.21
go run main.go 自动选哪个 Go 版本？
只看当前 shell 环境中 PATH 找到的第一个 go，和 go.mod 无关，也和 golang.org/dl/ 装的其他版本无关。
立即学习“go语言免费学习笔记（深入）”；
-
go run不读go.mod里的go行来决定用哪个工具链 —— 它只是普通命令行调用 - 唯一例外：用
go1.21.0 run main.go，这时明确指定了工具链 - 想让项目自动匹配版本？得靠外部工具，比如
asdf、gvm或 shell 的direnv+GOROOT切换，Go 自身不提供“项目级版本绑定”机制 - 容易被忽略的点：CI 脚本里写
go run，但 runner 预装的是go 1.19，而本地开发用go 1.21，结果go.sum哈希不一致或泛型报错
