Lance Add

已经解决，修改 ``` themes/Cxo/layout/includes/partial/footer.pug ``` 在马赛克处添加备案号即可 

Why is the nacos sdk referenced differently in "github.com/gogf/gf/contrib/config/nacos/v2" and "github.com/gogf/gf/contrib/registry/nacos/v2" > github.com/gogf/gf/contrib/registry/nacos/v2 ``` github.com/joy999/nacos-sdk-go ``` > github.com/gogf/gf/contrib/config/nacos/v2 ``` github.com/nacos-group/nacos-sdk-go/v2 ``` This leads to duplicate registrations when obtaining remote configuration...

> Have you solved this problem？ I used `github.com/nacos-group/nacos-sdk-go/v2` instead of `github.com/joy999/nacos-sdk-go`, and then combined it with the content of `github.com/gogf/gf/contrib/registry/nacos/v2` to write my own library `https://github.com/LanceAdd/nacos-gf` I hope it...

> Same problem The reason for this problem is that nacos-sdk-go is used in `config` and `registry`, `github.com/nacos-group/nacos-sdk-go/v2` is used in config, but `github.com/joy999/nacos-sdk-go` is used in registry, which causes...

I used `github.com/nacos-group/nacos-sdk-go/v2` instead of `github.com/joy999/nacos-sdk-go`, and then combined it with the content of `github.com/gogf/gf/contrib/registry/nacos/v2` `github.com/gogf/gf/contrib/config/nacos/v2` to write library https://github.com/LanceAdd/nacos-gf as a temporary solution. I hope it can help you.

@wwwfeng 我知道改成get是会去处理查询的参数，但是我现在遇到的情况是需要post/put/patch这三类 现在就是在post的请求下，同时有查询参数、路径参数、请求体参数三种参数时，这时候并不会构建查询参数，只会处理路径参数和请求体参数，我希望他能在post中也去构建查询参数，使用tag标记下就可以区分，想问下这个在实现的时候是故意这么设计的还是没处理，如果只是没处理我就提个PR处理下

我看着这个DoRequestObj的注释上也说`DoRequestObj does HTTP request using standard request/response object.`但是其中的参数并未严格按照规范路由的解析流程，应该用tag标注出来每个参数是路径参数/查询参数/请求体参数然后再去解析这些吧

> > @wwwfeng 我知道改成get是会去处理查询的参数，但是我现在遇到的情况是需要post/put/patch这三类 现在就是在post的请求下，同时有查询参数、路径参数、请求体参数三种参数时，这时候并不会构建查询参数，只会处理路径参数和请求体参数，我希望他能在post中也去构建查询参数，使用tag标记下就可以区分，想问下这个在实现的时候是故意这么设计的还是没处理，如果只是没处理我就提个PR处理下 > > 你好，目前`DoRequestObj`只会处理`path`和`body`参数，不会对请求结构体中的`in`标签进行解析，若有需要环境提pr来支持。 你好，我在修改现有DoRequestObj 支持这个issues，我个人希望直接使用规范路由请求体作为DoRequestObj的参数，这样方便大家在微服务远程调用中直接使用请求目标项目的req entity，现在其中关于上传文件这部分，现有DoRequestObj底层和其他request一样的`prepareRequest`，使用`@file:`, `"upload-file=@file:"+path`这样的形式进行支持，但是规范路由中则是通过`ghttp.UploadFile`和`ghttp.UploadFiles`配合tag中`type:file`使用，是否需要保留现有的`@file`形式，我个人觉得DoRequestObj没必要去兼容这样的形式，但是不清楚大家有没有其他的想法，想问下各位

1. V3是否能提供一些系统事件，例如配置文件变更后时其他组件能够感知到变化，或者RegisterXXXHandler这种也行。这个来源于我之前对gredis进行改造的经历（看安排gredis是要删除了），使用本地配置文件（fileAdapter或者contentAdapter）或者使用nacos远程配置文件时如果配置文件发生变化只会刷新全局缓存，redis的client缓存实际上不会发生变化，过时client仍然可以使用，查看代码后发现gredis有自己局部缓存，client和config都有局部缓存，client的缓存localInstances初始化后就不会删除了，每次构建client都要来捞一下localConfigMap，但是实际上这个缓存一直是空的，从来没有往里面塞过值（感觉像是忘了这个缓存），后来我提交过nacos的onchange回调的PR允许远程配置文件变更后自定义一些处理，又因为没法用pipeline我就做了个简化版[https://github.com/LanceAdd/gredis](https://github.com/LanceAdd/gredis) 替代然后配合nacos的onchange实时刷新。但是使用本地配置文件时仍然是没有感知能力的。 2. 其他的一些系统状态变更应该也有类似的问题 3. 当然了在运行时去改变正在使用的例造成的压力和竞争问题需要另外衡量讨论了

> 鉴于g包默认引入了多个包，应当谨慎在内部使用g包。 建议考虑一下针对g包的文档说明，明确提醒引入g包会有不少依赖被引入到编译当中。 > >  目前各个组件都是尽可能解耦，我觉的应该推荐大家直接使用具体组件，g包应该仅用于简化原本golang的各种繁琐操作或者一些常用的便捷操作，我在内部魔改gf做一些基础设施的时候是完全禁止他们通过g包去使用gf的其他组件的功能，至少在魔改的时候出的问题会少点，不知道其他人有没遇到过这种的