Beego默认MVC结构违反Clean Architecture规则：Controller直接调用ORM、Model硬编码数据库标签、router绑定具体控制器实例，导致业务逻辑与框架强耦合，无法独立测试和复用。
Beego 默认的 MVC 结构不满足 Clean Architecture 的依赖规则——控制器直接调用 ORM、模型硬编码数据库逻辑、业务逻辑散落在 Controller 和 Model 里，导致换数据库或改 UI 时必须动核心逻辑。真要落地 Clean Architecture，必须打破 beego 的“约定优于配置”惯性，手动重建分层边界。
beego 中哪些默认结构违反 Clean Architecture 规则
beego 的 Controller 直接调用 orm.QueryTable、Model 包含 TableName() 和字段标签（如 orm:"column:id"）、router.go 里绑定的是具体控制器实例——这三项全在把框架细节（ORM 实现、路由注册机制、HTTP 生命周期）泄漏进业务层。
常见错误现象包括：
- 改个数据库字段名，要同步改
Model结构体 +Controller查询逻辑 + 前端字段映射 - 想把某个 API 从 HTTP 接口改成 CLI 命令，发现所有业务逻辑都卡在
Controller的Get()/Post()方法里，无法复用 - 单元测试写不下去，因为
Controller初始化强依赖 beego 的运行时上下文（beego.Controller），mock 成本高
如何在 beego 项目中补上 Clean Architecture 的四层接口
不是推翻 beego，而是把它降级为纯“驱动层”。关键动作是定义三层接口，并让 beego 只出现在最外层：
-
UseCase层：只定义输入（InputDTO）、输出（OutputDTO）、错误（ErrUserNotFound），不出现任何 beego、orm、http 相关 import -
Repository接口：例如type UserRepository interface { FindByID(ctx context.Context, id int64) (*User, error) }，放在domain/或usecase/下，不带实现 -
Gateway层（即 Interface Adapters）：实现UserRepository，但具体实现在data/orm/user_repository.go，里面才 import"github.com/astaxie/beego/orm" -
HTTP Handler层：在server/web/handler/user_handler.go里，接收 beego 的Controller实例，调用UseCase，再把OutputDTO转成controller.Data["json"]
这样，UseCase 和 Repository 接口完全不依赖 beego；哪怕哪天换成 Gin，只需重写 Handler 和 Gateway 实现，业务逻辑一行不用动。
beego.Router 绑定方式必须从实例改为函数式
beego 默认允许 beego.Router("/users", &controllers.UserController{}) 这种基于结构体实例的注册，但它会强制控制器持有框架上下文，破坏 UseCase 的纯净性。必须切换到函数式路由：
func init() {
beego.Router("/users/:id", &controllers.UserHandler{}, "get:GetUser")
}
// UserHandler 不再嵌入 beego.Controller
type UserHandler struct {
getUserUseCase usecase.GetUserUseCase // 依赖注入 UseCase 接口
}
func (h *UserHandler) GetUser() {
id, _ := h.Ctx.Input.Param(":id")
user, err := h.getUserUseCase.Execute(context.Background(), id)
if err != nil {
h.Data["json"] = map[string]string{"error": err.Error()}
h.ServeJSON()
return
}
h.Data["json"] = user
h.ServeJSON()
}
注意：UserHandler 自己管理依赖（getUserUseCase），而不是靠 beego 自动 new 实例。初始化时需手动构造并传入，例如在 main.go 中：
<pre class="brush:php;toolbar:false;">orm.RegisterModel(new(model.User))
o := orm.NewOrm()
repo := data.NewUserRepository(o)
usecase := usecase.NewGetUserUseCase(repo)
handler := &controllers.UserHandler{getUserUseCase: usecase}
容易被忽略的 Data 层隔离细节
很多人以为只要把 ORM 操作挪到 data/ 目录就算解耦了，其实不然。以下三点常被跳过：
-
data/下的实体（如data/orm/user.go）不能和domain/下的User共用结构体——前者带 beego 标签（orm:"pk;auto"），后者只含业务字段（ID int64,Name string）。必须做一次转换（toDomain()/toData()） -
Repository接口方法参数不能是 beego 的context.Context，而应是标准库context.Context（它本身是接口，无依赖） -
data/目录下不能出现任何beego.或controllers.的 import，否则就又反向依赖了
真正的隔离点不在目录划分，而在 import 图——domain/ 不能 import 任何非标准库或本项目 domain/ 内部的包；data/ 可以 import domain/，但反过来绝对不行。
