go中导入本地模块需先在项目根目录执行go mod init初始化模块并生成go.mod，再按模块路径组织包结构，主程序用“模块名/子包”形式导入，确保路径与模块名一致，禁用相对路径。
go mod init 之前先确认当前目录是否已存在 go.mod
循环导包（比如 A → B → A）本质是模块边界混乱，但第一步常被跳过：你根本没在正确位置初始化模块。Go 不会自动识别“项目根目录”，go mod init 必须在你打算作为模块顶层的目录下执行。如果误在子包里执行，会生成嵌套、冲突的 go.mod，后续 go build 或 go list 就容易报 import cycle not allowed。
实操建议：
- 用
find . -name "go.mod"扫一遍整个代码树，删掉所有非顶层的go.mod - 进到你认为的项目根目录（通常含
main.go或cmd/），再跑go mod init example.com/myapp - 别依赖默认推导名（如
go mod init不带参数），它可能基于当前路径生成非法 module path（含空格、大写、下划线）
require 和 replace 配合解决本地包循环引用
当两个内部包（如 pkg/a 和 pkg/b）互相 import，又都属于同一模块时，Go 允许——但前提是它们不能通过外部路径导入对方。常见错误是：在 pkg/a/a.go 里写 import "example.com/myapp/pkg/b"，而 pkg/b 又反向 import a，这就触发循环。
正确做法是统一用相对路径导入（即不带 module 前缀），因为它们同属一个 module：
-
pkg/a/a.go中应写import "./b"或直接import "example.com/myapp/pkg/b"—— 等等，这句不对；只要在同一 module 下，就该用标准导入路径，但必须确保go.mod的module声明与实际路径一致 - 更稳妥的是：把循环依赖的逻辑抽到第三个包（如
pkg/core），让a和b都只依赖core，不互赖 - 若必须保留双向调用，可用
replace在go.mod中临时将其中一个包指向本地路径，绕过版本解析阶段的校验（仅限开发期）：replace example.com/myapp/pkg/b => ./pkg/b
go list -f '{{.ImportPath}}' all 能快速定位隐式循环链
编译时报 import cycle 时，错误信息只显示最外层的两个包，但真实循环可能是 A → B → C → A。靠肉眼翻代码效率极低。
用这行命令能导出当前模块所有包的完整 import 图谱：
go list -f '{{.ImportPath}}: {{join .Imports " "}}' all
输出类似：
example.com/myapp/pkg/a: example.com/myapp/pkg/b example.com/myapp/pkg/b: example.com/myapp/pkg/c example.com/myapp/pkg/c: example.com/myapp/pkg/a
一眼看出闭环。注意：all 会包含测试文件，如需排除，加 -test 参数或过滤掉 _test 结尾的路径。
重构时禁用 go.work，避免多模块干扰
如果你正在用 go work use 管理多个模块，而其中某个模块恰好和主模块有同名子包（如都含 internal/db），Go 工具链可能在解析 import 时混淆路径，导致看似无关的循环报错。
验证方式：临时删掉 go.work 文件，再运行 go build。如果错误消失，说明是 workspace 干扰了模块边界判断。
长期建议：
- 单体项目别用
go.work，它专为多仓库协同设计 - 真要拆多模块，每个子模块必须有独立
go.mod，且module名不可重叠（例如不能都是example.com/myapp） -
go.work中的use列表应只包含真正需要联合开发的模块，而非所有本地代码目录
循环导包不是语法问题，是模块契约没对齐。最常被忽略的点是：你以为删了 go.mod 就清除了模块身份，其实 Go 缓存（$GOMODCACHE）里还存着旧的依赖快照，go clean -modcache 才算真正重启。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
