go modules 是 go 官方依赖管理机制，自1.11引入、1.16起默认启用，提供版本控制、依赖隔离与可重复构建；它非独立包管理器，而是内建于工具链的解析与锁定机制。
Go Modules 不是“包管理器”，它没有独立进程、不维护全局锁、不提供依赖图可视化界面，也不支持 workspace-level 多模块协同开发（直到 go.work 出现）。它只是 Go 工具链内建的一套依赖解析与版本锁定机制，所有行为都由 go build、go test 等命令隐式触发。
为什么 go mod init 后 import 路径必须匹配 module 名
Go 的 import 解析规则是硬编码的：导入路径 = module path + 目录相对路径。比如你在 go.mod 里写了 module github.com/user/project，那 import "github.com/user/project/utils" 才能被识别为本地包；写成 import "./utils" 或 import "utils" 都会失败。
- 标准库包（如
fmt、net/http）不受此约束，它们走内置路径，和go.mod无关 - 如果目录结构是
project/internal/handler，但handler.go里声明package main，Go 会报错：找不到对应模块提供该包 -
go list -m all只显示模块层级，go list ./...才反映实际 package 结构，二者不能混用判断
go.sum 不是“锁文件”，而是内容校验快照
go.sum 记录的是每个模块 zip 包解压后所有 .go 文件内容的哈希值（加模块元信息），不是像 package-lock.json 那样记录依赖树拓扑。它只做两件事：下载时写入、构建时比对。
- 只要模块内容没变，哪怕你换代理、换机器、换 Go 版本，
go.sum行不变 - 删掉
go.sum后运行go build，它会重新生成——不是从缓存还原，而是重新下载并计算哈希 - 校验失败时错误是
verifying github.com/xxx@v1.2.3: checksum mismatch，不是版本冲突 - 私有模块若没配
GOPRIVATE，Go 默认跳过校验，go.sum里也不会写入其哈希
GO111MODULE=auto 在 2026 年已实质失效
自 Go 1.16 起默认开启模块模式，现在 GO111MODULE=auto 的行为只剩一个边界 case：项目在 $GOPATH/src 下且无 go.mod。这种路径在现代 CI/CD 和 IDE 中基本消失，auto 已退化为“兼容旧脚本的占位符”。
- 推荐永久设为
go env -w GO111MODULE=on，避免因目录位置误判导致依赖解析失败 - 设为
off会强制回退到 GOPATH 模式，此时go get不写go.mod，import全局查找，极易引发版本漂移 -
GO111MODULE对已有go.mod的项目无影响——存在即启用，变量只是控制初始化行为
真正容易被忽略的，是 go.mod 里 replace 和 exclude 的作用域限制：它们只影响当前模块的构建，不传递给下游依赖。也就是说，你替换了某个模块的本地路径，别人 go get 你的项目时，那个 replace 完全不起作用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
