答案是：耦合程度高表现为工具可量化、编译器拒绝、测试卡住，典型信号为import cycle not allowed报错或改User结构体需同步更新service/repo/handler；可用go mod graph和go list定位强依赖路径，接口须独立于实现与调用方，replace非解耦手段，测试覆盖率不等于低耦合。
耦合程度高，不是“感觉代码乱”，而是能被工具量化、被编译器拒绝、被测试卡住——最直接的信号是 import cycle not allowed 报错，或每次改一个 User 结构体就得同步更新 service、repo、handler 三个包。
用 go mod graph 和 go list 定位强依赖路径
Go 不提供“耦合度评分”，但能精准暴露谁在偷偷 import 谁。关键不是看 go.mod 里写了什么，而是看实际构建时的导入图：
-
go mod graph | grep yourmodule—— 查看哪些模块直接依赖你，以及它们还拉了哪些间接依赖 -
go list -f '{{.Deps}}' ./service—— 检查service包是否意外 import 了mysql或http等底层实现包（它只该 importrepo接口和model） -
go list -f '{{.Imports}}' ./repo/mysql—— 确认 mysql 实现包没反向 importservice或handler
如果发现 service → repo/mysql → service 这类闭环，说明接口没抽离干净，不是模块划分问题，是源码级循环。
接口定义必须独立于实现和调用方
很多团队把 UserRepo 接口放在 repo 包里，结果 service import repo，mysql 也 import repo，看似解耦，实则 repo 包成了“中间人依赖”——一旦它加个新方法，两边都得改。正确做法是：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 接口定义放在调用方更靠近的包，比如
service包内声明UserRepo接口（因为 service 才真正决定“需要什么能力”） -
mysql包只 importservice（或独立的contract包），实现该接口，不 importservice的任何逻辑代码 -
model包纯数据结构，不 import 任何其他业务包
这样 service 和 mysql 之间只有单向依赖：service → model，mysql → model + service（仅接口），没有交叉。
replace 不是解耦手段，而是开发期临时绕过模块隔离
看到 replace github.com/yourorg/lib => ./lib 就以为“模块已解耦”，这是典型误解。replace 只解决路径映射，不解决源码依赖方向。它甚至会掩盖真实耦合：
- 主模块用 replace 引用子模块，但子模块内部仍 import 主模块的
handler—— 编译能过，运行可能 panic，测试无法隔离 - CI 构建禁用 replace 后，
cannot load错误暴露出原本被掩盖的 import cycle - 真正解耦后，子模块应能独立
go test，不依赖主模块任何代码
验证方式：删掉主模块的 replace，把子模块单独 cd ./lib && go build。如果失败，说明它还没做到真正的模块自治。
测试覆盖率不能替代依赖结构审查
100% 单元测试覆盖率≠低耦合。常见陷阱是 mock 太重：
- 为测
UserService，mock 了整个EmailSender+DB+CacheClient，但这些 mock 本身又 import 了大量非必要类型（比如 mock 的DB依赖http包） - 测试文件里
import "github.com/yourorg/app/handler"—— 这意味着 handler 的变更会触发 service 测试失败，耦合已渗透到测试层 - 真正松耦合的测试，只 import 被测包 + 其依赖的 interface +
model，其余全用匿名函数或内嵌 struct 实现
最值得警惕的是：当你开始给 mock 写单元测试，或者 mock 文件比业务代码还大——那不是测试写得好，是依赖太紧，逼你用测试去缝合架构漏洞。
