微服务中import cycle not allowed易发，因共享model/event时包级循环依赖（如order→notification→user→order）导致编译失败，根源是职责错位与边界不清。
为什么import cycle not allowed在微服务里特别容易冒头
微服务不是单体，但包级循环依赖照样会炸——尤其当多个服务共享代码、共用 model 或 event 定义时。比如 order 服务要发通知，调用 notification 包；而 notification 又需要读用户信息，于是 import user 包；结果 user 为了做风控校验，又反向 import order 的状态查询函数。闭环就形成了，编译直接失败。
这不是“调用链太深”，而是包结构暴露了职责错位：领域逻辑、数据访问、事件通知混在同一层，又没划清抽象边界。
- 微服务间共用的 DTO、error、event 类型，如果放在某个服务包里，其他服务 import 它就会悄悄拉入整条依赖链
-
_test.go文件常被忽略，但它可能 import 了 A 和 B 两个包做集成测试，间接促成循环 - 用
wire或dig做 DI 时，若 provider 函数里跨包 new 实例（比如在order的 wire.go 里 newuser.Service），也会触发隐式 import 循环
用 domain 包收拢共享类型，且只放 struct 和 error
所有服务都要用 User、OrderID、ErrInvalidState？别让它们散落在各 service 包里。建一个独立的 domain（或 types）包，只做一件事：定义数据契约。
这个包必须是“干净叶子”：
立即学习“go语言免费学习笔记（深入）”；
-
go list -f '{{.Imports}}' ./domain输出应为空，或仅含errors、time等标准库 - 不写任何 method，禁止
func (u *User) Validate() error—— 验证逻辑属于user/service或order/validator - 不 import 任何业务包，包括
service、repo、handler
示例：domain/user.go
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
package domain
type User struct {
ID int64 `json:"id"`
Name string `json:"name"`
Email string `json:"email"`
}
var ErrUserNotFound = errors.New("user not found")
接口定义必须脱离具体实现方，放在 contract 或 eventbus
别把 Notifier 接口放在 notification 包里，然后让 payment import 它——这等于 payment → notification，而 notification 为读配置又 import payment，循环就回来了。
正确做法：接口和最小 DTO 放进 contract 包（或 eventbus、shared），它只被依赖，不依赖任何人。
-
contract包里定义type UserEvent interface{ GetUserID() int64 }，而不是type UserCreated struct{ ... }—— 后者是 concrete type，会把字段变更风险扩散到所有使用者 - 方法签名尽量用基础类型：
Send(ctx context.Context, msg string) error，避免传*service.User这种强耦合参数 - 如果接口开始出现
Save()、Delete()，说明它已越权，该拆成command+event两层
回调和状态通知一律用函数参数或 functional option
微服务里最典型的伪双向依赖：A 要触发 B 的动作，B 处理完又要回调 A 更新状态。硬写 import "a" 在 B 里，就是自爆开关。
换成显式注入：
- 在
a/service.go里定义回调类型：type OnOrderPaidFunc func(orderID int64) -
b/handler.go不 importa，只接收该函数作为参数：func ProcessPayment(onPaid OnOrderPaidFunc) - 启动时由
main组装：b.ProcessPayment(a.UpdateOrderStatus)
这样依赖方向是单向的：main → a、main → b、b → contract，没有闭环。
复杂场景可升级为 eventbus：所有服务都只 import eventbus，发布/订阅靠 eventbus.Publish(&OrderPaid{...}) 和 eventbus.Subscribe(func(e *OrderPaid){...})，彻底解耦调用关系。
