Is your feature request related to a problem?

Option No

Describe the solution you'd like

这里记录一些非兼容性但确实值得改进的修改，便于未来评估是否值得作为大版本发布。

Describe alternatives you've considered

【设计】1. ORM操作强制增加ctx参数 ✅

目前ORM的Model操作并不强制需要ctx参数，虽然可以通过dao代码生成工具规范使用Ctx(ctx)方法创建Model对象，但这样不是很优雅。

同时ORM组件内部处理ctx性能不是很高效，ctx参数作为DB实现对象的属性保存了起来，如果作为方法参数传递，这样别扭的设计可以去掉，也可以简化逻辑处理。

【设计】2. http server slice参数传递方式与标准库统一

http server的slice参数传递参考的是PHP的习惯，通过k[]的方式传递，这块需要参考golang标准库实现，以便于更统一的Golang处理逻辑。

【设计】3. gtime.Format和标准库的time.Format不一致 ✅

目前gtime.Format参考的是PHP的时间格式化方式，但该方法与标准库的time.Format冲突，建议改名。

【解耦】4. 完整废除gredis组件

目前主库虽然已经通过接口化解耦了Redis组件的设计，但是仍然耦合较重。需要完整删除gredis组件，在主库使用Redis的组件中（例如gcache, gsession）增加对应的接口定义，具体的实现还是通过社区组件的形式来提供，但是需要提供十分简化的接口定义。

【性能】5. 去掉对GET Body的支持

GET Body通常不需要传递参数，去掉去掉对GET Body的支持以提高性能。

【性能】6. 不再默认允许Request Body可重复读

保留现有的可重复读设置方法，用户若有需要可以通过中间件设置可重复读。

【性能】7. HTTP Server仅支持Query String及表单类型参数自动解析

服务端需要根据客户端提交的ContentType来解析参数内容，客户端提交若无指定ContentType，那么不再自动解析提交参数。

【设计、易用性】8. HTTP Client不再支持@file的特殊参数名称方式

通过提供明确的方法来管理客户端的文件上传功能，而不是通过参数前缀的方式。

【设计】9. gjson组件需要明确职责仅作为json的扩展组件，不再支持xml/yaml等其他数据类型

• 可以考虑使用第三方的gjson组件，需要充分评估功能和性能对比。
• 若要支持其他数据类型，增加gparser组件，功能与现有gjson功能类似，但需要做减法，不能提供太多别名方法。

【设计】10. 评估去掉gres组件而直接使用embed.FS的可能性

embed.FS已被广泛使用，评估是否能直接替换到gres，降低框架职责。

【性能】11. 去掉内置的链路跟踪中间件，改为用户配置

• 由用户选择接入链路跟踪，不再内置链路跟踪判断逻辑（http/grpc client&server）。
• 现有的内置的traceid功能通过中间件方式提供，由用户自行选择配置。

【设计】12. gtype组件改为gatomic以更好明确组件职责 ✅

【性能】13. orm不再对参数中字段与表不存在字段做自动过滤功能，考虑让用户自定配置过滤策略

【性能】14. 评估去掉ORM的Safe功能，让开发者使用Clone功能来实现模型复用 ✅

【设计】15. 工具链所有生成的代码，默认加上.gen.go的文件名后缀

Additional

No response