Go 1.16起GO111MODULE默认on，但仍需手动设为on以确保行为一致；模块路径须按最终import地址预设（如github.com/yourname/mytool），避免简名或本地路径。
GO111MODULE=on 还需要手动设吗？
Go 1.16 起默认启用 Module 模式，GO111MODULE 环境变量已“过时”，但不等于可以不管——它仍会直接影响行为一致性。尤其当你在 $GOPATH/src 下误建项目、或 CI 使用旧版 Go（如 1.15），GO111MODULE=auto 可能静默退回到 GOPATH 模式，导致依赖找不到、go build 报 no required module provides package。
- 运行
go env GO111MODULE，输出不是on就要干预 - Linux/macOS：执行
go env -w GO111MODULE=on（比export更可靠，永久生效） - Windows PowerShell：用
go env -w GO111MODULE=on，别用$env:GO111MODULE="on"（仅当前会话） - 旧项目迁移时，务必确认当前目录不在
$GOPATH/src内，否则模块模式可能被绕过
go mod init 的模块路径怎么写才不翻车？
模块路径不是项目名，而是未来别人 import 你包时的完整路径，错一次，所有 import 语句、CI 构建、版本发布都要改。
- 正确写法：
go mod init github.com/yourname/mytool（即使代码还没推 GitHub，也按最终公开地址预设） - 绝对避免：
go mod init mytool（无命名空间，易冲突）、go mod init /home/user/mytool（本地路径，go build直接报错） - 大小写和下划线慎用：虽然 Go 工具链支持，但某些私有代理（如 JFrog Artifactory）会强制小写，导致
github.com/YourName/My_Tool→ 404 - 内部工具可模拟域名：
go mod init example.org/internal/cli，比mycli更可持续
依赖下载失败？先看 GOPROXY 和 GOPRIVATE
国内直接连 proxy.golang.org 基本超时，而没配 GOPRIVATE 时，私有仓库（如 git.company.com/foo/bar）会被代理拦截并返回 404，错误常表现为 unknown revision 或 verifying ...: checksum mismatch。
- 设国内代理（推荐）：
go env -w GOPROXY=https://goproxy.cn,direct - 私有域名必须加
GOPRIVATE：go env -w GOPRIVATE=git.company.com,github.company.internal - 若私有库无 HTTPS 或证书不可信，还需加：
go env -w GONOSUMDB=git.company.com（跳过校验）或GOINSECURE=git.company.com（仅开发环境） - 验证是否生效：
go env GOPROXY GOPRIVATE，两个值都得有输出
go mod tidy 报 “no required module provides package” 怎么快速定位？
这不是网络问题，是 import 路径和模块定义对不上。比如你在代码里写了 import "github.com/you/project/v2/util"，但 go.mod 里声明的是 module github.com/you/project 且没发 v2 标签，Go 就找不到对应模块。
- 第一步：检查出错的
import路径，对照go.mod第一行module xxx是否前缀匹配 - 第二步：运行
go list -m all | grep -i 关键词，看该包是否真被引入、版本是否合理 - 第三步：确认该包所在目录是否有
go.mod，且其module声明与 import 路径一致（常见于本地 replace 未同步更新） - 临时绕过（仅调试）：
go mod edit -replace github.com/xxx=../xxx，但上线前必须删掉
最常被忽略的其实是模块路径的“前瞻性”——很多人初始化时图省事用简名，等团队协作或上 CI 才发现一堆 import 得全局替换。设好 GO111MODULE=on 和 GOPROXY 只是起点，模块路径选错，后面所有 go get、go mod vendor、版本语义化都会被动摇根基。
