Kratos 模块拆分后报 ImportError 是因跨层反向 import 导致导入环；须用接口抽象+依赖注入容器解耦，禁用硬编码 import，严格按依赖顺序注册 provider，domain 层仅含纯实体、事件与仓储接口。
为什么 Kratos 项目一拆模块就报 ImportError？
Kratos 默认按“分层 + 模块”组织代码（api、service、data、domain），但很多团队直接把业务逻辑写进 service 层，又在 data 层反向 import service 的函数或结构体来触发事件——这就立刻形成导入环。Python 解释器在加载模块时是线性执行的，一旦 A.py 顶层 import B.py，而 B.py 顶层又 import A.py，就会卡在未完成初始化的状态，抛出 ImportError: cannot import name 'X' from partially initialized module。
延迟导入不是“加个 import 在函数里”就完事
在 Kratos 中，延迟导入必须配合依赖注入容器（di.Container）使用，否则只是把问题从启动阶段推迟到运行时。正确做法是：
- 所有跨层调用（比如
data层需要通知service层）不写from service.xxx import Y，而是通过接口抽象 + 容器注入 - 在
internal/data/xxx.go中定义回调接口，如type NotifyHandler interface { OnUserCreated(uid int64) } - 在
internal/service/xxx.go实现该接口，并在internal/di/providers.go中注册为单例 -
data层只持有NotifyHandler接口，由容器在构建时传入，不感知具体实现
这样既切断了 import 链，又保留了清晰的调用语义。硬塞 import 到某个 func 体内，但没解耦接口，只是掩耳盗铃。
di.Provider 注册顺序和参数绑定很关键
Kratos 的 di.Container 是按注册顺序解析依赖的，如果 A 依赖 B，B 又依赖 C，那 C 必须先注册。常见错误包括：
- 在
providers.go里把service.NewUserService()放在data.NewUserRepo()前面，而后者构造函数需要NotifyHandler—— 此时容器还没注册 handler，会 panic - 用
di.As(new(NotifyHandler))绑定接口时，没确认实现类型是否已注册，导致注入失败却无提示 - 多个模块各自注册同名接口（比如都注册
*notify.Handler），容器不会报错，但运行时行为不可控
建议每个模块的 providers.go 显式导出一个 ProviderSet 变量，主模块统一按依赖拓扑顺序拼接：di.New(di.ProviderSet(a.ProviderSet, b.ProviderSet))。
别让 domain 层变成“胶水层”
有些团队把 domain 当成万能中转站，在里面 import 所有其他层的结构体和函数，再封装一层调用——这等于用一个包把所有循环引用重新集中爆发一次。真正该放在 domain 的只有：
- 纯业务实体（
User、Order） - 领域事件（
UserRegisteredEvent） - 仓储接口（
UserRepo interface { Save(*User) error }）
任何带具体实现、数据库操作、HTTP 调用、日志打印的代码，都不该出现在 domain。它要是开始 import data 或 service，说明边界已经失守。
