go 1.16+ 必须启用 go111module=on，禁用 off 模式以避免 fallback 到 gopath；需手动执行 go mod init 初始化模块，模块路径须符合域名格式，并通过 replace 支持本地包引用。
Go 1.16+ 必须用 go mod，不用 GO111MODULE=off 混淆路径
Go 1.16 起默认启用模块模式，go mod 不再是可选项。如果你还手动设 GO111MODULE=off 或依赖 $GOPATH 下的旧式布局，编译时会报 no required module provides package 或找不到本地包——这不是路径写错了，是根本没进模块上下文。
实操建议：
- 删掉所有
export GO111MODULE=off（包括 shell 配置文件） - 在项目根目录执行
go mod init example.com/myapp，模块名不必真实可访问，但需符合域名格式（避免纯名如myapp，否则后续go get可能误解析） - 只要目录下有
go.mod，所有go build/go run都自动按模块解析依赖，不再看$GOPATH/src
go build -o 输出路径不带扩展名，Windows 下要手动加 .exe
Linux/macOS 下 go build -o mybin main.go 生成可执行文件 mybin；Windows 下同样命令生成的是 mybin（无后缀），但双击打不开、终端里也提示“不是内部或外部命令”。这不是权限问题，是 Windows 执行机制要求可执行文件必须有 .exe 后缀。
实操建议：
- 跨平台构建时统一用
go build -o mybin.exe main.go（Windows）或go build -o mybin main.go（其他系统） - CI/CD 中推荐用
GOOS=windows go build -o mybin.exe显式指定目标系统，避免本地环境干扰 - 别依赖
go install自动复制到$GOPATH/bin——模块模式下它只装已发布版本，本地开发应直接go build
本地模块引用必须用 replace，不能靠文件路径或相对导入
想把 pkg/utils 和 cmd/app 分开开发，又不想发版就引用？直接写 import "pkg/utils" 会报 no matching versions for query "latest"。Go 的模块系统不认相对路径，也不接受未声明的本地路径导入。
实操建议：
- 在主模块的
go.mod里加replace pkg/utils => ./pkg/utils（路径必须相对于go.mod所在位置） - 被 replace 的目录下也得有独立的
go.mod（哪怕只有一行module pkg/utils），否则go mod tidy会清掉这条 replace - 切勿用
replace github.com/x/y => /abs/path/to/y：本地路径必须是相对路径，绝对路径会导致go mod vendor失败
go mod vendor 不解决全部依赖，replace 和 indirect 包要单独处理
运行 go mod vendor 后，vendor/ 目录看似完整，但构建仍失败？常见原因是：replace 指向的本地目录没被拷进去，或者 indirect 标记的间接依赖（比如测试工具依赖）被跳过。
实操建议：
- 执行前先确认
go mod edit -vendor是否已启用（Go 1.14+ 默认开启，但某些旧脚本可能关掉） -
replace的本地路径不会进vendor/——这是设计使然，vendor只存远程模块快照；本地开发请保持replace存在，并确保 CI 构建时这些路径可达（或改用git submodule） - 检查
go.mod中带// indirect的行，运行go mod graph | grep xxx确认是否真被需要；冗余的 indirect 依赖可用go mod tidy -compat=1.17清理（根据你最低支持版本调整）
replace 生效范围、vendor 的边界——这些不是配置开关，是 Go 模块模型的刚性约束。绕过去容易，但后续升级、协作、CI 构建会反复踩坑。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
