★ 框架设计思想：组件化/门面模式/接口约定

面试问法：GoFrame 的设计思想是什么？为什么搞一套 g.* 门面、一套目录约定？ 一句话结论：三个关键词——组件化（能力按包拆分、可独立复用）、门面模式（顶层 g.* 聚合常用组件，内部懒加载单例、统一入口）、约定优于配置（官方目录分层 + gen dao/service/ctrl 代码生成保证骨架一致）。设计目标是工程效率：少样板、好维护、易替换。

三个设计支柱

支柱	含义	例
组件化	每个能力独立成包，依赖自洽	gdb/gcfg/glog/ghttp/gcache 可单独使用
门面模式	顶层统一入口聚合单例	g.DB()、g.Cfg()、g.Log()、g.Server()、g.Redis()
约定 + 生成	目录/命名有规范，代码生成对齐	api/internal(controller/service/dao/model)/manifest；gen dao

门面模式怎么看

• 好处：使用者不用记一串包初始化路径，g.DB() 即取即用；单例内部懒加载，进程内天然复用连接池等重资源。
• 代价：隐藏了实现细节与初始化顺序——所以官方要求驱动类组件（如 MySQL/Redis 驱动）必须空导入注册，漏了会报“type not found”。
• 门面不是强 IoC 容器：GoFrame 没有 Spring 那种重依赖注入，模块解耦靠“service 接口 + 手动/生成式注册”，更轻、更直观。

接口约定与分层

• 依赖单向：api（契约）→ controller（接线）→ service（业务接口）→ dao/model（数据）。反向或跨层依赖会破坏可测性与复用。
• service 面向接口：模块间只依赖接口，实现可替换（mock、换实现），gen service 就是为降低“接口+实现”双份维护成本而生。
• 规范路由把“接口定义、路由、校验、文档”合成一份结构体声明，是“约定优于配置”在 API 层的极致体现。

一句话回答模板

面试可这样组织：先说“组件化给能力、门面给入口、约定给骨架”，再分别举 g.DB()、规范路由、gen dao 三个例子各一句落地说明，最后补“解耦靠 service 接口与生成器，而非重 IoC 容器”——有理论、有例子、有边界。

常见追问

• 追问：门面模式有什么缺点？——全局单例让测试替换变得麻烦（要绕开 g.* 或靠接口层注入）；大量魔法入口也提高了框架学习门槛。
• 追问：它和 Spring 的 IoC 本质区别？——Spring 靠容器管理 Bean 生命周期与自动注入；GoFrame 用“包内单例 + 显式注册/生成”实现轻量解耦，没有运行时反射式装配中心。
• 追问：为什么强调“可选”？——官方不少能力标注实验/可选（如部分生成命令），说明设计上倾向“核心稳定、外围可演进”。

记忆点

• 组件化给能力、门面给入口、约定给骨架；解耦靠接口不靠容器。