Go 重装后仍报 toolchain not available：检查持久化 GOTOOLCHAIN

macOS 已安装 Go，连 go version 都开始下载 go1.22，随后报 toolchain not available；重装安装目录也没有改善。应检查工具链选择配置，尤其是通过 go env -w 保存的 GOTOOLCHAIN。它存放在用户配置中，重装 Go 二进制不会自动清除。

下面针对 Go 1.21 起的工具链选择机制。go1.22 是语言版本对应的写法，却不是正式发布的标准工具链名称；Go 1.22 的初始发布工具链是 go1.22.0。这个规则不能倒推到所有历史版本：Go 1.21 以前的初始发布名称没有相同的 .0 形式。

先取得随当前 go 命令安装的版本

下面是 Unix shell 的诊断示例，只在本次命令中覆盖工具链选择，不持久修改配置：

GOTOOLCHAIN=local go version
GOTOOLCHAIN=local go env GOENV GOROOT GOMOD GOWORK

local 让命令使用随当前 go 命令安装的工具链，可用于绕过错误的下载选择。它不保证这个版本满足项目要求，也不能当作所有构建长期禁用自动切换的修复。

核对实际执行的 go 路径、GOENV 指向的用户配置位置、当前模块和工作区。终端、IDE 和 CI 可能使用不同二进制或环境。空目录正常、项目目录失败时，要继续查看 go.mod、go.work 的 go 与 toolchain 声明；不能仅凭新终端正常就认定项目已恢复。

环境变量为空，仍可能有用户默认设置

GOTOOLCHAIN 的选择依次考虑进程环境、用户默认环境文件和工具链自带的默认配置。shell 中没有显式变量，不意味着用户文件里也没有它。

按刚才取得的 GOENV 路径查看相关行，注意文件可能还保存了 GOPROXY、GOPRIVATE 等其他项目需要的设置，诊断时不要公开整份配置。若确实存在 GOTOOLCHAIN=go1.22，就有明确的无效工具链名称线索；不要继续删除安装目录、模块缓存或整个用户配置文件。

go.mod 的 go 1.22 是合法的语言版本要求，不能把它一概说成错误语法。部分旧工具链的自动选择行为会涉及具体发布版本，模块声明与 GOTOOLCHAIN 的工具链名称应分别核对。

只撤回确认有问题的默认值

保存原 GOTOOLCHAIN 值和用户配置后，可用以下示例仅移除 go env -w 保存的这一个默认设置：

GOTOOLCHAIN=local go env -u GOTOOLCHAIN

这会修改用户默认配置，但不会删除 shell、IDE 或 CI 注入的同名环境变量。若进程环境还显式指定了错误名称，应在实际注入位置修正，并重新启动受影响的会话。

移除用户值后会回到剩余配置层的选择规则，不能保证所有重新打包的 Go 都使用 auto。项目确实需要固定工具链时，应采用项目认可、存在且适合目标平台的完整名称，不应把历史 go1.22.0 当作今天所有项目都应固定的版本。

项目要求也需要同步审查。不要为了下载失败随意降低 go.mod 的最低版本；依赖和源码可能需要新能力。升级或调整 go/toolchain 声明应保存差异并按项目流程验证，不能通过重装掩盖工作区和模块要求的不一致。

名称正确后仍下载失败，再看新的证据

如果选择的是确实存在的工具链，但错误转为网络、代理或校验失败，应检查获准的下载路径与 GOPROXY 等配置。不同故障需要不同处理，不要因为最初出现 toolchain not available 就关闭校验或永久设 GOTOOLCHAIN=local。

自动下载的工具链需要验证；GOSUMDB=off 可能导致下载无法验证。应保留项目的供应链要求，解决实际下载与校验条件，而不是用不受信任的二进制填补缺失名称。

回到原失败入口检查选择

先确认普通 go version 不再请求错误的名称，再在原项目、IDE 和 CI 入口核对所选工具链。Go 1.24 起可按当前文档使用 toolchaintrace 观察选择过程；旧版本没有该能力不能当作新的异常。

最后检查项目原来的构建和测试是否使用预期版本。能输出版本只证明工具链选择已能启动，不证明项目构建已经通过。需要回退时按保存的值恢复用户配置和项目声明，并明确错误设置是否会重新出现；删除缓存或安装目录不是这次配置修改所需的回退步骤。