goland的“refactor → move”不能直接拆模块，因其仅支持包内移动，不自动更新import路径、不检查非法依赖、不补go.mod；拆模块需手动约束import、分层抽象接口并用go mod tidy验证。
模块间依赖最小化拆分不是靠 IDE 自动完成的，而是靠你主动约束 import 路径 + 分层接口抽象 + go mod tidy 验证。GoLand 只能帮你看见依赖、定位引用、高亮循环，不替你做设计决策。
为什么 GoLand 里“右键 → Refactor → Move”不能直接拆模块
GoLand 的重构功能默认只处理包内移动（如函数/类型在同包内重命名或提取），一旦跨目录移动文件，它不会自动更新 import 路径、不会检查是否引入了非法依赖、也不会帮你补 go.mod 条目。更关键的是：Go 没有“模块级访问控制”，internal/ 或 pkg/ 的语义全靠目录名和 Go Modules 规则强制——IDE 不会阻止你从 cmd/app 直接 import internal/handler，但构建时会报错。
- 手动移动文件后，必须立刻运行
go build ./...或go test ./...验证是否破坏导入链 - 若目标目录已存在
go.mod（比如子模块），移动过去前得确认该模块是否声明了对源模块的require - GoLand 的 “Find Usages” 对跨模块调用有时失效——尤其当被调用方是未导出方法或嵌入结构体字段时
用 go mod graph 和 GoLand 依赖图交叉验证真实依赖
GoLand 的 “Show Dependencies Diagram” 显示的是当前文件编译时实际参与的依赖，但它可能漏掉构建标签（//go:build）过滤的包，或被 replace 掩盖的真实路径。所以得用命令行补全：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在项目根目录运行
go mod graph | grep 'your-module-name'，看哪些模块直接依赖你正在拆的包 - 对比 GoLand 图表中显示的边，如果命令行输出有而图表没有，大概率是构建约束没命中，或 IDE 缓存未刷新（可试
File → Reload project from disk） - 特别注意
golang.org/x/...类路径——它们常被间接引入，但 GoLand 图表默认折叠，需在设置里取消勾选 “Hide standard library” 才能看到
拆分时如何守住 internal/ 边界不被越界引用
Go 的 internal/ 机制是编译期强制的：任何位于 your-module/internal/xxx 下的包，只能被同一模块根目录下的代码 import。但开发者容易踩坑：
- 错误地把
internal/包放到子模块（如api/internal/）下——此时它只对api/模块私有，cmd/app仍可 import，失去隔离意义 - 在
go.mod中用replace指向本地internal/路径，绕过编译检查（例如replace example.com/core => ./internal/core），这会让依赖关系失真且无法发布 - 测试文件（
*_test.go）与源码同目录时，可跨internal/边界 import —— 这是合法的，但意味着你的测试耦合了实现细节，后续拆分时要同步迁移测试
拆完后必须跑的三步验证
仅靠 GoLand 的语法高亮和跳转不能证明拆分成功。最终验证必须落地到构建和运行时：
- 执行
go mod tidy -v：观察输出里是否出现removing requirement，这是依赖真正被切断的信号；若提示require ... missing，说明某处 import 还没清理干净 - 在终端中切换到待拆出的子目录，运行
go list -m—— 如果输出不是该子模块自己的路径（如example.com/api），而是父模块（如example.com），说明它还没成为独立模块，go mod init没生效 - 删掉
go.sum后重新go mod download：若失败，说明某个被拆走的包仍被主模块隐式引用（比如通过间接依赖），得用go mod why -m xxx追根溯源
最易被忽略的点：拆分后 internal/ 包里的类型如果实现了某个公共接口，而该接口定义在外部模块（如 pkg/contract），那么这个 internal/ 包就天然依赖那个外部模块——它的“内部性”已经让渡给了契约，不能再当作纯实现来随意移动。
