Golang 企业级开发框架的架构设计思维

企业级Go框架设计以业务约束为起点，通过“约定优于配置”实现目录即契约、路径与handler强绑定、中间件可拆解、服务治理预留钩子、接口面向业务变更等架构实践。

说实话，企业级Go框架的构建，本质上不是简单地堆砌功能。更准确地说，它是一种将业务约束翻译成代码结构的架构思维。打个比方，如果我们要开发一个临床试验系统，那就必须满足GCP审计日志、多中心权限隔离、HIS/LIS对接等一系列硬性要求。那么，框架的设计就必须从这些约束倒推回来，而不是反过来。

约定优于配置：目录结构即契约

一个好的框架，应该能让新成员入职后10分钟内写出一个合规API。这靠的不是动辄几百页的文档，而是目录结构本身所代表的强制约定。比如，internal/handler只放HTTP入口，internal/logic禁止直接调用DB，internal/model里的struct必须带有CreatedAt和UpdatedBy字段。一旦有人在logic里写db.QueryRow，CI（持续集成）就该直接报错。这才是真正的“契约”。

• 路径名和handler函数名强制绑定：例如/v1/sites/:site_id/subjects，就对应handler.SiteSubjectHandler.List，一目了然。
• 所有handler必须接收*gin.Context或封装后的app.Context，禁止裸传http.ResponseWriter。
• internal/pkg下只放跨域工具（如JWT解析、审计日志写入），绝对不放任何业务逻辑。

中间件链必须可拆解、可跳过

那在实际的业务中，是不是所有接口都要走完整的中间件链？显然不是。比如，患者提交问卷（ePRO）需要走鉴权+审计+限流的完整链路；但后台导出Excel报表，则只需要鉴权和权限校验，跳过限流和审计日志（避免IO拖慢导出性能）。

• 直接用r.GET("/export", authMiddleware, exportPermissionMiddleware, exportHandler)这种显式声明的方式，别把所有中间件都塞进全局的r.Use()里。
• 权限中间件里别做DB查询。查用户所属site ID这种操作，应该由前置的authMiddleware在解析JWT后，存到c.Set("site_id", xxx)里，后续中间件直接从context里取。
• 审计日志中间件必须支持c.GetBool("skip_audit")，方便测试或内部调试时灵活绕过。

服务治理能力不能靠“加插件”补

像Go-Zero这样的框架，内置了熔断限流，而Gin则需要自己集成gobreaker和golang.org/x/time/rate。但核心问题并不在于选型，而在于设计时是否预留了这些能力的接入钩子。

• 所有RPC调用必须经过统一的出口函数rpc.Call(ctx, service, method, req)，而不是散落在各处的client.Do()。
• HTTP client必须用封装后的httpx.Client，它默认带超时、重试、指标打点，并且允许按path前缀关闭重试（比如对/healthz这样的健康检查端点就不重试）。
• 熔断状态不能只存在内存里。生产环境必须持久化到Redis，否则单实例重启就意味着熔断记忆的丢失。

接口抽象要面向业务变更，而非技术实现

记得有个项目，需要让智能开放平台接入三家不同AI厂商的模型。如果当时定义的是type BaiduAIClient struct，那么每新增一家，就得改三处代码。但如果一开始定义type AIModel interface { Predict(ctx context.Context, input string) (string, error) }，那么新增厂商就只需要实现这个接口，改动成本极低。

• 数据库层的抽象用Repo接口，而非ORM实体。例如SubjectRepo只暴露Create/FindBySiteID，而不暴露UpdateByID这种容易被滥用的方法。
• 第三方对接统一走adapter层。比如hismiddleware.HISAdapter包含GetPatientInfo和SyncVisitRecord，内部则可以方便地切换HL7 v2/v3或FHIR协议。
• 所有接口方法的参数必须是struct，禁止裸传多个string/int。这样既方便扩展字段，也利于mock测试。

说到底，写代码本身并不是最难的部分。真正的难点在于判断：某个功能该放进框架成为通用约束，还是交给业务代码去灵活处理。比如JWT秘钥轮换，框架只提供ParseToken接口和key fetcher注册点，至于具体怎么从Vault拉密钥、何时刷新，这些交由业务来决定才是更明智的选择。