框架对比

本页只对比框架自身或官方维护能力，不把零散社区包算成框架内置能力，表格里的“有”只表示官方能力存在，不代表默认更适合你的项目。

对比范围

这里分两类看，先看更接近业务工程的框架，再看纯 HTTP 路由类框架：

• 工程框架类：GoFrame、go-zero、Kratos、Beego、Buffalo、Runa
• HTTP 路由类：Gin、Echo、Fiber、Chi、Hertz

表格里的固定口径：

• 内置：框架本体提供
• 官方模块：由官方包提供，需要按需安装或接入
• 工具链：通过官方 CLI、代码生成或脚手架提供
• 自行组合：框架没有统一能力，项目自己选择第三方包
• 规划中：Runa 文档中明确规划，但当前不当作已完成能力

Runa 更接近第二类，但它不是一体化全家桶，而是微内核加按需能力。

架构模式对比

定位对比

工程和全栈框架

HTTP 路由类框架

Runa 现在明确有

• 应用入口、默认应用、全局 DI、命令入口和统一生命周期
• Module 业务模块入口
• route HTTP 路由、分组、域、中间件、请求上下文、错误渲染
• ws WebSocket Hub、频道订阅、广播和 Redis 横向扩展
• jsonrpc JSON-RPC 2.0 服务端，可运行在 HTTP 或 WebSocket 上
• 强类型 Input / Output handler、显式验证、结构化路由元数据
• OpenAPI 文档生成、Resource 资源路由、CRUD Builder
• cache、database、queue、session、auth、storage、log、lock、rate、event、task、schedule、message、view、asset 等能力模块
• redis、s3、oro、nats、amqp、mqtt 等可选驱动模块
• 审计、观测、集群、控制台等配套能力

Runa 的选型边界

• 性能目标：优先保证业务编排、模块化和可维护性，不把极限 HTTP benchmark 放在第一位
• 中间件生态：可复用 net/http 官方生态和通用中间件，框架专属中间件生态仍在早期
• 组件规模：采用按需能力模型，不走 GoFrame 那种完整一体化组件路线
• 代码生成：已有 devtools 脚手架和 embed 命令，当前没有 go-zero 那种完整 API/RPC 代码生成体系
• gRPC 传输：当前仍是规划中，已实现的是 HTTP、WebSocket 和 JSON-RPC 相关能力
• 前端流水线：聚焦 Go 业务服务端，不内置 Rails/Buffalo 风格的完整前端资产流水线

怎么选择

如果你只想替换一个路由器，并且最看重框架专属中间件生态或纯 HTTP benchmark，Gin、Echo、Fiber、Chi、Hertz 更直接。 如果你想要内置大而全的一体化框架，GoFrame、Beego、Buffalo 更接近。 如果你做 API/RPC 微服务，并且接受生成式工程结构，go-zero、Kratos、Hertz 更匹配。 如果你希望从微项目开始，用同一套应用入口、生命周期、DI、Module、路由、OpenAPI、资源路由、CRUD 和可选能力逐步扩展到企业级业务系统，Runa 更合适。

参考来源

• Gin 官方文档：https://gin-gonic.com/en/docs/
• Echo 官方网站：https://echo.labstack.com/
• Fiber 官方文档：https://docs.gofiber.io/
• Chi README：https://github.com/go-chi/chi
• CloudWeGo Hertz 文档：https://www.cloudwego.io/docs/hertz/
• GoFrame 文档：https://goframe.org/
• go-zero 文档：https://go-zero.dev/
• Kratos 文档：https://go-kratos.dev/docs/
• Beego 文档：https://beegodoc.com/
• Buffalo 官方网站：https://gobuffalo.io/