feat: update doc with build config

website/docs/guide/concept/buildConfig.md

@@ -65,13 +65,13 @@ new Function('require', 'exports', code)(fakeRequire, fakerExports);
 
 > `jsonpFunction` 配置的作用
 
-`jsonpFunction` 的配置主要也与沙箱的机制有关， `Garfish` 的沙箱子应用的执行上下文 `window` 主要来自于主应用，当主应用与子应用都是用相同的 `key` 作为子应用 `jsonp` 存储 `chunk` 的方式时，子应用的 `chunk` 可能会受到主应用和其他应用的影响，因此通过 `jsonpFunction` 配置能够避免应用间的 `chunk` 互相应用
+`jsonpFunction` 的配置主要也与沙箱的机制有关， `Garfish` 的沙箱子应用的执行上下文 `window` 主要来自于主应用，当主应用与子应用都是用相同的 `key` 来作为子应用 `jsonp` 存储 `chunk` 的方式时，子应用的 `chunk` 可能会受到主应用和其他应用的影响，因此通过 `jsonpFunction` 配置能够避免应用间的 `chunk` 互相应用
 
 ## 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` 这些内容可能难以被用户控制，所以默认走的还是修正模式。