前后端分离下 GoFrame 的角色定位

面试问法：前后端分离架构里，GoFrame 后端应该承担什么？还会渲染页面吗？ 一句话结论：GoFrame 定位为纯 API 服务端：对外输出 REST/JSON 接口与 OpenAPI 契约，负责鉴权、参数校验、业务与数据；页面与静态资源交给前端工程（nginx/CDN），接口文档是前后端协作的契约。框架保留模板/静态能力，供一体化小项目或需要 SSR 的场景使用，但分离架构下默认不承担渲染。

职责划分

端	承担	不承担
GoFrame 后端	接口契约（OpenAPI）、鉴权、校验、业务、数据、日志/追踪	页面渲染、静态资源分发（分离模式下）
前端 SPA	路由、状态、UI、调用接口	业务规则校验的最终依据、密钥保管
nginx/CDN	静态资源、HTTPS、反代、缓存	业务逻辑

协作关键点

• 契约先行：规范路由 + openapiPath/swaggerPath 直接产出文档，前端按文档联调，接口变更可评审、可版本化。
• 统一返回：{code,message,data} 结构 + 业务错误码表，前端只写一套解析。
• 鉴权与跨域：Token 由服务端签发校验（见鉴权章节）；跨域配置放 API 侧分组（见 CORS 章节），生产一般同域或 nginx 反代免跨域。
• 联调环境：开发期前端 dev server 代理到后端，避免本地被 CORS 折磨。

何时仍用框架渲染

• 一体化小项目/管理后台：gview 模板 + 静态文件由 ghttp 直接服务，一套进程搞定。
• 需要 SSR/SEO 或网关 BFF：GoFrame 做服务端聚合与首屏拼装再吐给前端。
• 关键判断：渲染与否不是框架能力问题，而是团队部署形态——分离架构就不让 GoFrame 碰静态与模板。

常见追问

• 追问：BFF 模式下 GoFrame 承担什么？——作为聚合层对外暴露前端友好的接口：内部调多个下游（gRPC/HTTP），做裁剪、合并、鉴权透传，业务规则仍在领域服务。
• 追问：接口变更怎么管理？——规范路由让“文档=代码”，评审 diff 即接口评审；破坏性变更走版本化路径前缀（/api/v1、/api/v2）。
• 追问：前端要自己处理错误文案吗？——后端给稳定 code + 展示文案，前端映射成提示；不要把内部异常细节暴露到契约里。

记忆点

• 分离架构下 GoFrame = API 工厂：契约、鉴权、业务、数据四件事；渲染能力留给需要它的场景。