Go编译器自动拓扑排序模块依赖图，不依赖手动指定顺序；关键在于go.mod和go.work须准确表达依赖关系，go.work是多模块本地开发的必需开关。

go 编译器不依赖你手动指定顺序，它会自动解析模块依赖图并拓扑排序——你真正要管的，是 go.mod 和 go.work 是否如实表达了“谁该被谁用”。

---

模块加载顺序由依赖图决定，不是文件名或 import 语句顺序

Go 不按 import 在源码中出现的先后加载包，也不按文件名（如 a.go 先于 b.go）执行。它先扫描整个模块树，构建一张有向无环图（DAG），再做拓扑排序：入度为 0 的模块（即不被其他本地模块依赖的）最先编译。

• 常见误解：认为 import "github.com/user/lib" 出现在 main.go 第一行，就代表 lib 模块一定先“加载”
• 实际逻辑：只要 lib 是 main 模块的直接或间接依赖，且其 go.mod 被正确识别，Go 就会在编译 main 前完成 lib 的解析与编译
• 容易踩的坑：在多模块项目中，若未用 go work use ./lib 显式纳入工作区，go build 可能仍走 proxy 下载远端版本，而非你本地修改中的 lib

---

go.work 是本地多模块开发的“开关”，不是可选项

当你有 ./app 和 ./shared 两个模块，并希望 app 总是使用本地 shared 的最新代码时，go.work 是唯一可靠方式。

go work init
go work use ./app ./shared

• 执行 go build 或 go test 时，只要当前目录在工作区根下，Go 就会：
  • 忽略 ./shared/go.mod 中声明的 require 版本号
  • 直接读取本地 ./shared 源码，参与依赖图构建
• 若漏掉 go work use，即使路径存在，Go 仍可能 fallback 到 replace 或 proxy 版本，导致“改了代码却不生效”
• 注意：go.work 文件必须位于工作区根目录，且不能嵌套；子目录里执行命令前，需确保 shell 当前路径在工作区根下

---

循环依赖会被编译器立刻拦截，没有绕过余地

Go 明确禁止模块级或包级循环 import：

Evez Github Manager

在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。

下载

立即学习“go语言免费学习笔记（深入）”；

• 错误示例：module A 的 go.mod require B v0.1.0，而 B 的 go.mod 又 require A v0.2.0
• 编译时直接报错：invalid cycle in requirements
• 解法只有三种，没有“黑科技”：
  • 提取公共模块 C，让 A 和 B 都依赖 C
  • 使用接口 + 依赖注入，把具体实现解耦到调用方
  • 合并模块（适用于原本就不该拆分的场景）

别试图用 //go:build 或 replace 掩盖循环——工具链在解析阶段就终止，根本不会走到编译。

---

包内文件执行顺序 ≠ 模块加载顺序，但影响 init 行为

模块加载顺序解决的是“哪个模块先编译”，而包内文件顺序解决的是“同一个包里多个 init() 函数谁先跑”。

• 同一包下，go 按文件名字典序加载（a.go → b.go），每个文件里的 init() 按此顺序执行
• 这和模块无关，哪怕 shared/utils 包被十个模块引用，它的文件加载顺序也恒定
• 容易踩的坑：在 init() 里访问另一个包的变量（比如 log.SetOutput(...)），但那个包的 init() 还没跑——这属于包间依赖，应通过显式初始化函数控制，而非依赖加载巧合

最常被忽略的一点：模块加载顺序只保证“编译通过”，不保证运行时 init 执行顺序跨模块可预测；跨模块的初始化协调，得靠设计（如 shared.Init() 显式调用）。