gres.Contains: features some optimization suggestions

[zhangwebb]

Is your feature request related to a problem?

Option Yes

Describe the solution you'd like

Go version
go version go1.24.2 windows/amd64

GoFrame version
v2.9.0

I have been learning about the static file service function of GF framework recently and have encountered a problem with how to set up ServerRoot.

我最近在学习GF框架的静态文件服务功能，在如何设置 ServerRoot 那里遇到了问题。

I want to set a relative path for ServerRoot, such as: / www/html。
After compiling and running, I found that whether I use config. toml or s. Set Server Root(), it ultimately resolves to the source code path set during development!
I am very puzzled ...

我想给ServerRoot设置一个相对路径，如：./www/html。
编译后运行，发现无论我用 config.toml 还是 s.SetServerRoot()，它最终都解析设置到开发时的源码路径下！
就非常疑惑……

My expectation is that no matter where my application is placed, it should resolve to a sub path in the directory where the program is currently running.
I have made various attempts to compare and found that when the relative path is set to the style of "www/html" (note not to include the "./" prefix), it meets expectations

我的预期是，无论我的应用程序放到哪里，应当解析到程序当前运行的目录下的子路径。
我进行了各种尝试对比，发现当设置为“www/html”（注意不带“./”前缀）这种样式的相对路径时，就符合预期了……

Describe alternatives you've considered

After consulting in the group without success, I looked at the source code and finally learned the reason:

When creating a g.Server() instance, gres.Contains(...) Check if the ServerRoot path exists in the resource list packaged in the gf pack:
-If available, use it;
-If not, it will go through again gfile.Search(...) attempts to search for

gfile.Search defaults to including the current directory, running directory, and main function directory. It is precisely this [MainPkgPath] that naturally exists as a ServerRoot! So it caused me confusion above, mistakenly thinking that the compile time path was cached.
Although by reviewing the source code, we can understand what was done behind the scenes and avoid misunderstandings by modifying settings. However, we still believe that there is room for further optimization and improvement. Here are some suggestions:

1. The gres.Containers(...) method should be compatible with relative path writing with prefixes such as "./www/html".
2. In the 'Resource Management - Best Practices' section of the GF document, emphasis should be placed on explaining the issues that may arise from differences in the development and operation environment regarding the Server Root path setting and search mechanism, in order to avoid similar situations from recurring.
3. gfile.MainPkgPath() determines the source code development environment through runtime.GOROOT(), right? Go 1.24 has been marked as deprecated. In the new code, it is recommended to use the system path to find the "go" binary file and use the "go env GOROOT" to find its GOROOT.

在群里咨询无果，我就看了下源码，最终了解到原因：

g.Server()实例在创建时，会使用 gres.Contains(...) 检查 ServerRoot 路径是否存在于 gf pack 打包的资源列表中：

• 如果有就使用；
• 如果没有，会再次通过gfile.Search(...) 尝试搜索……

gfile.Search 默认包含当前目录、运行目录、主函数目录，正是这个【主函数目录（MainPkgPath）】，它当然存在 ServerRoot 了！所以造成我上面的困惑，误以为缓存了编译时的路径。
虽然通过查看源码，了解背后做了什么能通过修改设置规避误区，但还是觉得能再优化做点什么，建议如下：

1、gres.Contains(...)方法，应兼容形如"./www/html"这种带"./"前缀的相对路径写法。
2、在gf文档的【资源管理-最佳实践】里，应增加对 ServerRoot 路径设置、搜索机制因开发运行环境差异可能导致的问题做强调说明，避免类似情况再次踩坑。
3、gfile.MainPkgPath() 判断源代码开发环境，是通过runtime.GOROOT()吧？Go 1.24里已经标记弃用了，新的代码中建议使用系统路径来查找“go”二进制文件，并使用 go env GOROOT 来查找其 GOROOT。

Additional

No response