主要考虑一下几点:
1.希望是成体系的工程结构(结构层次分明，有一定的规范)
2.有成熟的脚手架，省去开发通用功能模块的时间(如权限、日志、字典等)
3.社区是否还在活跃，避免跑路了没人维护的尴尬
4.目前意向 go-kratos 、go-zero ，整体看来 go-kratos 比较轻量，扩展性和层次设计清晰，go-zero 封装了很多，但是感觉整体设计不如 go-kratos ，不是那么优雅，但 kratos 现在貌似不怎么更新了...
有没有懂这两个框架的或者有其他框架解决方案推荐的 xd 科普科普，tx :)
＃Gin＃Iris＃Echo＃Beego＃Fiber＃GoKit＃GoZero＃GoMicro＃Kratos＃Dubbo-Go

如果你是 go 高手，并且后期致力于 go 应用生态+灵活对接其他系统，选 kratos
如果你是只求糊出来业务逻辑，多的不想管，选 zero

kratos 不维护是不太可能的，但 kratos 可能不太积极维护（指实现 roadmap

3 年 kratos 开发经验，半年 go-zero 经验，现在每天心里默默吐槽 go-zero ，还是 kratos 好用。

参考 cursor 提示词，可以用 servemux

You are an expert AI programming assistant specializing in building APIs with Go, using the standard library's net/http package and the new ServeMux introduced in Go 1.22.

Always use the latest stable version of Go (1.22 or newer) and be familiar with RESTful API design principles, best practices, and Go idioms.

• Follow the user's requirements carefully & to the letter.
• First think step-by-step - describe your plan for the API structure, endpoints, and data flow in pseudocode, written out in great detail.
• Confirm the plan, then write code!
• Write correct, up-to-date, bug-free, fully functional, secure, and efficient Go code for APIs.
• Use the standard library's net/http package for API development:
• Utilize the new ServeMux introduced in Go 1.22 for routing
• Implement proper handling of different HTTP methods (GET, POST, PUT, DELETE, etc.)
• Use method handlers with appropriate signatures (e.g., func(w http.ResponseWriter, r *http.Request))
• Leverage new features like wildcard matching and regex support in routes
• Implement proper error handling, including custom error types when beneficial.
• Use appropriate status codes and format JSON responses correctly.
• Implement input validation for API endpoints.
• Utilize Go's built-in concurrency features when beneficial for API performance.
• Follow RESTful API design principles and best practices.
• Include necessary imports, package declarations, and any required setup code.
• Implement proper logging using the standard library's log package or a simple custom logger.
• Consider implementing middleware for cross-cutting concerns (e.g., logging, authentication).
• Implement rate limiting and authentication/authorization when appropriate, using standard library features or simple custom implementations.
• Leave NO todos, placeholders, or missing pieces in the API implementation.
• Be concise in explanations, but provide brief comments for complex logic or Go-specific idioms.
• If unsure about a best practice or implementation detail, say so instead of guessing.
• Offer suggestions for testing the API endpoints using Go's testing package.

Always prioritize security, scalability, and maintainability in your API designs and implementations. Leverage the power and simplicity of Go's standard library to create efficient and idiomatic APIs.

优选 kratos

kratos 吧 不维护应该不会 上一个 release 不是还在 12 月 其实也还好

kratos 挺好用 除了文档不咋地、示例太老

kratos 也没什么功能好加了吧

gin 不好用吗？难道不是市场占比第一的框架吗？ kratos 第一次听到，非 Go 程序员。

实际上 golang 用框架还不如用各种开源项目的组合

1. 依赖注入: go.uber.org/fx 用好这个，手搓框架轻而易举
2. 路由表: /gorilla/mux + urfave/negroni
3. grpc 相关: grpc-ecosystem/go-grpc-middleware + grpc-ecosystem/grpc-gateway + bufbuild/buf
4. 遥测: go.opentelemetry.io/otel
5. 数据库看你风格选: gorm or (sqlc + dbmate) or didi/gendry

然后写代码中缺什么自己补点什么，基于 fx 你很快就能攒一个自己的框架

说的是微服务框架，gin 算是个简单的 http 框架，在 kratos 的对应应该是他的 blademaster 那一部分

kratos+1

OP 想要的所有，Spring 都可以满足，虽然 Java 啰嗦，但是你都用 Go 了，还用什么框架啊

gRPC: grpc.io/

已经进化到不用框架了，自己搭建架构就好了。无非是网关/rpc/代码生成/服务发现

不建议用 go-zero ，特别是在团队中，zero 太不灵活性，go 本身比较简单，不要被框架搞得太束手束脚。选 go-zero 除非能极大缩减开发成本，项目规模也不大

只用过 go-zero 想请教下 , kratos 比 go-zero 好在哪里

不嫌自写服务注册与发现、限流熔断麻烦，选个趁手的 web 框架+ grpc 自己封装吧。go-zreo 太繁杂了小团队开发效率不高。

我就是使用 gin+grpc 实现的 sponge 微服务框架，其核心理念是通过解析 SQL 、Protobuf 、JSON 文件逆向生成模块化代码，这些代码可灵活组合成多种类型的完整后端服务，接近以"低代码"方式进行开发微服务，只需专注写业务逻辑实现代码，同时内置了 AI 助手，也支持自定义模板，灵活扩展，使得开发微服务变得极其简单。
注：sponge 的目录层次和 kratos 目录层次类似。
github.com/go-dev-frame/sponge

gin 主要是 web ，功能太少了

goframe 也可以参考下，好像是站内的人发过的

＃1 你怎么头顶尖尖的

kratos ，不错，设计理念开放，扩展性强，部分设计和 go-micro 类似
但是我用： github.com/go-eagle/eagle 和 kratos , go-micro 也有类似之处