fix docs

docs/zh/guide/best-practices/performance.md

@@ -4,26 +4,26 @@
 
 我们可以通过 `xmake -j N` 指定同时构建的任务并行度，来加速编译。
 
-不过默认情况下，Xmake 已经开启此特性，会自动根据当前机器的 CPU Core 资源来自动评估分配需要并行的任务数。
+不过默认情况下，Xmake 已经开启此特性，会自动根据当前机器的 CPU Core 资源自动评估并分配需要并行的任务数。
 
 ## 编译缓存加速
 
 Xmake 默认开启了本地编译缓存，这在 Linux/macOS 上提速效果非常明显。
 
-不过在 Windows 上由于启动进程太重，并且 msvc 内置的预处理器太慢，因此目前默认对 msvc 禁用了本地缓存。
+不过在 Windows 上，由于启动进程太重，并且 msvc 内置的预处理器太慢，因此目前默认对 msvc 禁用了本地缓存。
 
-另外，除了本地缓存，Xmake 还提供远程缓存的支持，这在多台机器上共享编译缓存时非常有用。
+另外，除了本地缓存，Xmake 还提供远程缓存支持，这在多台机器上共享编译缓存时非常有用。
 
 关于这个特性的详细介绍，可以看下文档：[编译缓存](/zh/guide/extras/build-cache)。
 
 ## Unity Build 编译加速
 
-对于 C++ 构建，我们还可以配置开启 Unity Build 编译，将多个 C++ 源码合并到一个源文件中去编译，来减少头文件的解析时间，效果也比较明显。
+对于 C++ 构建，我们还可以配置开启 Unity Build 编译，将多个 C++ 源码合并到一个源文件中进行编译，以减少头文件的解析时间，效果也比较明显。
 
-详情见：[Unity Build 编译](/zh/guide/extras/unity-build)
+详情见：[Unity Build 编译](/zh/guide/extras/unity-build)。
 
 ## 分布式编译
 
 对于超大型的工程，我们还可以通过增加多台编译服务器，通过分布式编译特性来加速编译。
 
-详情见：[分布式编译](/zh/guide/extras/distributed-compilation)
+详情见：[分布式编译](/zh/guide/extras/distributed-compilation)。

docs/zh/guide/extensions/builtin-plugins.md

@@ -8,13 +8,13 @@ outline: deep
 
 ### 简介
 
-XMake跟`cmake`, `premake`等其他一些构建工具的区别在于：
+XMake 跟 `cmake`、`premake` 等其他一些构建工具的区别在于：
 
 ::: tip 注意
-`xmake` 默认是直接构建运行的，生成第三方的IDE的工程文件仅仅作为`插件`来提供。
+`xmake` 默认是直接构建运行的，生成第三方 IDE 的工程文件仅仅作为 `插件` 来提供。
 :::
 
-这样做的一个好处是：插件更加容易扩展，维护也更加独立和方便。
+这样做的一个好处是：插件更容易扩展，维护也更加独立和方便。
 
 ### 生成 Makefile {#generate-makefile}
 
@@ -42,7 +42,7 @@ $ xmake project -k compiler_flags
 
 ### 生成 compile_commands {#generate-compile-commands}
 
-导出每个源文件的编译信息，生成基于clang的编译数据库文件，json格式，可用于跟ide，编辑器，静态分析工具进行交互。
+导出每个源文件的编译信息，生成基于 clang 的编译数据库文件，json 格式，可用于与 IDE、编辑器、静态分析工具进行交互。
 
 ```sh
 $ xmake project -k compile_commands
@@ -60,15 +60,15 @@ $ xmake project -k compile_commands
 
 ```
 
-对于`compile_commands`的详细说明见：[JSONCompilationDatabase](https://clang.llvm.org/docs/JSONCompilationDatabase.html)
+对于 `compile_commands` 的详细说明见：[JSONCompilationDatabase](https://clang.llvm.org/docs/JSONCompilationDatabase.html)
 
 ### 生成 Xcode 工程文件 {#generate-xcode-project}
 
-当前历史版本是利用 CMake 来生成的 Xcode 工程，不过最新的 dev 版本，也就是后续即将发布的 3.0.1 版本，将会带来原生的 Xcode 生成器。
+目前历史版本是利用 CMake 来生成的 Xcode 工程，不过最新的 dev 版本，也就是后续即将发布的 3.0.1 版本，将会带来原生的 Xcode 生成器。
 
-如果想要提前体验，可以更新到 xmake dev 版本尝试，`xmake update -s dev`。
+如果想要提前体验，可以更新到 xmake dev 版本试用，`xmake update -s dev`。
 
-具体详情见：[#4810](https://github.com/xmake-io/xmake/issues/4810)。
+具体详情见：[issue #4810](https://github.com/xmake-io/xmake/issues/4810)。
 
 ```sh
 $ xmake project -k xcode
@@ -78,7 +78,7 @@ $ xmake project -k xcode
 
 #### 使用 xmake 集成编译 {#geneerate-vsxmake}
 
-v2.2.8以上版本，提供了新版本的vs工程生成插件扩展，跟之前的生成vs的插件处理模式上有很大的不同，之前生成的vs工程是把所有文件的编译展开后，转交给vs来处理编译。
+v2.2.8以上版本，提供了新版本的vs工程生成插件扩展，与之前的生成vs的插件处理模式有很大不同，之前生成的vs工程是把所有文件的编译展开后，转交给vs来处理编译。
 
 但是这种模式，对xmake的rules是没法支持的。因为xmake的rules里面用了很多的`on_build`此类自定义脚本，无法展开，所以像qt， wdk此类的项目就没法支持导出到vs里面进行编译了。
 
@@ -102,7 +102,7 @@ $ xmake project -k vsxmake -m "debug,release"
 
 ![](/assets/img/manual/property_page_vsxmake.png)
 
-v2.5.1 版本提供了一个 `add_rules("plugin.vsxmake.autoupdate")` 规则，如果应用此规则，生产的vs工程在编译完成后，会检测 xmake.lua 和代码文件列表的改动，如果有变化，就会自动更新 vs 工程。
+v2.5.1 版本提供了一个 `add_rules("plugin.vsxmake.autoupdate")` 规则，如果应用此规则，生成的vs工程在编译完成后，会检测 xmake.lua 和代码文件列表的改动，如果有变化，就会自动更新 vs 工程。
 
 ```lua
 add_rules("plugin.vsxmake.autoupdate")
@@ -111,7 +111,7 @@ target("test")
     add_files("src/*.c")
 ```
 
-另外，我们可以通过 `set_group` 接口对每个 target 设置分组，使得生成的 vs 工程可以按指定结构进行分组。更多详情见：[issue 1026](https://github.com/xmake-io/xmake/issues/1026)
+另外，我们可以通过 `set_group` 接口对每个 target 设置分组，使得生成的 vs 工程可以按指定结构进行分组。更多详情见：[issue #1026](https://github.com/xmake-io/xmake/issues/1026)
 
 #### 使用 vs 内置编译机制 {#generate-vs}
 
@@ -138,7 +138,7 @@ $ xmake project -k vs2017 -m "debug,release"
 add_rules("mode.debug", "mode.release")
 ```
 
-另外，我们可以通过 `set_group` 接口对每个 target 设置分组，使得生成的 vs 工程可以按指定结构进行分组。更多详情见：[issue 1026](https://github.com/xmake-io/xmake/issues/1026)
+另外，我们可以通过 `set_group` 接口对每个 target 设置分组，使得生成的 vs 工程可以按指定结构进行分组。更多详情见：[issue #1026](https://github.com/xmake-io/xmake/issues/1026)
 
 ## 运行自定义 lua 脚本 {#run-lua-scripts}
 
@@ -189,7 +189,7 @@ $ xmake lua versioninfo
 
 ### 运行交互命令 (REPL)
 
-有时候在交互模式下，运行命令更加的方便测试和验证一些模块和api，也更加的灵活，不需要再去额外写一个脚本文件来加载。
+有时候在交互模式下，运行命令更加方便测试和验证一些模块和 API，也更加灵活，不需要再去额外写一个脚本文件来加载。
 
 我们先看下，如何进入交互模式：
 

docs/zh/guide/extensions/ide-integration-plugins.md

@@ -6,25 +6,25 @@
 
 <img src="https://raw.githubusercontent.com/xmake-io/xmake-vscode/master/res/problem.gif" width="650px" />
 
-[VSCode](https://code.visualstudio.com/)是常用的文本编辑器，xmake提供了插件支持。
+[VSCode](https://code.visualstudio.com/) 是常用的文本编辑器，xmake 提供了插件支持。
 
 ### 插件安装
 
-由于VSCode本身只提供了文本编辑的功能，我们需要安装插件以支持配置，编译，调试，语法提示等功能:
+由于 VSCode 本身只提供了文本编辑功能，我们需要安装插件以支持配置、编译、调试、语法提示等功能：
 
 * XMake
 * C/C++
 * CodeLLDB
 
-在完成插件的安装后，重启VSCode可以看到下方的状态栏:
+在完成插件的安装后，重启 VSCode 可以看到下方的状态栏：
 
 ![](/assets/img/guide/vscode_status_bar.png)
 
-可以在状态栏设置平台，架构，编译模式，工具链等选项，随后点击Build开始构建。
+可以在状态栏设置平台、架构、编译模式、工具链等选项，随后点击 Build 开始构建。
 
 ### 自定义选项
 
-如果这些选项不够，可以创建.vscode/settings.json并编写xmake需要的设置，如
+如果这些选项不够，可以创建 .vscode/settings.json 并编写 xmake 需要的设置，如：
 
 ```
 {
@@ -36,13 +36,13 @@
 }
 ```
 
-其他xmake的选项也同样可以在settings.json中完成设置。修改后可通过 >XMake: Configure 命令刷新配置。
+其他 xmake 的选项也同样可以在 settings.json 中完成设置。修改后可通过 >XMake: Configure 命令刷新配置。
 
 ### 配置 IntelliSense {#intellisense}
 
-为了更好的 C++ 语法提示体验，xmake提供了对[Language Server Protocol](https://microsoft.github.io/language-server-protocol/)（简称LSP）的支持。
+为了更好的 C++ 语法提示体验，xmake 提供了对 [Language Server Protocol](https://microsoft.github.io/language-server-protocol/)（简称 LSP）的支持。
 
-在 vscode 中，我们可以通过使用 vscode-cpptools 或者 clangd 来提供 intellisense 支持。
+在 VSCode 中，我们可以通过使用 vscode-cpptools 或 clangd 来提供 intellisense 支持。
 
 另外，为了支持 intellisense，xmake 提供了 compile_commands.json 的生成支持。
 
@@ -56,11 +56,11 @@
 
 ##### 手动触发生成
 
-当然，如果没看到文件被生成，我们也可以在 vscode 中，可以使用 `>XMake: UpdateIntellisense` 命令手动触发生成 .vscode/compile_commands.json。
+当然，如果没看到文件被生成，我们也可以在 VSCode 中，使用 `>XMake: UpdateIntellisense` 命令手动触发生成 .vscode/compile_commands.json。
 
 ##### 配置 xmake.lua 自动生成
 
-或者，我们也可以使用这个规则来自动更新生成 compile_commandss.json
+或者，我们也可以使用这个规则来自自动更新生成 compile_commands.json
 
 ```lua
 add_rules("plugin.compile_commands.autoupdate", {outputdir = ".vscode"})
@@ -81,9 +81,9 @@ $ xmake project -k compile_commands .vscode
 
 #### vscode-cpptools
 
-如果我们使用 vscode-cpptools 插件来提供 intellisense 支持，需要先去 vscode 插件市场，搜下 C++，默认第一个插件就是，安装下。
+如果我们使用 vscode-cpptools 插件来提供 intellisense 支持，需要先去 VSCode 插件市场，搜索 C++，默认第一个插件就是，安装即可。
 
-装完后，这个插件提供了 intellisense 和 调试支持。
+安装后，这个插件提供了 intellisense 和调试支持。
 
 然后，我们需要配置下 c_cpp_properties.json 文件，关联上我们生成的 `.vscode/compile_commands.json`。
 
@@ -123,16 +123,16 @@ $ xmake project -k compile_commands .vscode
 - https://code.visualstudio.com/docs/cpp/configure-intellisense-crosscompilation
 - https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference
 
-当然，理论上可以做到 xmake-vscode 插件自动关联设置这个文件，但是考虑到用户不一定使用 cpptools，有可能还会使用 clangd。
+当然，理论上可以做到 xmake-vscode 插件自动关联设置这个文件，但考虑到用户不一定使用 cpptools，也有可能会使用 clangd。
 
-因此，默认自动配置并不是很好，而且作者暂时也没时间精力去改进它。
+因此，默认自动配置并不是很好，而且作者暂时也没有时间和精力去改进它。
 
 #### clangd
 
-与此同时，我们可以选择安装支持 LSP 的语法提示插件，如 LLVM 推出的[clangd](https://clangd.llvm.org/)，其功能稳定且提示流畅，
+与此同时，我们可以选择安装支持 LSP 的语法提示插件，如 LLVM 推出的 [clangd](https://clangd.llvm.org/)，其功能稳定且提示流畅，
 并通过 LSP 标准完成对不同编译工具链的支持。
 
-使用 clangd 时，可能与上述的C/C++插件的提示功能有冲突，可以在 .vscode/settings.json 中添加设置将C/C++的语法提示功能关闭:
+使用 clangd 时，可能与上述的 C/C++ 插件的提示功能有冲突，可以在 .vscode/settings.json 中添加设置将 C/C++ 的语法提示功能关闭：
 
 ```
 {
@@ -147,7 +147,7 @@ $ xmake project -k compile_commands .vscode
 }
 ```
 
-同时由于 XMake 生成的 compile_commands.json 在 .vscode 目录，还需要设置 clangd 传参使其在正确位置寻找:
+同时由于 XMake 生成的 compile_commands.json 在 .vscode 目录，还需要设置 clangd 参数使其在正确位置寻找：
 
 ```
 {
@@ -159,7 +159,7 @@ $ xmake project -k compile_commands .vscode
 }
 ```
 
-如果配置后，还是没生效，可以尝试重启 vscode 和 clangd 进程，再验证下。
+如果配置后，还是没生效，可以尝试重启 VSCode 和 clangd 进程，再验证。
 
 ## Sublime 插件 {#sublime-plugin}
 
@@ -187,9 +187,9 @@ $ xmake project -k compile_commands .vscode
 
 ## Gradle插件（JNI）{#gradle-plugin}
 
-* [xmake-gradle](https://github.com/xmake-io/xmake-gradle): 一个无缝整合xmake的gradle插件
+* [xmake-gradle](https://github.com/xmake-io/xmake-gradle): 一个无缝整合 xmake 的 gradle 插件
 
-### 通过插件DSL集成
+### 通过插件 DSL 集成
 
 ```
 plugins {

docs/zh/guide/extensions/plugin-development.md

@@ -2,7 +2,7 @@
 
 ## 简介
 
-Xmake 完全支持插件模式，我们可以很方便的扩展实现自己的插件，并且 Xmake 也提供了一些内建的使用插件。
+Xmake 完全支持插件模式，我们可以很方便地扩展实现自己的插件，并且 Xmake 也提供了一些内建的插件可供使用。
 
 我们可以执行下 `xmake -h` 看下当前支持的插件：
 
@@ -16,10 +16,10 @@ Plugins:
 ```
 
 * lua: 运行lua脚本的插件
-* macro: 这个很实用，宏脚本插件，可以手动录制多条xmake命令并且回放，也可以通过脚本实现一些复杂的宏脚本，这个我们后续会更加详细的介绍
-* doxygen：一键生成doxygen文档的插件
-* hello: 插件demo，仅仅显示一句话：'hello xmake!'
-* project： 生成工程文件的插件，目前已经支持make, cmake, ninja, xcode (需要 cmake) 和 vs 的工程文件以及 compile_commands.json 和 compile_flags.txt 文件的生成
+* macro: 这个很实用，宏脚本插件，可以手动录制多条 xmake 命令并且回放，也可以通过脚本实现一些复杂的宏脚本，这个我们后续会更加详细地介绍
+* doxygen：一键生成 doxygen 文档的插件
+* hello: 插件 demo，仅仅显示一句话：'hello xmake!'
+* project： 生成工程文件的插件，目前已经支持 make、cmake、ninja、xcode（需要 cmake）和 vs 的工程文件，以及 compile_commands.json 和 compile_flags.txt 文件的生成
 
 ## 快速开始
 
@@ -64,9 +64,9 @@ plugins
 
 现在一个最简单的插件写完了，那怎么让它被xmake检测到呢，有三种方式：
 
-1. 把 hello 这个文件夹放置在 xmake的插件安装目录 `xmake/plugins`，这个里面都是些内建的插件
-2. 把 hello 文件夹放置在 `~/.xmake/plugins` 用户全局目录，这样对当前xmake 全局生效
-3. 把 hello 文件夹放置在当前工程的`./plugins`目录下，通过在工程描述文件xmake.lua中调用`add_plugindirs("plugins")` 添加当前的工程的插件搜索目录，这样只对当前工程生效
+1. 把 hello 这个文件夹放置在 xmake 的插件安装目录 `xmake/plugins`，这个里面都是一些内建的插件
+2. 把 hello 文件夹放置在 `~/.xmake/plugins` 用户全局目录，这样对当前 xmake 全局生效
+3. 把 hello 文件夹放置在当前工程的 `./plugins` 目录下，通过在工程描述文件 xmake.lua 中调用 `add_plugindirs("plugins")` 添加当前工程的插件搜索目录，这样只对当前工程生效
 
 ## 运行插件
 
@@ -82,7 +82,7 @@ xmake hello
 hello xmake!
 ```
 
-最后我们还可以在target自定义的脚本中运行这个插件：
+最后我们还可以在 target 自定义的脚本中运行这个插件：
 
 ```lua
 target("demo")

docs/zh/guide/extensions/theme-style.md

@@ -6,15 +6,15 @@ outline: deep
 
 ## 切换主题 {#switch-theme}
 
-如果用户不喜欢xmake默认的显示配色和风格，我们可以通过下面的全局配置命令，来切换到xmake提供的其他一些配置主题上去，例如：
+如果用户不喜欢 xmake 默认的显示配色和风格，我们可以通过下面的全局配置命令，切换到 xmake 提供的其他一些配置主题，例如：
 
 ```sh
 $ xmake g --theme=dark
 ```
 
-默认的主题名为default，这里我们通过切换到dark风格主题，来适配一些终端背景很浅的场景，提供更加深色的色彩输出，避免看不清。
+默认的主题名为 default，这里我们通过切换到 dark 风格主题，来适配一些终端背景很浅的场景，提供更加深色的色彩输出，避免看不清。
 
-如果我们要切回默认主题，可以直接敲：
+如果我们要切回默认主题，可以直接输入：
 
 ```sh
 $ xmake g -c
@@ -26,7 +26,7 @@ $ xmake g -c
 $ xmake g --theme=default
 ```
 
-另外，xmake还提供了不少有趣实用的内置主题，大伙可以试试，下文会详细讲解。
+另外，xmake 还提供了不少有趣实用的内置主题，大家可以试试，下面会详细讲解。
 
 ::: tip 注意
 如果大家有更好的主题，也欢迎提pr贡献进来，非常感谢！
@@ -48,7 +48,7 @@ $ xmake g --theme=default
 
 ### Ninja 主题 {#ninja-theme}
 
-这个是v2.3.4之后版本提供的主题，构建进度风格类似ninja，采用单行进度条，不再回滚进度，用户可以根据自己的喜好设置。
+这个是 v2.3.4 之后版本提供的主题，构建进度风格类似 ninja，采用单行进度条，不再回滚进度，用户可以根据自己的喜好设置。
 
 除了进度展示不同外，其他都跟默认主题的配置相同。
 
@@ -60,7 +60,7 @@ $ xmake g --theme=ninja
 
 ### Emoji 主题 {#emoji-theme}
 
-这个主题部分输出通过emoji字符代替之前的色彩输出。
+这个主题部分输出通过 emoji 字符代替之前的色彩输出。
 
 ```sh
 $ xmake g --theme=emoji
@@ -70,7 +70,7 @@ $ xmake g --theme=emoji
 
 ### Dark 主题 {#dark-theme}
 
-这个主题主要是对一些终端背景是浅色系（比如淡黄色等），导致一些警告输出（默认也是黄色）重合不可见，所以把主题配色变成深色系，提高可见性。
+这个主题主要是针对一些终端背景为浅色系（比如淡黄色等），导致一些警告输出（默认也是黄色）重合不可见，所以把主题配色变成深色系，提高可见性。
 
 ```sh
 $ xmake g --theme=dark
@@ -78,7 +78,7 @@ $ xmake g --theme=dark
 
 ### Light 主题 {#light-theme}
 
-这个主题主要是对一些终端背景是深色系，导致一些输出重合不可见，所以把主题配色变成浅色系，提高可见性。
+这个主题主要是针对一些终端背景为深色系，导致一些输出重合不可见，所以把主题配色变成浅色系，提高可见性。
 
 ```sh
 $ xmake g --theme=light
@@ -89,7 +89,7 @@ $ xmake g --theme=light
 这个主题，其实就是完全禁用色彩、emoji 输出，主要是应对一些不支持 colors code 的终端导致显示乱码的问题，也是最朴素的主题风格。
 
 ::: tip 注意
-一些win终端可能不支持colors，就可以设置这个主题来解决乱码显示问题
+一些 Windows 终端可能不支持 colors，就可以设置这个主题来解决乱码显示问题。
 :::
 
 ```sh
@@ -98,9 +98,9 @@ $ xmake g --theme=plain
 
 ### Powershell 主题 {#powershell-theme}
 
-Windows 下 powershell 终端背景是蓝色的，而它的调色板配置似乎被改过的，其中 magenta 色居然显示成背景蓝色，很诡异，导致 Xmake 的默认输出会有局部文本不可见（跟背景色重叠了）
+Windows 下 powershell 终端背景是蓝色的，而它的调色板配置似乎被改过，其中 magenta 色居然显示成背景蓝色，很诡异，导致 Xmake 的默认输出会有局部文本不可见（与背景色重叠了）。
 
-所以，这个主题就是为了更好的适配 powershell 终端下的显示输出。
+所以，这个主题就是为了更好地适配 powershell 终端下的显示输出。
 
 ```sh
 $ xmake g --theme=powershell

docs/zh/guide/extras/autoscan-sourcecode.md

@@ -1,15 +1,15 @@
 # 自动源码扫描 {#autoscan-sourcecode}
 
-对于一份工程源码，可以不用编写makefile，也不用编写各种make相关的工程描述文件（例如：xmake.lua，makefile.am, cmakelist.txt等）
+对于一份工程源码，可以不用编写 makefile，也不用编写各种 make 相关的工程描述文件（例如：xmake.lua、makefile.am、CMakeLists.txt 等）。
 
-xmake就可以直接编译他们，这是如何做到的呢，简单来说下实现原理：
+xmake 就可以直接编译它们，这是如何做到的呢？简单来说下实现原理：
 
-1. 首先扫描当前目录下，xmake所以支持的所有源代码文件
-2. 分析代码，检测哪些代码拥有main入口函数
-3. 所有没有main入口的代码编译成静态库
-4. 带有main入口的代码，编译成可执行程序，同时链接其他静态库程序
+1. 首先扫描当前目录下，xmake 所支持的所有源码文件
+2. 分析代码，检测哪些代码拥有 main 入口函数
+3. 所有没有 main 入口的代码编译成静态库
+4. 带有 main 入口的代码，编译成可执行程序，同时链接其他静态库程序
 
-这种代码扫描和智能编译，非常简单，目前xmake还不支持多级目录扫描，只对单级目录的代码进行扫描编译。。
+这种代码扫描和智能编译，非常简单，目前 xmake 还不支持多级目录扫描，只对单级目录的代码进行扫描编译。。
 
 ## 使用场景
 
@@ -28,7 +28,7 @@ please input: n (y/n)
 y
 ```
 
-另外, 当存在其他构建系统标识性文件的时候(比如 CMakeLists.txt), 不会触发自动生成 xmake.lua 的流程, 而是首先触发自动探测构建系统并编译。
+另外，当存在其他构建系统标识性文件时（比如 CMakeLists.txt），不会触发自动生成 xmake.lua 的流程，而是首先触发自动探测构建系统并编译。
 
 ```sh
 $ xmake f -y
@@ -36,11 +36,11 @@ $ xmake f -y
 
 ## 开源代码的移植和编译
 
-虽然这种方式，并不是非常智能，限制也不少，但是对于想临时写些代码进行编译运行，或者临时想交叉编译一些简单的开源库代码
+虽然这种方式并不是非常智能，限制也不少，但是对于想临时写些代码进行编译运行，或者临时想交叉编译一些简单的开源库代码
 
-这种方式已经足够使用了，下面看下一个实际的例子：
+这种方式已经足够使用了，下面看一个实际的例子：
 
-我下载了一份zlib-1.2.10的源码，想要编译它，只需要进入zlib的源码目录执行：
+我下载了一份 zlib-1.2.10 的源码，想要编译它，只需要进入 zlib 的源码目录执行：
 
 ```sh
 $ cd zlib-1.2.10
@@ -50,7 +50,7 @@ please input: n (y/n)
 y
 ```
 
-就行了，输入y确认后，输出结果如下：
+就行了，输入 y 确认后，输出结果如下：
 
 ```
 target(zlib-1.2): static
@@ -132,11 +132,11 @@ clean ok!
 build ok!👌
 ```
 
-通过输出结果，可以看到，xmake会去检测扫描当前目录下的所有.c代码，发现没有main入口，应该是静态库程序，因此执行xmake后，就直接编译成静态库libzlib-1.2.a了
+通过输出结果，可以看到，xmake 会去检测扫描当前目录下的所有 .c 代码，发现没有 main 入口，应该是静态库程序，因此执行 xmake 后，就直接编译成静态库 libzlib-1.2.a 了。
 
-连xmake.lua都没有编写，其实xmake在扫描完成后，会去自动在当前目录下生成一份xmake.lua，下次编译就不需要重新扫描检测了。
+这些 xmake.lua 都没有编写，其实 xmake 在扫描完成后，会自动在当前目录下生成一份 xmake.lua，下次编译就不需要重新扫描检测了。
 
-自动生成的xmake.lua内容如下：
+自动生成的 xmake.lua 内容如下：
 
 ```lua
 -- define target
@@ -163,36 +163,36 @@ target("zlib-1.2")
     add_files("./zutil.c")
 ```
 
-也许你会说，像这种开源库，直接`configure; make`不就好了吗，他们自己也有提供makefile来直接编译的，的确是这样，我这里只是举个例子而已。。
+也许你会说，像这种开源库，直接 `configure; make` 不就好了吗，他们自己也有提供 makefile 来直接编译的，的确是这样，我这里只是举个例子而已。。
 
-当然，很多开源库在交叉编译的时候，通过自带的`configure`，处理起来还是很繁琐的，用xmake进行交叉编译会更方便些。。
+当然，很多开源库在交叉编译的时候，通过自带的 `configure`，处理起来还是很繁琐的，用 xmake 进行交叉编译会更方便些。。
 
 ## 即时地代码编写和编译运行
 
-xmake的这个扫描代码编译特性，主要的目的：还是为了让我们在临时想写些测试代码的时候，不用考虑太多东西，直接上手敲代码，然后快速执行`xmake run` 来调试验证结果。。
+xmake 的这个扫描代码编译特性，主要的目的还是为了让我们在临时想写些测试代码的时候，不用考虑太多东西，直接上手敲代码，然后快速执行 `xmake run` 来调试验证结果。
 
 例如：
 
-我想写了个简单的main.c的测试程序，打印`hello world!`，如果要写makefile或者直接通过gcc命令来，就很繁琐了，你需要：
+我想写一个简单的 main.c 测试程序，打印 `hello world!`，如果要写 makefile 或者直接通过 gcc 命令来，就很繁琐了，你需要：
 
 ```sh
 gcc ./main.c -o demo
 ./demo
 ```
 
-最快速的方式，也需要执行两行命令，而如果用xmake，只需要执行：
+最快的方式，也需要执行两行命令，而如果用 xmake，只需要执行：
 
 ```sh
 xmake run
 ```
 
-就行了，它会自动检测到代码后，自动生成对应的xmake.lua，自动编译，自动运行，然后输出：
+就行了，它会自动检测到代码后，自动生成对应的 xmake.lua，自动编译，自动运行，然后输出：
 
 ```
 hello world!
 ```
 
-如果你有十几个代码文件，用手敲gcc的方式，或者写makefile的方式，这个差距就更明显了，用xmake还是只需要一行命令：
+如果你有十几个代码文件，用手敲 gcc 的方式，或者写 makefile 的方式，这个差距就更明显了，用 xmake 还是只需要一行命令：
 
 ```sh
 xmake run
@@ -200,9 +200,9 @@ xmake run
 
 ## 多语言支持
 
-这种代码检测和即时编译，是支持多语言的，不仅支持c/c++，还支持objc/swift，后期还会支持golang（正在开发中）
+这种代码检测和即时编译，是支持多语言的，不仅支持 c/c++，还支持 objc/swift，后期还会支持 golang（正在开发中）
 
-例如我下载了一份fmdb的ios开源框架代码：
+例如我下载了一份 fmdb 的 ios 开源框架代码：
 
 ```
 .
@@ -219,7 +219,7 @@ xmake run
 └── FMResultSet.m
 ```
 
-想要把它编译成ios的静态库，但是又不想写xmake.lua，或者makefile，那么只需要使用xmake的这个新特性，直接执行：
+想要把它编译成 ios 的静态库，但是又不想写 xmake.lua，或者 makefile，那么只需要使用 xmake 的这个新特性，直接执行：
 
 ```sh
 $ xmake f -p iphoneos; xmake
@@ -288,9 +288,9 @@ build ok!👌
 
 输出结果的开头部分，就是对代码的分析结果，虽然目前只支持单级目录结构的代码扫描，但是还是可以同时支持检测和编译多个可执行文件的
 
-我们以libjpeg的开源库为例：
+我们以 libjpeg 的开源库为例：
 
-我们进入jpeg-6b目录后，执行：
+我们进入 jpeg-6b 目录后，执行：
 
 ```sh
 $ xmake
@@ -503,7 +503,7 @@ clean ok!
 build ok!👌
 ```
 
-可以看到，处理静态库，xmake还分析出了很多可执行的测试程序，剩下的代码统一编译成一个 libjpeg.a 的静态库，供哪些测试程序链接使用。。
+可以看到，处理静态库，xmake 还分析出了很多可执行的测试程序，剩下的代码统一编译成一个 libjpeg.a 的静态库，供哪些测试程序链接使用。。
 
 ```
 target(ansi2knr): binary
@@ -524,7 +524,7 @@ target(wrjpgcom): binary
 
 ## 遇到的一些问题和限制
 
-当前xmake的这种自动分析检测还不是非常智能，对于：
+当前 xmake 的这种自动分析检测还不是非常智能，对于：
 
 1. 需要特殊的编译选项
 2. 需要依赖其他目录的头文件搜索
@@ -532,7 +532,7 @@ target(wrjpgcom): binary
 4. 同目录需要生成多个静态库
 5. 需要多级目录支持的源码库
 
-以上这些情况，xmake暂时还没发自动化的智能处理，其中限制1，2还是可以解决的，通过半手动的方式，例如：
+以上这些情况，xmake 暂时还没发自动化的智能处理，其中限制 1，2 还是可以解决的，通过半手动的方式，例如：
 
 ```sh
 $ xmake f --cxflags="" --ldflags="" --includedirs="" --linkdirs=""; xmake
@@ -540,12 +540,6 @@ $ xmake f --cxflags="" --ldflags="" --includedirs="" --linkdirs=""; xmake
 
 在自动检测编译的时候，手动配置这个源码工程需要的特殊编译选项，就可以直接通过编译了
 
-而限制3，暂时只能通过删源代码来解决了，就像刚才编译jpeg的代码，其实它的目录下面同时存在了：
+而限制 3，暂时只能通过删源代码来解决了，就像刚才编译 jpeg 的代码，其实它的目录下面同时存在了：
 
-```
-jmemdos.c
-jmemmac.c
-jmemansi.c
-```
-
-其中两个是没法编译过的，需要删掉后才行。。
+```

docs/zh/guide/extras/build-cache.md

@@ -6,21 +6,21 @@ outline: deep
 
 ## 本地编译缓存 {#local-build-cache}
 
-默认，Xmake 就会开启本地缓存，2.6.5 之前的版本默认使用外置的 ccache，而 2.6.6 之后版本，Xmake 提供了内置的跨平台本地缓存方案。
+默认情况下，Xmake 会开启本地缓存。2.6.5 之前的版本默认使用外置的 ccache，而 2.6.6 之后版本，Xmake 提供了内置的跨平台本地缓存方案。
 
 相比 ccache 等第三方独立进程，xmake 内部状态维护，更加便于优化，也避免了频繁的独立进程加载耗时，也避免了与守护进程额外的通信。
 
-另外，内置的缓存能够更好的支持跨平台，Windows 上 msvc 也能够很好的支持，而 ccache 仅仅支持 gcc/clang。
+另外，内置的缓存能够更好地支持跨平台，Windows 上 msvc 也能够很好地支持，而 ccache 仅仅支持 gcc/clang。
 
-当然，我们也可以通过下面的命令禁用缓存。
+当然，我们也可以通过下面的命令禁用缓存：
 
 ```sh
 $ xmake f --ccache=n
 ```
 
-注：不管是否使用内置本地缓存，配置名都是 `--ccache=`，意思是 c/c++ 构建缓存，而不仅仅是指 ccache 工具的名字。
+注意：无论是否使用内置本地缓存，配置名都是 `--ccache=`，意思是 c/c++ 构建缓存，而不仅仅是指 ccache 工具的名字。
 
-我们如果想继续使用外置的其他缓存工具，我们也是可以通过下面的方式来配置。
+我们如果想继续使用外置的其他缓存工具，也可以通过下面的方式来配置。
 
 ```sh
 $ xmake f --ccache=n --cxx="ccache gcc" --cc="ccache gcc"
@@ -31,22 +31,22 @@ $ xmake
 
 除了本地缓存，我们也提供了远程缓存服务，类似 mozilla 的 sscache，如果只是个人开发，平常不会用到它。
 
-但是，如果是公司内部多人协同开发一个大型项目，仅仅靠分布式编译和本地缓存，是不够的。我们还需要对编译的对象文件缓存到独立的服务器上进行共享。
+但是，如果是公司内部多人协同开发一个大型项目，仅靠分布式编译和本地缓存是不够的。我们还需要将编译的对象文件缓存到独立的服务器上进行共享。
 
 这样，其他人即使首次编译，也不需要每次都去分布式编译它，直接从远程拉取缓存来加速编译。
 
-另外，Xmake 提供的远程缓存服务，也是全平台支持的，不仅支持 gcc/clang 还支持 msvc。
+另外，Xmake 提供的远程缓存服务，也是全平台支持的，不仅支持 gcc/clang，还支持 msvc。
 
 ### 开启服务 {#start-service}
 
-我们可以指定 `--ccache` 参数来开启远程编译缓存服务，当然如果不指定这个参数，xmake 会默认开启所有服务端配置的服务。
+我们可以指定 `--ccache` 参数来开启远程编译缓存服务。当然如果不指定这个参数，xmake 会默认开启所有服务端配置的服务。
 
 ```sh
 $ xmake service --ccache
 <remote_cache_server>: listening 0.0.0.0:9092 ..
 ```
 
-我们也可以开启服务的同时，回显详细日志信息。
+我们也可以在开启服务的同时，回显详细日志信息。
 
 ```sh
 $ xmake service --ccache -vD
@@ -63,7 +63,7 @@ $ xmake service --ccache --stop
 
 ### 配置服务端 {#configure-server}
 
-我们首先，运行 `xmake service` 命令，它会自动生成一个默认的 `server.conf` 配置文件，存储到 `~/.xmake/service/server.conf`。
+我们可以运行 `xmake service` 命令，它会自动生成一个默认的 `server.conf` 配置文件，存储到 `~/.xmake/service/server.conf`。
 
 ```sh
 $ xmake service
@@ -73,7 +73,7 @@ generating the config file to /Users/ruki/.xmake/service/client.conf ..
 <remote_cache_server>: listening 0.0.0.0:9692 ..
 ```
 
-然后，我们编辑它，修复服务器的监听端口（可选）。
+然后，我们编辑它，修正服务器的监听端口（可选）。
 
 ```sh
 $ cat ~/.xmake/service/server.conf
@@ -94,7 +94,7 @@ $ cat ~/.xmake/service/server.conf
 
 客户端配置文件在 `~/.xmake/service/client.conf`，我们可以在里面配置客户端需要连接的服务器地址。
 
-我们可以在 hosts 列表里面配置多个服务器地址，以及对应的 token。
+我们可以在 hosts 列表中配置多个服务器地址，以及对应的 token。
 
 ```sh
 $cat ~/.xmake/service/client.conf
@@ -109,11 +109,11 @@ $cat ~/.xmake/service/client.conf
 
 #### 配置超时 {#configure-timeout}
 
-默认情况下，客户端连接，收发数据都是无限等待不超时的，但是如果访问服务端的网络不稳定，那么有可能会导致访问卡死，这个时候可以配置超时来解决。
+默认情况下，客户端连接、收发数据都是无限等待不超时的，但是如果访问服务端的网络不稳定，有可能会导致访问卡死，这时可以配置超时来解决。
 
 如果发生超时异常，就会自动退化到本地缓存，不会永远卡死。
 
-我们可以配置，`send_timeout`, `recv_timeout` 和 `connect_timeout` 三种超时，如果在根节点设置，那么所有客户端服务都会生效。
+我们可以配置 `send_timeout`、`recv_timeout` 和 `connect_timeout` 三种超时，如果在根节点设置，那么所有客户端服务都会生效。
 
 ```sh
 $ cat ~/.xmake/service/client.conf
@@ -124,7 +124,7 @@ $ cat ~/.xmake/service/client.conf
 }
 ```
 
-我们也可以仅仅针对当前远程缓存服务配置超时，其他服务还是默认超时。
+我们也可以仅针对当前远程缓存服务配置超时，其他服务还是默认超时。
 
 ```sh
 $ cat ~/.xmake/service/client.conf
@@ -147,9 +147,9 @@ $ cat ~/.xmake/service/client.conf
 
 ### 连接服务器 {#connect-server}
 
-配置完认证和服务器地址后，就可以输入下面的命令，将当前工程连接到配置的服务器上了。
+配置完认证和服务器地址后，就可以输入下面的命令，将当前工程连接到配置的服务器上。
 
-我们需要在连接时候，输入 `--ccache`，指定仅仅连接远程编译缓存服务。
+我们需要在连接时，输入 `--ccache`，指定仅连接远程编译缓存服务。
 
 ```sh
 $ cd projectdir
@@ -182,10 +182,10 @@ $ xmake service --disconnect --ccache
 $ xmake service --clean --ccache
 ```
 
-而如果我们执行 `xmake clean --all`，在连接了远程服务的状态下，也会去自动清理所有的缓存。
+而如果我们执行 `xmake clean --all`，在连接了远程服务的状态下，也会自动清理所有的缓存。
 
 ### 一些内部优化 {#optimizations}
 
-1. 拉取远程缓存的快照，通过 bloom filter + lz4 回传本地后，用于快速判断缓存是否存在，避免频繁的查询服务端缓存信息
+1. 拉取远程缓存的快照，通过 bloom filter + lz4 回传本地后，用于快速判断缓存是否存在，避免频繁查询服务端缓存信息。
 2. 配合本地缓存，可以避免频繁地请求远程服务器，拉取缓存。
-3. 内部状态维护，相比 sscache 等独立工具，避免了频繁的独立进程加载耗时，也避免了与守护进程额外的通信
+3. 内部状态维护，相比 sscache 等独立工具，避免了频繁的独立进程加载耗时，也避免了与守护进程额外的通信。

docs/zh/guide/extras/distributed-compilation.md

@@ -1,10 +1,10 @@
 # 分布式编译 {#distributed-compilation}
 
-Xmake 提供了内置的分布式编译服务，通常它可以跟 本地编译缓存，远程编译缓存 相互配合，实现最优的编译的加速。
+Xmake 提供了内置的分布式编译服务，通常它可以与本地编译缓存、远程编译缓存相互配合，实现最优的编译加速。
 
-另外，它是完全跨平台支持，我们不仅支持 gcc/clang，也能够很好地支持 Windows 和 msvc。
+另外，它是完全跨平台支持的，我们不仅支持 gcc/clang，也能够很好地支持 Windows 和 msvc。
 
-对于交叉编译，只要交叉工具链支持，我们不要求服务器的系统环境，即使混用 linux, macOS 和 Windows 的服务器资源，也可以很好的实现分布式编译。
+对于交叉编译，只要交叉工具链支持，我们不要求服务器的系统环境，即使混用 linux、macOS 和 Windows 的服务器资源，也可以很好地实现分布式编译。
 
 ## 开启服务 {#start-service}
 
@@ -16,7 +16,7 @@ $ xmake service --distcc
 <distcc_build_server>: listening 0.0.0.0:9093 ..
 ```
 
-我们也可以开启服务的同时，回显详细日志信息。
+我们也可以在开启服务的同时，回显详细日志信息。
 
 ```sh
 $ xmake service --distcc -vD
@@ -33,7 +33,7 @@ $ xmake service --distcc --stop
 
 ## 配置服务端 {#configure-server}
 
-我们首先，运行 `xmake service` 命令，它会自动生成一个默认的 `server.conf` 配置文件，存储到 `~/.xmake/service/server.conf`。
+我们首先运行 `xmake service` 命令，它会自动生成一个默认的 `server.conf` 配置文件，存储到 `~/.xmake/service/server.conf`。
 
 ```sh
 $ xmake service
@@ -43,7 +43,7 @@ generating the config file to /Users/ruki/.xmake/service/client.conf ..
 <distcc_build_server>: listening 0.0.0.0:9693 ..
 ```
 
-然后，我们编辑它，修复每台服务器的监听端口（可选）。
+然后，我们编辑它，修正每台服务器的监听端口（可选）。
 
 ```sh
 $ cat ~/.xmake/service/server.conf
@@ -64,10 +64,10 @@ $ cat ~/.xmake/service/server.conf
 
 客户端配置文件在 `~/.xmake/service/client.conf`，我们可以在里面配置客户端需要连接的服务器地址。
 
-我们可以在 hosts 列表里面配置多个服务器地址，以及对应的 token。
+我们可以在 hosts 列表中配置多个服务器地址，以及对应的 token。
 
 ::: tip 注意
-分布式编译，推荐使用 token 认证模式，因为密码模式，每台服务器连接时候都要输入一次密码，很繁琐。
+分布式编译，推荐使用 token 认证模式，因为密码模式下每台服务器连接时都要输入一次密码，很繁琐。
 :::
 
 ```sh
@@ -90,11 +90,11 @@ $cat ~/.xmake/service/client.conf
 
 ### 配置超时 {#configure-timeout}
 
-默认情况下，客户端连接，收发数据都是无限等待不超时的，但是如果访问服务端的网络不稳定，那么有可能会导致访问卡死，这个时候可以配置超时来解决。
+默认情况下，客户端连接、收发数据都是无限等待不超时的，但是如果访问服务端的网络不稳定，有可能会导致访问卡死，这时可以配置超时来解决。
 
 如果发生超时异常，就会自动退化到本地编译，不会永远卡死。
 
-我们可以配置，`send_timeout`, `recv_timeout` 和 `connect_timeout` 三种超时，如果在根节点设置，那么所有客户端服务都会生效。
+我们可以配置 `send_timeout`、`recv_timeout` 和 `connect_timeout` 三种超时，如果在根节点设置，那么所有客户端服务都会生效。
 
 ```sh
 $ cat ~/.xmake/service/client.conf
@@ -105,7 +105,7 @@ $ cat ~/.xmake/service/client.conf
 }
 ```
 
-我们也可以仅仅针对当前分布式构建服务配置超时，其他服务还是默认超时。
+我们也可以仅针对当前分布式构建服务配置超时，其他服务还是默认超时。
 
 ```sh
 $ cat ~/.xmake/service/client.conf
@@ -128,9 +128,9 @@ $ cat ~/.xmake/service/client.conf
 
 ## 连接服务器 {#connect-server}
 
-配置完认证和服务器地址后，就可以输入下面的命令，将当前工程连接到配置的服务器上了。
+配置完认证和服务器地址后，就可以输入下面的命令，将当前工程连接到配置的服务器上。
 
-我们需要在连接时候，输入 `--distcc`，指定仅仅连接分布式服务。
+我们需要在连接时，输入 `--distcc`，指定仅连接分布式服务。
 
 ```sh
 $ cd projectdir
@@ -173,9 +173,9 @@ $ xmake
 [100%]: build ok!
 ```
 
-其中，带有 distcc 字样的是远程编译任务，其他的都是本地编译任务，默认 xmake 还开启了本地编译缓存，对分布式编译结果进行缓存，避免频繁请求服务器。
+其中，带有 distcc 字样的是远程编译任务，其他的都是本地编译任务。默认 xmake 还开启了本地编译缓存，对分布式编译结果进行缓存，避免频繁请求服务器。
 
-另外，我们也可以开启远程编译缓存，跟其他人共享编译缓存，进一步加速多人协同开发的编译。
+另外，我们也可以开启远程编译缓存，与其他人共享编译缓存，进一步加速多人协同开发的编译。
 
 ## 断开连接 {#disconnect}
 

docs/zh/guide/extras/environment-variables.md

@@ -1,6 +1,6 @@
 # 环境变量 {#environment-variables}
 
-我们可以执行下面的命令，获取所有 xmake 用到的环境变量，以及当前被设置的值。
+我们可以执行下面的命令，获取所有 xmake 用到的环境变量，以及当前被设置的值：
 
 ```sh
 $ xmake show -l envs
@@ -34,7 +34,7 @@ XMAKE_LOGFILE           Set the log output file path.
 
 - 设置 ramdisk 目录路径
 
-ramdisk 目录是内存文件系统的目录位置，通常 `os.tmpdir()` 接口会用到，xmake 内部使用的临时文件，如果用户设置 ramdisk 路径，则会优先存储在这个上面，提升整体编译速度。
+ramdisk 目录是内存文件系统的目录位置，通常 `os.tmpdir()` 接口会用到。xmake 内部使用的临时文件，如果用户设置 ramdisk 路径，则会优先存储在这个上面，提升整体编译速度。
 
 ## XMAKE_TMPDIR
 
@@ -46,19 +46,19 @@ ramdisk 目录是内存文件系统的目录位置，通常 `os.tmpdir()` 接口
 
 - 设置本地工程配置目录
 
-每个项目的本地编译配置，默认会存储在当前项目根目录的 `.xmake` 路径下，然后根据不同的平台，架构区分，例如：
+每个项目的本地编译配置，默认会存储在当前项目根目录的 `.xmake` 路径下，然后根据不同的平台、架构区分，例如：
 
 ```sh
 .xmake/macosx/x86_64
 ```
 
-我们如果不想存储在项目根目录，也可以自己设置到其他路径，比如 build 目录下等等。
+我们如果不想存储在项目根目录，也可以自己设置到其他路径，比如 build 目录下等。
 
 ## XMAKE_GLOBALDIR
 
 - 设置全局配置文件根目录
 
-xmake将在该目录下创建 `.xmake`，作为 `xmake g/global` 全局配置的存储目录，还有安装包，缓存等其他全局文件，默认都会存储在这个目录下。
+xmake 会在该目录下创建 `.xmake`，作为 `xmake g/global` 全局配置的存储目录，还有安装包、缓存等其他全局文件，默认都会存储在这个目录下。
 
 默认路径为：`~`。
 
@@ -66,7 +66,7 @@ xmake将在该目录下创建 `.xmake`，作为 `xmake g/global` 全局配置的
 
 - 允许用户在 root 模式下运行
 
-通常 xmake 是默认禁止在 root 下运行，这非常不安全。但是如果用户非要在 root 下运行，也可以设置这个变量，强制开启。
+通常 xmake 默认禁止在 root 下运行，这非常不安全。但是如果用户非要在 root 下运行，也可以设置这个变量，强制开启。
 
 ```sh
 export XMAKE_ROOT=y
@@ -85,7 +85,7 @@ export XMAKE_ROOT=y
 | color256  | 256 色输出支持 |
 | truecolor | 真彩色输出支持 |
 
-通常，用户不需要设置它们，xmake 会自动探测用户终端支持的色彩范围，如果用户不想输出色彩，可以设置 nocolor 来全局禁用。
+通常，用户不需要设置它们，xmake 会自动探测用户终端支持的色彩范围。如果用户不想输出色彩，可以设置 nocolor 来全局禁用。
 
 或者用 `xmake g --theme=plain` 也可以全局禁用。
 
@@ -95,7 +95,7 @@ export XMAKE_ROOT=y
 
 xmake 的远程包安装的全局目录默认是 `$XMAKE_GLOBALDIR/.xmake/packages`，但是用户也可以设置这个变量，去单独修改它。
 
-我们也可以使用 `xmake g --pkg_installdir=/xxx` 去设置它，效果是一样的。但环境变量的优先级高于此配置。
+我们也可以使用 `xmake g --pkg_installdir=/xxx` 去设置它，效果是一样的。但是环境变量的优先级高于此配置。
 
 ## XMAKE_PKG_CACHEDIR
 
@@ -109,7 +109,7 @@ xmake 的远程包安装的全局目录默认是 `$XMAKE_GLOBALDIR/.xmake/packag
 
 - 设置 xmake 的脚本目录
 
-xmake 的所有 lua 脚本随安装程序一起安装，默认都在安装目录下，但是如果想要切到自己下载的脚本目录下，方便本地修改调试，可以设置此变量。
+xmake 的所有 lua 脚本随安装程序一起安装，默认都在安装目录下，但是如果想要切换到自己下载的脚本目录下，方便本地修改调试，可以设置此变量。
 
 如果要查看当前 xmake 在使用的脚本目录，可以执行：
 
@@ -122,7 +122,7 @@ $ xmake l os.programdir
 
 - 开启性能分析
 
-这仅仅对 xmake 的开发者开放，用于分析 xmake 运行过程中的耗时情况，追踪调用过程。
+这个仅对 xmake 的开发者开放，用于分析 xmake 运行过程中的耗时情况，追踪调用过程。
 
 ### 分析函数调用耗时
 
@@ -206,8 +206,7 @@ $ XMAKE_PROFILE=stuck xmake l test.lua
 stack traceback:
         [C]: in function 'base/io.file_read'
         @programdir/core/base/io.lua:177: in method '_read'
-        @programdir/core/sandbox/modules/io.lua:90: in function <@programdir/core/sandbox/module
-s/io.lua:89>
+        @programdir/core/sandbox/modules/io.lua:90: in function <@programdir/core/sandbox/modules/io.lua:89>
         (...tail calls...)
         /Users/ruki/share/test.lua:2: in function </Users/ruki/share/test.lua:1>
         (...tail calls...)
@@ -218,8 +217,7 @@ s/io.lua:89>
         (...tail calls...)
         @programdir/core/base/task.lua:519: in function 'base/task.run'
         @programdir/core/main.lua:278: in upvalue 'cotask'
-        @programdir/core/base/scheduler.lua:371: in function <@programdir/core/base/scheduler.lu
-a:368>
+        @programdir/core/base/scheduler.lua:371: in function <@programdir/core/base/scheduler.lua:368>
 ```
 
 ## XMAKE_RCFILES