go mod 是生产级依赖管理机制，非语言学习工具；初学者误用会掩盖 import 路径、模块路径、版本锁定等核心概念的理解断层。
go mod 不是“规范语言学习”的工具，它是生产级依赖管理机制；初学者用错方式，反而会掩盖 import 路径、模块路径、版本锁定等核心概念的理解断层。
go mod init 后 import 不生效，八成是路径没对上
执行 go mod init example.com/hello 只生成 go.mod，不改变任何目录语义。Go 的 import 路径必须和 module 声明 + 文件系统路径严格一致：
- 若
go.mod写的是module example.com/hello，那import "example.com/hello/utils"才合法，对应目录必须是./utils/ -
import "./utils"或import "utils"会报import path does not begin with hostname - 子目录里有
func main()？Go 会把它当可执行包（package main），无法被其他包 import - 把代码放在
$GOPATH/src下却开了GO111MODULE=on，Go 直接忽略该路径，不提示原因，只报找不到包
go get 默认拉最新版，生产环境必须显式锁死
go get github.com/gin-gonic/gin 会取最新 tag（比如 v1.9.1），但下次构建可能因上游发了 v1.9.2 而行为突变——这不是 bug，是默认策略：
- 锁版本：用
go get github.com/gin-gonic/gin@v1.8.2，go.mod中写入require github.com/gin-gonic/gin v1.8.2 - 别用
go get -u升级全部依赖：它跳过go.sum校验，还可能把// indirect依赖也升级，引发兼容问题 - 只改
go.mod里的版本号，不运行go get或go mod tidy，Go 不会下载新版本，编译仍用旧缓存
本地修改依赖时，replace 是标准解法，不是临时 hack
调试 fork 的库或正在开发的内部组件，replace 是 Go Modules 原生支持的机制：
立即学习“go语言免费学习笔记（深入）”；
- 在
go.mod末尾加：replace github.com/foo/bar => ./local-bar，之后import "github.com/foo/bar"就加载./local-bar -
replace支持绝对路径、相对路径，甚至另一个 Git 仓库：replace github.com/foo/bar => github.com/myfork/bar v0.1.0 - 注意：
./local-bar目录下最好先跑go mod init，否则 Go 会尝试从package声明推断模块名，容易出错
go mod tidy 报 “no required module provides package”，本质是路径错配
这不是网络问题，也不是权限问题，而是 go.mod 里没有声明能提供该 import 路径的模块：
- 检查
import是否拼错：比如import "githib.com/xxx"（少了个u） - 确认
import路径是否和某个require行的模块路径前缀匹配（例如require example.com/lib v1.0.0，只能支撑import "example.com/lib"或其子路径） -
go list -m all可列出当前解析出的所有模块，对照看缺哪个
真正难的从来不是命令怎么敲，而是理解 import 路径如何映射到磁盘目录、模块路径如何约束依赖可见性、以及 go.sum 如何在无人干预时默默保证校验一致性——这些细节不踩一遍坑，就永远在调通和崩掉之间反复横跳。
