go 1.16+ 不需也不该配置 gopath，因默认启用 go111module=on，gopath 已无实际影响；关键是要确保 go111module=on 且 go mod init 的模块路径与 import 路径严格一致。
不用配置 GOPATH，也不该去配。 Go 1.16+ 默认启用 GO111MODULE=on，GOPATH 对项目构建、依赖解析、import 路径已无实际影响——它只在极少数旧场景下起作用，强行配置反而容易触发降级行为或路径错乱。
go env GO111MODULE 输出 off 或 auto 就得立刻处理
这是最常被忽略的开关状态问题。输出 off 表示模块完全关闭；输出 auto 表示“看情况启用”：如果当前目录或父目录有 go.mod 就用模块，否则 fallback 到 GOPATH/src 查找，极易导致同一命令在不同路径下行为不一致。
- 执行
go env -w GO111MODULE=on强制启用模块模式 - 删掉项目中可能残留的
GO111MODULE=off设置（比如~/.bashrc或/etc/profile里的export GO111MODULE=off） - 重启终端或运行
source ~/.zshrc（或对应 shell 配置文件）让变更生效 - 再跑一次
go env GO111MODULE，确认输出是on
go mod init 后 import 路径报错：不是路径写错了，是模块名没对齐
常见错误现象：cannot find module providing package myutils 或 import "config" not found。这不是因为没加 ./ 前缀，而是模块路径（module 声明）和实际 import 语句不匹配。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
go mod init后面跟的不是本地路径，而是模块路径，例如go mod init github.com/yourname/project，之后所有import都要以这个前缀开头（如import "github.com/yourname/project/config"） - 如果原项目在
$GOPATH/src/myproject下，别写go mod init myproject，那会导致 import 写成"myproject/config"—— 这种短路径只在 GOPATH 模式下有效，模块模式下会直接失败 - 子目录内执行
go run main.go时，确保main.go所在路径相对于模块根是合法的（比如模块根是~/proj，main.go在~/proj/cmd/app/main.go，那它的package main就没问题，但 import 其他包必须用完整模块路径）
VS Code 提示 “No modules found” 或依赖红线不断
这通常不是环境变量问题，而是工作区没落在模块根目录，或 go.mod 不完整。
- 用 VS Code 打开的是整个
~/projects文件夹，而不是含go.mod的具体项目目录 → 关闭窗口，重新打开那个项目根目录（即有go.mod的那一层） - 项目根目录有
go.mod，但里面只有module example.com/hello，没有go 1.23或依赖项 → 运行go mod tidy补全 - 仍报错？按
Ctrl+Shift+P→ 输入Go: Restart Language Server，强制重载 gopls - 检查
.vscode/settings.json里有没有"go.gopath"字段，有就删掉——现代 Go 扩展不需要它
真正需要你操心的只有两件事：确保 GO111MODULE=on，以及 go mod init 时写的模块路径能覆盖所有 import。其余所谓 “配置 GOPATH” 的操作，基本都在给已经退役的机制擦灰。最容易被忽略的点是：你以为自己在用模块，其实 go env GO111MODULE 是 auto，而当前目录又没 go.mod，结果命令悄悄退回到 GOPATH 查找逻辑，构建行为和预期完全脱节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
