docs(cn): fix all conflicts.

Author: ShenQingchuan

guide/dep-pre-bundling.md

@@ -3,17 +3,10 @@
 当你首次启动 `vite` 时，你可能会注意到打印出了以下信息：
 
 ```
-<<<<<<< HEAD
-Optimizable dependencies detected: （侦测到可优化的依赖：）
-react, react-dom
-Pre-bundling them to speed up dev server page load...（将预构建它们以提升开发服务器页面加载速度）
-(this will be run only when your dependencies have changed)（这将只会在你的依赖发生变化时执行）
-=======
-Pre-bundling dependencies:
-  react
+Pre-bundling dependencies: （正在预构建依赖：）
+  react, 
   react-dom
-(this will be run only when your dependencies or config have changed)
->>>>>>> 638b2518b7f414c23ef231de3449c9aacfe2dc3e
+(this will be run only when your dependencies or config have changed)（这将只会在你的依赖或配置发生变化时执行）
 ```
 
 ## 原因 {#the-why}
@@ -35,30 +28,19 @@ Pre-bundling dependencies:
 
    通过预构建 `lodash-es` 成为一个模块，我们就只需要一个 HTTP 请求了！
 
-<<<<<<< HEAD
-## 自动依赖搜寻 {#automatic-dependency-discovery}
-=======
-Note that this only applies in development mode.
+请注意，这只会应用在开发模式下。
 
-## Automatic Dependency Discovery
->>>>>>> 638b2518b7f414c23ef231de3449c9aacfe2dc3e
+## 自动依赖搜寻 {#automatic-dependency-discovery}
 
 如果没有找到相应的缓存，Vite 将抓取你的源码，并自动寻找引入的依赖项（即 "bare import"，表示期望从 `node_modules` 解析），并将这些依赖项作为预构建包的入口点。预构建通过 `esbuild` 执行，所以它通常非常快。
 
 在服务器已经启动之后，如果遇到一个新的依赖关系导入，而这个依赖关系还没有在缓存中，Vite 将重新运行依赖构建进程并重新加载页面。
 
 ## Monorepo 和链接依赖 {#monorepos-and-linked-dependencies}
 
-<<<<<<< HEAD
 在一个 monorepo 启动中，该仓库中的某个依赖可能会成为另一个包的依赖。Vite 会自动侦测没有从 `node_modules` 解析的依赖项，并将链接的依赖视为源码。它不会尝试打包被链接的依赖，而是会分析被链接依赖的依赖列表。
 
-::: warning Note
-由于依赖关系的处理方式不同，链接的依赖关系在最终构建时可能无法正常工作。
-使用 `npm pack` 代替所有本地依赖，以避免最终打包时出现问题。（`npm pack` 只有在链接的源代码或包只导出 CJS 代码时才需要。如果它导出 ESM 代码，则不需要使用它。
-=======
-In a monorepo setup, a dependency may be a linked package from the same repo. Vite automatically detects dependencies that are not resolved from `node_modules` and treats the linked dep as source code. It will not attempt to bundle the linked dep, and will analyze the linked dep's dependency list instead.
-
-However, this requires the linked dep to be exported as ESM. If not, you can add the dependency to [`optimizeDeps.include`](/config/#optimizedeps-include) and [`build.commonjsOptions.include`](/config/#build-commonjsoptions) in your config.
+然而，这需要被链接的依赖被导出为 ESM 格式。如果不是，那么你可以在配置里将此依赖添加到 [`optimizeDeps.include`](/config/#optimizedeps-include) 和 [`build.commonjsOptions.include`](/config/#build-commonjsoptions) 这两项中。
 
 ```js
 export default defineConfig({
@@ -73,11 +55,10 @@ export default defineConfig({
 })
 ```
 
-When making changes to the linked dep, restart the dev server with the `--force` command line option for the changes to take effect.
+当这个被链接的依赖发生变更后，在重启开发服务器时在命令中带上 `--force` 选项让所有更改生效。
 
-::: warning Deduping
-Due to differences in linked dependency resolution, transitive dependencies can deduplicated incorrectly, causing issues when used in runtime. If you stumble on this issue, use `npm pack` on the linked dependency to fix it.
->>>>>>> 638b2518b7f414c23ef231de3449c9aacfe2dc3e
+::: warning 重复删除
+由于对链接依赖的解析方式不同，传递性的依赖项可能会不正确地进行重复数据删除，而造成运行时的问题。如果你偶然发现了这个问题，请使用 `npm pack` 来修复它。
 :::
 
 ## 自定义行为 {#customizing-the-behavior}
@@ -94,15 +75,9 @@ Due to differences in linked dependency resolution, transitive dependencies can
 
 Vite 会将预构建的依赖缓存到 `node_modules/.vite`。它根据几个源来决定是否需要重新运行预构建步骤:
 
-<<<<<<< HEAD
 - `package.json` 中的 `dependencies` 列表
 - 包管理器的 lockfile，例如 `package-lock.json`, `yarn.lock`，或者 `pnpm-lock.yaml`
 - 可能在 `vite.config.js` 相关字段中配置过的
-=======
-- The `dependencies` list in your `package.json`.
-- Package manager lockfiles, e.g. `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`.
-- Relevant fields in your `vite.config.js`, if present.
->>>>>>> 638b2518b7f414c23ef231de3449c9aacfe2dc3e
 
 只有在上述其中一项发生更改时，才需要重新运行预构建。
 

guide/why.md

@@ -32,11 +32,7 @@ Vite 通过在一开始将应用中的模块区分为 **依赖** 和 **源码**
 
 基于打包器启动时，重建整个包的效率很低。原因显而易见：因为这样更新速度会随着应用体积增长而直线下降。
 
-<<<<<<< HEAD
 一些打包器的开发服务器将构建内容存入内存，这样它们只需要在文件更改时使模块图的一部分失活<sup>[[1]](#footnote-1)</sup>，但它也仍需要整个重新构建并重载页面。这样代价很高，并且重新加载页面会消除应用的当前状态，所以打包器支持了动态模块热重载（HMR）：允许一个模块 “热替换” 它自己，而不会影响页面其余部分。这大大改进了开发体验 —— 然而，在实践中我们发现，即使采用了 HMR 模式，其热更新速度也会随着应用规模的增长而显著下降。
-=======
-In some bundlers, the dev server runs the bundling in memory so that it only needs to invalidate part of its module graph when a file changes, but it still needs to re-construct the entire bundle and reload the web page. Reconstructing the bundle can be expensive, and reloading the page blows away the current state of the application. This is why some bundlers support Hot Module Replacement (HMR): allowing a module to "hot replace" itself without affecting the rest of the page. This greatly improves DX - however, in practice we've found that even HMR update speed deteriorates significantly as the size of the application grows.
->>>>>>> 638b2518b7f414c23ef231de3449c9aacfe2dc3e
 
 在 Vite 中，HMR 是在原生 ESM 上执行的。当编辑一个文件时，Vite 只需要精确地使已编辑的模块与其最近的 HMR 边界之间的链失活<sup>[[1]](#footnote-1)</sup>（大多数时候只是模块本身），使得无论应用大小如何，HMR 始终能保持快速更新。