vitejs · waynzh · Aug 4, 2024 · Apr 11, 2024 · Apr 12, 2024 · Apr 13, 2024
diff --git a/config/build-options.md b/config/build-options.md
@@ -32,7 +32,7 @@ import 'vite/modulepreload-polyfill'
 
 此 polyfill 可以通过 `{ polyfill: false }` 来禁用。
 
-每个动态导入要预加载的块列表将由 Vite 计算。默认情况下，在载入这些依赖时，会使用一个包含 `base` 的绝对路径。如果 `base` 是相对路径（`''` 或者 './'），解析时则会使用 `import.meta.url`，以避免出现依赖于最终部署基路径的绝对路径。
+每个动态导入要预加载的块列表将由 Vite 计算。默认情况下，在载入这些依赖时，会使用一个包含 `base` 的绝对路径。如果 `base` 是相对路径（`''` 或者 `'./'`），解析时则会使用 `import.meta.url`，以避免出现依赖于最终部署基路径的绝对路径。
 
 目前有一个实验性功能支持使用 `resolveDependencies` 函数对依赖项列表及其路径进行细粒度控制。可以在这里 [提供反馈](https://github.com/vitejs/vite/discussions/13841)。它期望接收一个 `ResolveModulePreloadDependenciesFn` 类型的函数:
 

diff --git a/config/shared-options.md b/config/shared-options.md
@@ -18,7 +18,7 @@
 开发或生产环境服务的公共基础路径。合法的值包括以下几种：
 
 - 绝对 URL 路径名，例如 `/foo/`
-- 完整的 URL，例如 `https://bar.com/foo/`（在开发环境中不会使用源部分（origin），所以其值与 `/foo/` 相同）
+- 完整的 URL，例如 `https://bar.com/foo/ `（域名部分在开发环境中不会被使用，因此该值与 `/foo/` 相同）
 - 空字符串或 `./`（用于嵌入形式的开发）
 
 更多信息详见 [公共基础路径](/guide/build#public-base-path)。

diff --git a/guide/env-and-mode.md b/guide/env-and-mode.md
@@ -153,9 +153,9 @@ VITE_APP_TITLE=My App (staging)
 NODE_ENV=development
 ```
 
-## NODE_ENV and Modes
+## NODE_ENV 和 模式 {#node-env-and-modes}
 
-It's important to note that `NODE_ENV` (`process.env.NODE_ENV`) and modes are two different concepts. Here's how different commands affect the `NODE_ENV` and mode:
+需要注意的是，`NODE_ENV`（`process.env.NODE_ENV`）和模式是两个不同的概念。以下是不同命令如何影响 `NODE_ENV` 和模式：
 
 | Command                                              | NODE_ENV        | Mode            |
 | ---------------------------------------------------- | --------------- | --------------- |
@@ -164,7 +164,7 @@ It's important to note that `NODE_ENV` (`process.env.NODE_ENV`) and modes are tw
 | `NODE_ENV=development vite build`                    | `"development"` | `"production"`  |
 | `NODE_ENV=development vite build --mode development` | `"development"` | `"development"` |
 
-The different values of `NODE_ENV` and mode also reflect on its corresponding `import.meta.env` properties:
+`NODE_ENV` 和模式的不同值也会反映在相应的 `import.meta.env` 属性上：
 
 | Command                | `import.meta.env.PROD` | `import.meta.env.DEV` |
 | ---------------------- | ---------------------- | --------------------- |
@@ -178,9 +178,9 @@ The different values of `NODE_ENV` and mode also reflect on its corresponding `i
 | `--mode development` | `"development"`        |
 | `--mode staging`     | `"staging"`            |
 
-:::tip `NODE_ENV` in `.env` files
+:::tip `.env` 文件中的 `NODE_ENV`
 
-`NODE_ENV=...` can be set in the command, and also in your `.env` file. If `NODE_ENV` is specified in a `.env.[mode]` file, the mode can be used to control its value. However, both `NODE_ENV` and modes remain as two different concepts.
+`NODE_ENV=...` 可以在命令中设置，也可以在 `.env` 文件中设置。如果在 `.env.[mode]` 文件中指定了 `NODE_ENV`，则可以使用模式来控制其值。不过，`NODE_ENV` 和模式仍然是两个不同的概念。
 
-The main benefit with `NODE_ENV=...` in the command is that it allows Vite to detect the value early. It also allows you to read `process.env.NODE_ENV` in your Vite config as Vite can only load the env files once the config is evaluated.
+命令中使用 `NODE_ENV=...` 的主要好处是，它允许 Vite 提前检测到该值。这也使你能够在 Vite 配置中读取 `process.env.NODE_ENV`，因为 Vite 只有在解析配置之后才能加载环境变量文件。
 :::
diff --git a/guide/features.md b/guide/features.md
@@ -112,7 +112,7 @@ Vite 默认不会转译 TypeScript，而是使用 `esbuild` 的默认行为。
 - [`alwaysStrict`](https://www.typescriptlang.org/tsconfig#alwaysStrict)
 
 ::: tip `skipLibCheck`
-Vite 启动模板默认情况下会设置 `"skipLibCheck": "true"`，以避免对依赖项进行类型检查，因为它们可能只支持特定版本和配置的 TypeScript。你可以在 [vuejs/vue-cli#5688](https://github.com/vuejs/vue-cli/pull/5688)。
+Vite 启动模板默认情况下会设置 `"skipLibCheck": "true"`，以避免对依赖项进行类型检查，因为它们可能只支持特定版本和配置的 TypeScript。你可以在 [vuejs/vue-cli#5688](https://github.com/vuejs/vue-cli/pull/5688) 了解更多信息。
 :::
 
 ### 客户端类型 {#client-types}
@@ -166,7 +166,7 @@ Vite 为 Vue 提供第一优先级支持：
 - Vue 3 单文件组件支持：[@vitejs/plugin-vue](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue)
 - Vue 3 JSX 支持：[@vitejs/plugin-vue-jsx](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue-jsx)
 - Vue 2.7 SFC 支持：[@vitejs/plugin-vue2](https://github.com/vitejs/vite-plugin-vue2)
-- Vue 2.7 JSX support via [@vitejs/plugin-vue2-jsx](https://github.com/vitejs/vite-plugin-vue2-jsx)
+- Vue 2.7 JSX 支持：[@vitejs/plugin-vue2-jsx](https://github.com/vitejs/vite-plugin-vue2-jsx)
 
 ## JSX {#jsx}
 

diff --git a/guide/index.md b/guide/index.md
@@ -74,7 +74,7 @@ $ bun create vite
 ::: code-group
 
 ```bash [NPM]
-# npm 7+，需要添加额外的双破折号：
+# npm 7+，需要添加额外的 --：
 $ npm create vite@latest my-vue-app -- --template vue
 ```
 

diff --git a/guide/static-deploy.md b/guide/static-deploy.md
@@ -59,7 +59,7 @@ $ npm run preview
 
    如果你正要部署到 `https://<USERNAME>.github.io/`，或者通过 GitHub Pages 部署到一个自定义域名（例如 `www.example.com`），请将 `base` 设置为 `'/'`。或者，你也可以从配置中移除 `base`，因为它默认为 `'/'`。
 
-   如果你正在部署到 `https://<USERNAME>.github.io/<REPO>/`（例如你的仓库地址为 `https://github.com<USERNAME>/<REPO>`），那么请将 `base` 设置为 `'/<REPO>/'`。
+   如果你正在部署到 `https://<USERNAME>.github.io/<REPO>/`（例如你的仓库地址为 `https://github.com/<USERNAME>/<REPO>`），那么请将 `base` 设置为 `'/<REPO>/'`。
 
 2. 进入仓库 settings 页面的 GitHub Pages 配置，选择部署来源为“GitHub Actions”，这将引导你创建一个构建和部署项目的工作流程，我们提供了一个安装依赖项和使用 npm 构建的工作流程样本：
 
@@ -183,7 +183,7 @@ $ ntl deploy --prod
 4. 点击 **部署**
 5. 你的 Vite 应用就部署完成了！
 
-在你的项目被导入和部署后，所有对生产分支以外的其他分支（可能来自合并请求）的后续推送都会生成 [预览部署](https://docs.netlify.com/site-deploys/deploy-previews/)，所有对生产分支（通常是 “main”）都会生成一个 [生产部署](https://docs.netlify.com/site-deploys/overview/#definitions)。
+在你的项目被导入和部署后，所有对生产分支以外的其他分支（可能来自合并请求）的后续推送都会生成 [预览部署](https://docs.netlify.com/site-deploys/deploy-previews/)，所有对生产分支（通常是 "main"）的更改都会生成一个 [生产部署](https://docs.netlify.com/site-deploys/overview/#definitions)。
 
 ## Vercel {#vercel}
 
@@ -208,7 +208,7 @@ Vercel CLI
 3. Vercel 会检测到你正在使用 Vite，并会为你的部署开启相应的正确配置。
 4. 你的应用被部署好了！（示例：[vite-vue-template.vercel.app](https://vite-vue-template.vercel.app/)）
 
-在你的项目被导入和部署后，所有对分支的后续推送都会生成 [预览部署](https://vercel.com/docs/concepts/deployments/environments#preview)，而所有对生产分支（通常是“main”）的更改都会生成一个 [生产构建](https://vercel.com/docs/concepts/deployments/environments#production)
+在你的项目被导入和部署后，所有对分支的后续推送都会生成 [预览部署](https://vercel.com/docs/concepts/deployments/environments#preview)，而所有对生产分支（通常是"main"）的更改都会生成一个 [生产构建](https://vercel.com/docs/concepts/deployments/environments#production)
 
 查看 Vercel 的 [Git 集成](https://vercel.com/docs/concepts/git) 了解更多细节。
 

diff --git a/guide/why.md b/guide/why.md
@@ -33,7 +33,7 @@ import esmSvg from '../images/esm.svg?raw'
 
 ### 缓慢的更新 {#slow-updates}
 
-基于打包器启动时，重建整个包的效率很低。原因显而易见：因为这样更新速度会随着应用体积增长而直线下降。
+基于打包启动时，当源文件被修改后，重新构建整个包是低效的，原因显而易见：更新速度会随着应用体积的增加而线性下降。
 
 一些打包器的开发服务器将构建内容存入内存，这样它们只需要在文件更改时使模块图的一部分失活<sup>[[1]](#footnote-1)</sup>，但它也仍需要整个重新构建并重载页面。这样代价很高，并且重新加载页面会消除应用的当前状态，所以打包器支持了动态模块热替换（HMR）：允许一个模块 “热替换” 它自己，而不会影响页面其余部分。这大大改进了开发体验 —— 然而，在实践中我们发现，即使采用了 HMR 模式，其热更新速度也会随着应用规模的增长而显著下降。