Lance Add

1. 强化`规范路由`的要求，不应该由框架自行尝试解析没有明确标注参数类型和位置的参数(path/query/header/body parameter），应该强制要求开发者在tag中指定参数位置 2. 强化 `gclient`对`规范路由`标准支持

增强远程配置中心支持，主要是`gcfg`对远程多配置文件的支持，目前`gcfg`只支持获取指定名称的本地配置文件，以目前现有`github.com/gogf/gf/contrib/config/nacos/v2`的为例，在不修改`gcfg`代码的情况下，只能使用底层sdk`github.com/nacos-group/nacos-sdk-go/v2`写代码定制和维护多个远程配置文件的缓存以及事件回调，这背离了`gcfg`作为全局配置实例的初衷。其他几个远程配置文件中心的社区组件应该也有类似的问题。

适配Seata分布式事务或者DTM

我之前也准备提交这个，但是群里说gredis作为抽象层不应该暴露go-redis驱动的相关引用就放弃了，我现在是自定义了一个gredis，只保留了gins里对redis配置文件参数的解析和客户端的初始化还有多配置redis客户端获取，这样就能直接用go-redis驱动的方法，我看V3的计划表里也有删除gredis的意向，等等，我最近好像在某个isssues里也回复过老哥？？

> @LanceAdd @cyjaysong 看看这样折中解决行不行。https://github.com/gogf/gf/pull/4306/files#diff-27ba9cb3e60614ccdd6a2e5cdc82825ee6b1db0b8957c37fdbfa179cfd4ccd61R66 我觉得可以，我自己是单独实现了一个获取底层client的package [raw-gredis](https://github.com/LanceAdd/gredis/blob/main/gredis.go)

先暂时用lua脚本吧, 我正在尝试改造`database/gredis`和`contrib/nosql/redis`这俩模块，如果想用底层驱动`github.com/redis/go-redis/v9`的原生pipeline的功能就得在`database/gredis`里import这个驱动，但是gredis算是抽象出来的又不能暴露底层驱动的东西，但是如果我在gredis里重新抽象出来IGroupPipline的interface，里面所有get/set/hash操作都实现一遍工程量又有点大，没法复用当前已有的封装，有点纠结，或者在闭包里拦截 UniversalClient.Do生成的redis命令又不太做的到，等本菜鸡再想想怎么弄或者再看看其他大佬的方案 

> 我们这个redis是集群是阿里云魔改的，不支持用lua > […](#) > > ---- 回复的原邮件 ---- > | 发件人 | Lance ***@***.***> | > | 发送日期 | 2025年06月13日 10:17 | > | 收件人 | gogf/gf ***@***.***> |...

没复现出来，源码也没找到=`len(newWhere)>0时，直接返回"1"。`这个，有具体表结构和代码吗

这个没啥必要，我之前加这个onchange回调的时候考虑过这个，按照gf的设计来说，每个组件都是解耦的，如果有需要组件应该自己缓存自己需要的旧配置内容，配置更新了onchange里带着新配置通知下就行，剩下的让具体组件自己决定要干嘛，目前V3 plan下面大家也提出了增强感知需求，就是不知道会不会通过

> @ppanphper @LanceAdd 可以让用户自定义`c.config.ConfigParam.OnChange`，这样更灵活一些。 我们后来搞了这个， https://github.com/gogf/gf/pull/4446