docs: optimized partial description

website-new/docs/guide/advance/plugins.mdx

@@ -14,11 +14,11 @@ import AfterUnmount from '@components/lifeCycle/\_afterUnmount.mdx';
 import ErrorUnmountApp from '@components/lifeCycle/\_errorUnmountApp.mdx';
 import OnNotMatchRouter from '@components/lifeCycle/\_onNotMatchRouter.mdx';
 
-Garfish 框架引入了插件化机制，目的是为了让开发者能够通过编写插件的方式扩展更多功能，或为自身业务定制个性化功能；同时框架的基础能力也都是通过插件机制来实现，确保框架核心足够精简和稳定。
+Garfish 框架引入了插件化机制，目的是为了让开发者能够通过编写插件的方式来扩展更多功能，或为自身业务定制个性化功能；同时框架的基础能力也都是通过插件机制来实现，确保框架核心足够精简和稳定。
 
 ## 插件能做什么
 
-插件的功能范围没有严格的限制——一般有下面两种：
+插件的功能范围没有严格的限制，一般有下面两种：
 
 1. 添加全局方法或增加默认参数
 2. 在应用的生命周期中自定义功能（例如：`Garfish router`、`Garfish sandbox`）

website-new/docs/guide/concept/buildConfig.md

@@ -65,9 +65,9 @@ new Function('require', 'exports', code)(fakeRequire, fakerExports);
 
 ## publicPath
 
-通过 `publicPath` 配置将微前端子应用的资源路径转换成绝对路径，为什么需要降子应用的资源路径转换成绝对路径呢？
+通过 `publicPath` 配置将微前端子应用的资源路径转换成绝对路径，为什么需要将子应用的资源路径转换成绝对路径呢？
 
 - 子应用在独立运行时，使用相对路径的接口时，接口请求的路径是，当前页面域名+相对路径
 - 但是在主应用时，子应用使用相对路径的接口，请求的路径按道理来说还是，当前域名+相对路径
 
-当在微前端的场景下如果 `Garfish` 让子应用走「当前域名+相对路径」会发生更多的异常请求（`hmr` 热更新、`websocket`、`server worker` ...），因为子应用的域名并不一定是与主应用一致，因此 `Garfish` 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，子应用的入口有可能会走 `CDN`。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 `CDN` 前缀。这一块做了很对权衡，因为 `hmr`、`websocket`、`server worker` 这些内容可能难以被用户控制，所以默认走的还是修正模式。
+当在微前端的场景下如果 `Garfish` 让子应用走「当前域名+相对路径」会发生更多的异常请求（`hmr` 热更新、`websocket`、`server worker` ...），因为子应用的域名并不一定是与主应用一致，因此 `Garfish` 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，子应用的入口有可能会走 `CDN`。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 `CDN` 前缀。这一块做了很多权衡，因为 `hmr`、`websocket`、`server worker` 这些内容可能难以被用户控制，所以默认走的还是修正模式。

website-new/docs/issues/index.mdx

@@ -215,7 +215,7 @@ export const provider = () => {
 1. 子应用在独立运行时，使用相对路径的接口，接口请求的路径是，当前页面域名+相对路径
 2. 但是在主应用时，子应用使用相对路径的接口，请求的路径按道理来说还是，当前域名+相对路径
 
-当在微前端的场景下如果 Garfish 让子应用走「当前域名+相对路径」会发生更多的异常请求（hmr 热更新、websock、server worker ...），因为子应用的域名并不一定是与主应用一致，因此 Garfish 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，Goofy web 为了提升子应用资源加载的性能，子应用的入口会走 CDN。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 CDN 前缀。这一块做了很对权衡，因为 hmr、websock、server worker 这些内容可能难以被用户控制，所以默认走的还是修正模式。
+当在微前端的场景下如果 Garfish 让子应用走「当前域名+相对路径」会发生更多的异常请求（hmr 热更新、websock、server worker ...），因为子应用的域名并不一定是与主应用一致，因此 Garfish 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，Goofy web 为了提升子应用资源加载的性能，子应用的入口会走 CDN。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 CDN 前缀。这一块做了很多权衡，因为 hmr、websock、server worker 这些内容可能难以被用户控制，所以默认走的还是修正模式。
 
 ## 为什么主应用仅支持 history 模式？
 

website/docs/guide/advance/plugins.md

@@ -18,11 +18,11 @@ import AfterUnmount from '@site/src/components/lifeCycle/\_afterUnmount.mdx';
 import ErrorUnmountApp from '@site/src/components/lifeCycle/\_errorUnmountApp.mdx';
 import OnNotMatchRouter from '@site/src/components/lifeCycle/\_onNotMatchRouter.mdx';
 
-Garfish 框架引入了插件化机制，目的是为了让开发者能够通过编写插件的方式扩展更多功能，或为自身业务定制个性化功能；同时框架的基础能力也都是通过插件机制来实现，确保框架核心足够精简和稳定。
+Garfish 框架引入了插件化机制，目的是为了让开发者能够通过编写插件的方式来扩展更多功能，或为自身业务定制个性化功能；同时框架的基础能力也都是通过插件机制来实现，确保框架核心足够精简和稳定。
 
 ## 插件能做什么
 
-插件的功能范围没有严格的限制——一般有下面两种：
+插件的功能范围没有严格的限制，一般有下面两种：
 
 1. 添加全局方法或增加默认参数
 2. 在应用的生命周期中自定义功能（例如：`Garfish router`、`Garfish sandbox`）

website/docs/guide/concept/buildConfig.md

@@ -69,9 +69,9 @@ new Function('require', 'exports', code)(fakeRequire, fakerExports);
 
 ## publicPath
 
-通过 `publicPath` 配置将微前端子应用的资源路径转换成绝对路径，为什么需要降子应用的资源路径转换成绝对路径呢？
+通过 `publicPath` 配置将微前端子应用的资源路径转换成绝对路径，为什么需要将子应用的资源路径转换成绝对路径呢？
 
 - 子应用在独立运行时，使用相对路径的接口时，接口请求的路径是，当前页面域名+相对路径
 - 但是在主应用时，子应用使用相对路径的接口，请求的路径按道理来说还是，当前域名+相对路径
 
-当在微前端的场景下如果 `Garfish` 让子应用走「当前域名+相对路径」会发生更多的异常请求（`hmr` 热更新、`websocket`、`server worker` ...），因为子应用的域名并不一定是与主应用一致，因此 `Garfish` 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，子应用的入口有可能会走 `CDN`。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 `CDN` 前缀。这一块做了很对权衡，因为 `hmr`、`websocket`、`server worker` 这些内容可能难以被用户控制，所以默认走的还是修正模式。
+当在微前端的场景下如果 `Garfish` 让子应用走「当前域名+相对路径」会发生更多的异常请求（`hmr` 热更新、`websocket`、`server worker` ...），因为子应用的域名并不一定是与主应用一致，因此 `Garfish` 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，子应用的入口有可能会走 `CDN`。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 `CDN` 前缀。这一块做了很多权衡，因为 `hmr`、`websocket`、`server worker` 这些内容可能难以被用户控制，所以默认走的还是修正模式。

website/docs/issues/childApp.md

@@ -219,7 +219,7 @@ export const provider = () => {
 1. 子应用在独立运行时，使用相对路径的接口，接口请求的路径是，当前页面域名+相对路径
 2. 但是在主应用时，子应用使用相对路径的接口，请求的路径按道理来说还是，当前域名+相对路径
 
-当在微前端的场景下如果 Garfish 让子应用走「当前域名+相对路径」会发生更多的异常请求（hmr 热更新、websock、server worker ...），因为子应用的域名并不一定是与主应用一致，因此 Garfish 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，Goofy web 为了提升子应用资源加载的性能，子应用的入口会走 CDN。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 CDN 前缀。这一块做了很对权衡，因为 hmr、websock、server worker 这些内容可能难以被用户控制，所以默认走的还是修正模式。
+当在微前端的场景下如果 Garfish 让子应用走「当前域名+相对路径」会发生更多的异常请求（hmr 热更新、websock、server worker ...），因为子应用的域名并不一定是与主应用一致，因此 Garfish 框架会对相对路径的资源和请求去进行修正，修正的参照物为基础域名为子应用的路径，在本地开发时可能是正常的，但是发到线上出现问题，原因在于发布到线上之后，Goofy web 为了提升子应用资源加载的性能，子应用的入口会走 CDN。因此参照的基础路径就变为了 CDN 前缀。那么此时子应用的相对路径请求就变为了 CDN 前缀。这一块做了很多权衡，因为 hmr、websock、server worker 这些内容可能难以被用户控制，所以默认走的还是修正模式。
 
 ## 为什么主应用仅支持 history 模式？