能用但不该用——go 1.16+ 启用 go111module=on 后，gopath 仅影响 go install 输出路径和未指定模块的 go get 存放位置，不再决定源码根目录；项目结构由 go.mod 所在目录定义，与 gopath/src 无关。
Go Modules启用后，GOPATH还能不能用
能用，但不该用——Go 1.16+ 默认启用 GO111MODULE=on，此时 GOPATH 仅影响 go install 输出路径和 go get 未指定模块时的默认存放位置，不再决定源码根目录。项目结构完全由 go.mod 文件所在目录定义，与 GOPATH/src 无关。
常见错误现象：go run main.go 正常，但 go build 报 cannot find module providing package ...；或 go get github.com/some/pkg 拉到 $GOPATH/src 下却无法被当前模块识别。
- 确认是否启用模块：运行
go env GO111MODULE，输出必须是on（不是auto） - 初始化模块前，先
cd到你希望的项目根目录（比如~/myapp），再执行go mod init example.com/myapp - 不要把项目放在
$GOPATH/src下再 init——这会制造路径错位，导致go.sum校验失败或本地replace不生效
Git仓库根目录和Go模块根目录必须严格一致
不一致就会在 CI/CD 或他人 go get 时出问题：依赖解析错乱、go list -m all 显示路径异常、go mod vendor 失败。
实操建议：
-
git init必须在go mod init同一目录下执行；反过来也一样——先git init，再go mod init，但不能跨目录 - 检查一致性：进入项目目录后，运行
git rev-parse --show-toplevel和go list -m（无参数），两者输出路径应完全相同 - 如果已建错，不要挪动
.git目录或重写go.mod路径——直接删掉.git和go.mod/go.sum，重新初始化
.gitignore 里必须排除哪些 Go 相关文件
漏掉会导致二进制、缓存、临时文件污染仓库，引发构建不一致或安全风险。
关键排除项（按实际使用场景）：
-
/bin/和/pkg/：即使不用 GOPATH 模式，有些工具（如dlv调试器生成的__debug_bin）也会往这里写 -
**/*.exe、**/*.test、**/go-build*：Windows/Linux 测试/构建产物，非源码 -
go.work：多模块工作区配置文件，不应提交——它只对本地开发有意义，CI 环境应靠go mod edit -replace或GOWORK=off控制 -
vendor/：除非明确要求锁定所有依赖（如离线构建），否则不建议提交；现代 Go 推荐靠go.sum+go mod download还原
打 tag 前必须验证三件事
Go 生态认的是 tag，不是分支。一个没校验就打的 v1.2.0 tag，可能让下游用户 go get myrepo@v1.2.0 拉到无法编译的版本。
每次打 tag 前执行：
- 运行
go mod tidy，确保go.mod和go.sum一致且无冗余依赖 - 检查
go.mod第一行module声明是否与你的仓库地址匹配（例如 GitHub 仓库是github.com/user/repo，那 module 行就得是module github.com/user/repo） - 本地构建并测试：
go build -o ./tmp/main ./...+go test ./...全部通过，再git tag v1.2.0并git push origin v1.2.0
最容易被忽略的是 go.mod 中 module 路径和 Git 远程地址的隐式绑定——改了 GitHub 仓库名但没同步改 module 行，tag 就失效了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
