fix: issue4092

[wln32]

Fixes #4092 基础类型的切片数组，不再递归循环验证，防止一些基础类型切片容量过大导致内存泄漏，具体见issue

[gqcn]

• 针对[]string, []int等基础类型也不支持了吗？这样会有兼容问题的。
• 个人建议改进如下：
  • 针对太大块的提交内容，定义校验规则没有意义，建议使用侧去掉校验规则，
  • 组件增加对校验内容大小的限制，比如默认限制1K。

[wln32]

• 针对[]string, []int等基础类型也不支持了吗？这样会有兼容问题的。

• 个人建议改进如下：

  • 针对太大块的提交内容，定义校验规则没有意义，建议使用侧去掉校验规则，
  • 组件增加对校验内容大小的限制，比如默认限制1K。

1. 并不是注释那样，注释想说明的是当切片的元素类型为指针类型时，和原逻辑一样，需要循环逐个验证。
2. 其实仅就目前的规则来说，只有一个foreach规则会对切片类型进行循环验证，实现在 gf\util\gvalid\gvalid_validator_check_value.go:145行开始
3. 当切片元素类型非struct,map时，完全没有必要去循环验证
4. 建议对gvalid文档增加一些说明，规则可以作用于哪些类型
5. gvalid在性能方面可能不尽人意，相对于go-playground/validator来说有几十倍的差距.
6. 在ghttp中关于验证部分的逻辑直接写死了gvalid，go的其他主流框架，都有开放自定义模型验证这方面的接口
7. gvalid年久失修，在实现上也不易维护，建议抛弃掉现在的gvalid，改用go-playground/validator，或为框架提供一个可以自定义验证的接口

[LanceAdd]

是不是可以开个issue讨论下重新设计gvalid和gconv，印象中在好几个issue中都有讨论gvalid和gconv的性能问题，或者使用现成的社区方案，通过适配器去适配那些不错的社区库

[wln32]

是不是可以开个issue讨论下重新设计gvalid和gconv，印象中在好几个issue中都有讨论gvalid和gconv的性能问题，或者使用现成的社区方案，通过适配器去适配那些不错的社区库

gconv应该不用了，之前我重新实现过了，现在性能不成问题，主要是gvalid这个，年久失修，维护困难，性能落后