Merge pull request #1655 from vitejs/main

m2d

Author: thinkasany

guide/api-environment-frameworks.md

@@ -115,13 +115,13 @@ if (import.meta.hot) {
 
 :::info
 
-我们正在征集对[`FetchableDevEnvironment`提案](https://github.com/vitejs/vite/discussions/18191)的反馈意见。
+我们正在征集对 [`FetchableDevEnvironment` 提案](https://github.com/vitejs/vite/discussions/18191) 的反馈意见。
 
 :::
 
 `FetchableDevEnvironment` 是一种可以通过 [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch) 接口与运行时进行通信的环境。由于 `RunnableDevEnvironment` 仅能在有限的运行时环境中实现，我们建议使用 `FetchableDevEnvironment` 替代 `RunnableDevEnvironment`。
 
-该环境通过`handleRequest`方法提供了一种标准化的请求处理方式：
+该环境通过 `handleRequest` 方法提供了一种标准化的请求处理方式：
 
 ```ts
 import {
@@ -305,7 +305,7 @@ export function createHandler(input) {
 
 在命令行接口中，调用 `vite build` 和 `vite build --ssr` 仍将只构建客户端和仅 ssr 环境以保证向后兼容性。
 
-当 `builder` 选项 为 `undefined` 时（或者调用 `vite build --app`）时，`vite build` 将选择构建整个应用。这将在未来的主要版本中成为默认设置。将创建一个 `ViteBuilder` 实例（构建时等同于 `ViteDevServer`），用于为生产环境构建所有配置的环境。默认情况下，环境的构建按照 `environments` 记录的顺序依次运行。框架或用户可以进一步使用 `builder.buildApp` 选项配置环境的构建方式：
+当 `builder` 选项不为 `undefined` 时（或者调用 `vite build --app`）时，`vite build` 将选择构建整个应用。这将在未来的主要版本中成为默认设置。将创建一个 `ViteBuilder` 实例（构建时等同于 `ViteDevServer`），用于为生产环境构建所有配置的环境。默认情况下，环境的构建按照 `environments` 记录的顺序依次运行。框架或用户可以进一步使用 `builder.buildApp` 选项配置环境的构建方式：
 
 ```js [vite.config.js]
 import { defineConfig } from 'vite'
@@ -322,7 +322,7 @@ export default defineConfig({
 })
 ```
 
-插件还可以定义一个 `buildApp` 钩子。顺序 `'pre'` 和 `'null'` 在配置的 `builder.buildApp` 之前执行，顺序 `'post'` 钩子在其之后执行。`environment.isBuilt` 可用于检查环境是否已被构建。
+插件还可以定义一个 `buildApp` 钩子。顺序 `'pre'` 和 `null` 在配置的 `builder.buildApp` 之前执行，顺序 `'post'` 钩子在其之后执行。`environment.isBuilt` 可用于检查环境是否已被构建。
 
 ## 环境无关的代码 {#environment-agnostic-code}
 

guide/api-environment.md

@@ -94,11 +94,11 @@ interface UserConfig extends EnvironmentOptions {
 }
 ```
 
-请注意，一旦环境 API 稳定， `ssr` 顶级属性将被废弃。该选项的作用与 `environments` 相同，但针对的是默认的 `ssr` 环境，而且只允许配置一小部分选项。
+请注意，一旦环境 API 稳定，`ssr` 顶级属性将被废弃。该选项的作用与 `environments` 相同，但针对的是默认的 `ssr` 环境，而且只允许配置一小部分选项。
 
 ## 自定义环境实例 {#custom-environment-instances}
 
-底层 API 配置已可用，因此可以支持为运行时提供环境。这些环境还可以生成其他进程或线程，以便在更接近生产环境的运行时间内运行开发模块。
+底层 API 配置已可用，因此可以支持为运行时提供环境。这些环境还可以生成其他进程或线程，以便在更接近生产环境的运行时内运行开发模块。
 
 例如，[Cloudflare Vite 插件](https://developers.cloudflare.com/workers/vite-plugin/) 使用环境 API 在开发过程中在 Cloudflare Workers 运行时 (`workerd`) 中运行代码。
 
@@ -123,13 +123,13 @@ export default {
 
 当前的 Vite 服务器 API 尚未被弃用，并且与 Vite 5 向后兼容。
 
-`server.moduleGraph` 返回客户端和服务器端渲染（ssr）模块图的混合视图。所有其方法都将返回向后兼容的混合模块节点。对于传递给 `handleHotUpdate` 的模块节点，也使用相同的方案。
+`server.moduleGraph` 返回客户端和服务器端渲染（ssr）模块图的混合视图。其所有方法都将返回向后兼容的混合模块节点。对于传递给 `handleHotUpdate` 的模块节点，也使用相同的方案。
 
 我们不建议现在就切换到环境 API。我们的目标是在插件不需要维护两个版本之前，让大部分用户基础采用 Vite 6。查看未来破坏性更改部分以获取未来弃用和升级路径的信息：
 
 - [钩子函数中的 `this.environment`](/changes/this-environment-in-hooks)
 - [HMR `hotUpdate` 插件钩子](/changes/hotupdate-hook)
-- [迁移到基于环境的API](/changes/per-environment-apis)
+- [迁移到基于环境的 API](/changes/per-environment-apis)
 - [使用 `ModuleRunner` API 进行服务端渲染](/changes/ssr-using-modulerunner)
 - [构建过程中的共享插件](/changes/shared-plugins-during-build)
 

guide/api-plugin.md

@@ -27,7 +27,7 @@ Vite 努力秉承开箱即用的原则，因此在创作一款新插件前，请
 对于 Vite 专属的插件：
 
 - Vite 插件应该有一个带 `vite-plugin-` 前缀、语义清晰的名称。
-- 在 package.json 中包含 `vite-plugin` 关键字。
+- 在 package.json 的 `keywords` 字段中添加 `vite-plugin` 关键字。
 - 在插件文档增加一部分关于为什么本插件是一个 Vite 专属插件的详细说明（如，本插件使用了 Vite 特有的插件钩子）。
 
 如果你的插件只适用于特定的框架，它的名字应该遵循以下前缀格式：