模块加载由go编译器静态分析依赖图决定，require声明逻辑依赖，replace在构建时重写导入路径映射，实际加载代码来源由此确定；import路径需与module声明完全匹配才能命中。
模块加载顺序不等于 import 语句顺序，也不等于文件名顺序——它由 Go 编译器静态分析依赖图决定，且只在构建时固化。
go.mod 中 require 和 replace 如何影响模块加载
require 声明的是「逻辑依赖」，不直接触发加载；真正触发模块初始化的是 import 路径能否被解析到某个已知 module。replace 只在 go build 或 go run 阶段重写导入路径映射，不影响 init 执行时机，但会改变实际加载的代码来源。
- 如果
replace github.com/a => ./local/a，而你的代码 import"github.com/a"，那编译时就会加载./local/a目录下的包，包括它的init() - replace 不会改变模块的 module path，所以
github.com/a在go list -m all中仍显示为原始路径 - 多个 replace 冲突时（比如同一模块被两次 replace），Go 报错：
replaced by multiple modules
import 路径怎么决定哪个模块被加载
Go 按照「最长前缀匹配 + 最新兼容版本」原则解析 import 路径。关键点是：模块路径必须和 go.mod 中的 module 声明完全一致（含大小写、斜杠），否则无法命中。
- 假设
go.mod写的是module example.com/myapp，那么import "example.com/myapp/utils"才能正确解析到本地utils/子目录 - 如果误写成
import "myapp/utils"，Go 会去 GOPROXY 查找myapp模块，而不是报错或 fallback 到本地 - 子模块（如
example.com/myapp/v2）必须显式声明module example.com/myapp/v2，且 import 路径也得带/v2
为什么有时候改了 go.mod 却没生效
常见原因是 Go 缓存了旧的模块解析结果，或项目被意外识别为多模块工作区（go.work 干扰）。模块加载不是“读一次 go.mod 就完事”，而是贯穿 go list、go build、go mod vendor 全流程。
- 删掉项目根目录下的
go.work文件（如果存在），它会让 Go 忽略当前go.mod，转而合并多个模块 - 执行
go mod tidy后，检查go.sum是否更新了哈希值；没更新说明依赖未真正重解析 - 用
go list -m all看实际加载的模块列表，比单纯看go.mod更真实 - IDE（如 GoLand）可能缓存模块信息，右键项目 → “Reload project”（不是 Sync）才能强制刷新
init 函数执行顺序和模块加载的关系
模块加载完成 ≠ init 执行完成。init 是包级行为，发生在模块被 import 触发后，且严格按依赖拓扑排序：被依赖包的 init() 总是在依赖方之前执行完毕。
- 如果
a.goimport"net/http"，那么net→crypto/tls→net/http的所有init()都会在a.go的init()之前跑完 - 同包内多个
init()按源文件中出现顺序执行，但跨文件顺序只由文件名 Unicode 字典序决定（如a_init.go早于b_init.go） - 用
_ "xxx"导入只会触发该包init()，但不会引入任何符号——适合注册驱动、启动后台 goroutine 等副作用操作
最易被忽略的一点：模块加载顺序在 go test 下可能和 go run 不同，因为测试会额外导入 testing 及其依赖，从而改变依赖图拓扑。验证顺序不能只靠 main 包，得用 go list -deps 或加日志打点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
