docs(cn): standardize the translations of the word fallback

src/content/blog/2022/03/08/react-18-upgrade-guide.md

@@ -305,7 +305,7 @@ globalThis.IS_REACT_ACT_ENVIRONMENT = true;
 * **一致的 useEffect 时间**：现在，如果更新是在类似点击或者敲击键盘事件这样的离散用户输入事件期间触发，React 总是同步刷新 effect 函数。而之前的行为不是一直可预测或者一致的。
 * **更严格的 hydrate 报错**：由于缺失或者额外的文本而导致的 hydrate 不匹配现在会作为错误而不是告警对待。React 将不再试图通过在客户端增加或删除节点来“修补”单个节点来匹配服务端标记，并且将会回退客户端渲染到树中最近的 `<Suspense>` 边界。这可以保证 hydrate 树保持一致并且避免可能由 hydrate 不匹配导致的隐私和安全漏洞。
 * **Suspense 树一直保持一致**：如果一个组件在它完全被添加到树上之前挂起，React 将不会把它以不完整的状态添加到树或者触发它的 effect。React 会完全扔掉新树，等待异步操作结束，然后重新尝试从头开始再次渲染。React 会同时渲染重试尝试，并且不会阻塞浏览器。
-* **使用 Suspense 的 Layout Effect**：当一个树重新挂起并恢复为回退时，现在的 React 会清理 layout effect，然后在边界内的内容再次显示时重新创建它们。这修复了一个在与 Suspense 一起使用时的问题：阻止组件库正确测量布局。
+* **使用 Suspense 的 Layout Effect**：当一个树重新挂起并恢复为后备方案时，现在的 React 会清理 layout effect，然后在边界内的内容再次显示时重新创建它们。这修复了一个在与 Suspense 一起使用时的问题：阻止组件库正确测量布局。
 * **新的 JavaScript 环境要求**：React 现在依赖于现代浏览器特性，包括 `Promise`、`Symbol` 和 `Object.assign`。如果你需要支持像 Internet Explorer 这样较老版本的浏览器和设备，它们本身不提供现代浏览器特性或者有不兼容的实现，可以考虑在打包后的应用中包含全局的 polyfill。
 
 ## 其他值得注意的变化 {/*other-notable-changes*/}
@@ -320,8 +320,8 @@ globalThis.IS_REACT_ACT_ENVIRONMENT = true;
 
 ### React DOM Server {/*react-dom-server*/}
 
-* **`renderToString`**：当在服务端挂起时，它不再会报错。而是会为最接近的 `<Suspense>` 边界发射 fallback HTML，然后在客户端尝试渲染同样的内容。我们仍然推荐你切换到像 `renderToPipeableStream` 或者 `renderToReadableStream` 这样的流式 API。
-* **`renderToStaticMarkup`**：当在服务端挂起时，它不再会报错。而是会为最接近的 `<Suspense>` 边界发射 fallback HTML。
+* **`renderToString`**：当在服务端挂起时，它不再会报错。而是会为最接近的 `<Suspense>` 边界发射后备 HTML，然后在客户端尝试渲染同样的内容。我们仍然推荐你切换到像 `renderToPipeableStream` 或者 `renderToReadableStream` 这样的流式 API。
+* **`renderToStaticMarkup`**：当在服务端挂起时，它不再会报错。而是会为最接近的 `<Suspense>` 边界发射后备 HTML。
 
 ## 更新日志 {/*changelog*/}
 

src/content/blog/2022/03/29/react-v18.md

@@ -74,7 +74,7 @@ React 18 中最重要的更新内容是我们希望你永远不会考虑的：
 
 在未来，我们可能会暴露更多原语，使你能用 `Suspense` 更容易地获取数据，那时也就不一定必须要使用某个的框架。不过，Suspense 被深度整合到你的应用结构中时能产生最好的效果：你的路由，你的数据层，你的服务端渲染环境。因此我们预计，即使在未来相当长一段时间里，库和框架也还会在 React 生态中发挥关键作用。
 
-就像在过去的 React 的版本中，你总是可以使用 Suspense 与客户端侧的 `React.lazy` 配合进行代码分割。但是我们的对 Suspense 的期望并不仅仅是加载代码——最终的目标是扩展对 Suspense 的支持，以至于相同的声明式 Suspense fallback 能够处理任何异步操作（加载代码，数据，图片等）。
+就像在过去的 React 的版本中，你总是可以使用 Suspense 与客户端侧的 `React.lazy` 配合进行代码分割。但是我们的对 Suspense 的期望并不仅仅是加载代码——最终的目标是扩展对 Suspense 的支持，以至于相同的声明式 Suspense 后备方案能够处理任何异步操作（加载代码，数据，图片等）。
 
 ## 服务器组件仍在开发中 {/*server-components-is-still-in-development*/}
 
@@ -162,7 +162,7 @@ Suspense 使得“UI 加载状态”成为了 React 编程模型中最高级的
 
 在 React 18 中，我们已经支持了服务端 Suspense，并且使用并发渲染特性扩展了其功能。
 
-React 18 中的 Suspense 在与 transition API 结合时效果最好。如果你在 transition 期间挂起，React 不会让已显示的内容被之前的内容取代。相反，React 会延迟渲染，直到有足够的数据，以防止出现加载状态错误。
+React 18 中的 Suspense 在与 transition API 结合时效果最好。如果你在 transition 期间挂起，React 不会让已显示的内容被后备方案取代。相反，React 会延迟渲染，直到有足够的数据，以防止出现加载状态错误。
 
 更多内容参见 [React 18 中的 Suspense](https://github.com/reactjs/rfcs/blob/main/text/0213-suspense-in-react-18.md) 的意见征求。
 

src/content/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023.md

@@ -85,7 +85,7 @@ React 的核心思想是开发人员将其 UI 定义为当前状态的函数。
 
 我们的想法是，开发者应该能够在不更改组件编写方式的情况下，将任何 React 树渲染到屏幕外。当组件被离屏渲染时，它实际上并没有 **挂载**，直到组件变为可见状态——其效果不会被触发。例如，如果组件使用 `useEffect` 在首次出现时记录分析数据，预渲染不会影响数据的准确性。同样，当组件离开屏幕时，其效果也会被卸载。离屏渲染的一个关键特性是，可以切换组件的可见性，而不会失去其状态。
 
-自上次更新以来，我们在 Meta 的 React Native 应用程序上测试了一个实验性的预渲染版本，包括 Android 和 iOS，性能表现良好。我们还改进了离屏渲染与 Suspense 的配合方式——在离屏树中挂起（suspend）但不会触发 suspense fallback。我们剩下的工作是完成向库开发人员公开的基本组件。我们预计将于今年晚些时候发布一个 RFC，同时发布一个实验性的 API 用于测试和反馈。
+自上次更新以来，我们在 Meta 的 React Native 应用程序上测试了一个实验性的预渲染版本，包括 Android 和 iOS，性能表现良好。我们还改进了离屏渲染与 Suspense 的配合方式——在离屏树中挂起（suspend）但不会触发 Suspense 后备方案。我们剩下的工作是完成向库开发人员公开的基本组件。我们预计将于今年晚些时候发布一个 RFC，同时发布一个实验性的 API 用于测试和反馈。
 
 ## 追踪 transition {/*transition-tracing*/}
 

src/content/reference/react-dom/flushSync.md

@@ -43,7 +43,7 @@ flushSync(() => {
 #### 参数 {/*parameters*/}
 
 
-* `callback`：一个函数。React 会立即调用这个回调函数，并同步刷新其中包含的任何更新。它也可能会刷新任何挂起的更新、Effect 或 Effect 内部的更新。如果因为调用 `flushSync` 而导致更新挂起（suspend），则可能会重新显示 fallback。
+* `callback`：一个函数。React 会立即调用这个回调函数，并同步刷新其中包含的任何更新。它也可能会刷新任何挂起的更新、Effect 或 Effect 内部的更新。如果因为调用 `flushSync` 而导致更新挂起（suspend），则可能会重新显示后备方案。
 
 #### 返回值 {/*returns*/}
 
@@ -126,7 +126,7 @@ export default function PrintApp() {
 
 <Pitfall>
 
-`flushSync` 可能会严重影响性能，并且可能会意外地强制挂起的 Suspense 边界显示其 fallback 状态。
+`flushSync` 可能会严重影响性能，并且可能会意外地强制挂起的 Suspense 边界显示其后备状态。
 
 大多数时候都不需要使用 `flushSync`，请将其作为最后的手段使用。
 

src/content/reference/react-dom/server/renderToPipeableStream.md

@@ -57,8 +57,8 @@ const { pipe } = renderToPipeableStream(<App />, {
   * **可选** `nonce`：[`nonce`](http://developer.mozilla.org/zh-CN/docs/Web/HTML/Element/script#nonce) 一个字符串，能为脚本设置跨域限制，即 [`script-src` 浏览器内容安全策略](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Security-Policy/script-src)。
   * **可选** `onAllReady`：一个回调函数，将会在所有渲染完成时触发，包括 [shell](#specifying-what-goes-into-the-shell) 和所有额外的 [content](#streaming-more-content-as-it-loads)。你可以用这个替代 `onShellReady` [用于爬虫和静态内容生成](#waiting-for-all-content-to-load-for-crawlers-and-static-generation)。如果在此处开启了流式传输，所有的 HTML 都会被包含在流中直接返回，而不会有任何渐进的加载。
   * **可选** `onError`：一个回调函数，只要是出现了异常错误，无论这是 [可恢复的](#recovering-from-errors-outside-the-shell) 还是 [不可恢复的](#recovering-from-errors-inside-the-shell)，它都会触发。默认情况下，它只会调用 `console.error`。如果你想要将它重写为 [日志崩溃报告](#logging-crashes-on-the-server)，记得仍然要使用 `console.error` 为可能不兼容的场景兜底。你也可以在 shell 发送之前使用它来 [修改状态码](#setting-the-status-code)。
-  * **可选** `onShellReady`：一个回调函数，在 [shell 初始化](#specifying-what-goes-into-the-shell) 渲染后立即调用。你可以 [设置状态码](#setting-the-status-code) 然后在这里调用 `pipe` 方法启用流式传输。这样一来，React 将会初始化 shell 渲染完毕后，通过上面提到的 `<script>` 进行 [流式传输更多内容](#streaming-more-content-as-it-loads)，用这些内容替换掉 HTML 的加载动画部分。
-  * **可选** `onShellError`：一个回调函数，在初始化 shell 发生错误渲染时调用。它的第一个参数将自动接收捕获到的异常错误。此时，这个流中的任何内容都不会被发送，并且 `onShellReady` 和 `onAllReady` 都不会被调用，所以你还可以 [输出一段备用的 HTML shell](#recovering-from-errors-inside-the-shell) 作为兜底。
+  * **可选** `onShellReady`：一个回调函数，在 [shell 初始化](#specifying-what-goes-into-the-shell) 渲染后立即调用。你可以 [设置状态码](#setting-the-status-code) 然后在这里调用 `pipe` 方法启用流式传输。这样一来，React 将会初始化 shell 渲染完毕后，通过上面提到的 `<script>` 进行 [流式传输更多内容](#streaming-more-content-as-it-loads)，用这些内容替换掉 HTML 的加载中的后备方案。
+  * **可选** `onShellError`：一个回调函数，在初始化 shell 发生错误渲染时调用。它的第一个参数将自动接收捕获到的异常错误。此时，这个流中的任何内容都不会被发送，并且 `onShellReady` 和 `onAllReady` 都不会被调用，所以你还可以 [输出一段后备 HTML shell](#recovering-from-errors-inside-the-shell) 作为兜底。
   * **可选** `progressiveChunkSize`：一个块中的字节数。[查阅更多关于该参数默认值的信息](https://github.com/facebook/react/blob/14c2be8dac2d5482fda8a0906a31d239df8551fc/packages/react-server/src/ReactFizzServer.js#L210-L225)。
 
 
@@ -253,7 +253,7 @@ function ProfilePage() {
 }
 ```
 
-这样做将通知 React 在 `Posts` 加载数据之前就开始流式传输 HTML。React 首先会发送加载动画（`PostsGlimmer`）对应的 HTML，然后当 `Posts` 的数据加载完成时，React 会将剩下的 HTML 带上一个 `<script>` 标签一并发送，这个 `<script>` 的作用是将加载动画替换为这段 HTML。从用户的角度上看，页面上首先出现的是 `PostsGlimmer`，稍后被替换为 `Posts`。
+这样做将通知 React 在 `Posts` 加载数据之前就开始流式传输 HTML。React 首先会发送加载中的后备方案（`PostsGlimmer`）对应的 HTML，然后当 `Posts` 的数据加载完成时，React 会将剩下的 HTML 带上一个 `<script>` 标签一并发送，这个 `<script>` 的作用是将加载中的后备方案替换为这段 HTML。从用户的角度上看，页面上首先出现的是 `PostsGlimmer`，稍后被替换为 `Posts`。
 
 你可以进一步地 [嵌套 `<Suspense>`](/reference/react/Suspense#revealing-nested-content-as-it-loads) 来创建一个更加细致的加载序列：
 
@@ -276,7 +276,7 @@ function ProfilePage() {
 }
 ```
 
-在这个例子中，React 甚至能够更早地启用流式传输。因为 `ProfileLayout` 和 `ProfileCover` 没有被包裹在 `<Suspense>` 中，所以它们必须先完成渲染。然而，如果 `Sidebar`、`Friend` 或者 `Photos` 需要加载更多数据，React 将会发送加载动画 `BigSpinner` 对应的 HTML 暂时替代有效内容。然后，当这些数据加载完成时，有效内容将渐进地显示直至全部可见。
+在这个例子中，React 甚至能够更早地启用流式传输。因为 `ProfileLayout` 和 `ProfileCover` 没有被包裹在 `<Suspense>` 中，所以它们必须先完成渲染。然而，如果 `Sidebar`、`Friend` 或者 `Photos` 需要加载更多数据，React 将会发送后备方案 `BigSpinner` 所对应的 HTML 暂时替代有效内容。然后，当这些数据加载完成时，有效内容将渐进地显示直至全部可见。
 
 流式传输不需要等待 React 本身在浏览器中的加载，也不需要等待你的应用程序变得可交互。在任何 `<script>` 标签加载之前，服务端发送的 HTML 内容就会开始渐进式地显示。
 
@@ -389,7 +389,7 @@ function ProfilePage() {
 }
 ```
 
-在这些组件渲染的过程中，如果发生了异常错误，React 就不会发送任何有效的 HTML 到客户端。重载 `onShellError` ，发送一个不依赖服务端渲染的 HTML 作为兜底处理方案：
+在这些组件渲染的过程中，如果发生了异常错误，React 就不会发送任何有效的 HTML 到客户端。重载 `onShellError`，发送一个不依赖服务端渲染的 HTML 作为后备方案：
 
 ```js {7-11}
 const { pipe } = renderToPipeableStream(<App />, {
@@ -410,7 +410,7 @@ const { pipe } = renderToPipeableStream(<App />, {
 });
 ```
 
-如果在生成 shell 的过程中出现异常错误，`onError` 和 `onShellError` 都会触发。使用 `onError` 来做错误上报，并且使用 `onShellError` 发送一个兜底的 HTML 文档。你的兜底 HTML 不一定要是一个错误提示页面。你还可以引入一个可交互的、并且只在客户端渲染你的应用程序的 shell。
+如果在生成 shell 的过程中出现异常错误，`onError` 和 `onShellError` 都会触发。使用 `onError` 来做错误上报，并且使用 `onShellError` 发送一个后备 HTML 文档。你的后备 HTML 不一定要是一个错误提示页面。你还可以引入一个可交互的、并且只在客户端渲染你的应用程序的 shell。
 
 ---
 
@@ -433,13 +433,13 @@ function ProfilePage() {
 
 如果 `Post` 组件本身或者其内部的某处发生异常报错，React 将会 [试图将它恢复](/reference/react/Suspense#providing-a-fallback-for-server-errors-and-server-only-content)：
 
-1. 它将用在结构上和异常发生的位置最近的一个父级 `<Suspense>` 的加载动画（`PostsGlimmer`）替代这段 HTML。
+1. 它将用在结构上和异常发生的位置最近的一个父级 `<Suspense>` 的加载中的后备方案（`PostsGlimmer`）替代这段 HTML。
 2. 它将会“放弃”尝试在服务端渲染 `Posts` 组件的内容。
 3. 当 JavaScript 在客户端代码加载时，React 将会在客户端 **重试** 渲染 `Posts` 组件。
 
 如果在客户端重试渲染 `Posts` **也** 失败了，React 将会在客户端抛出一个异常错误。当渲染过程中的所有异常错误都被抛出时，距离它们[最近的父级异常错误边界](/reference/react/Component#static-getderivedstatefromerror) 会定义这个异常错误将如何呈现给用户。实际上，这意味着用户将看到一个加载指示器，直到这个异常错误被判定为是不可恢复的。
 
-如果在客户端重试渲染 `Posts` 成功了，加载动画将被替换为客户端渲染的内容。这样一来用户感知到服务端出现了异常错误。不过，服务端的 `onError` 回调函数和客户端的 [`onRecoverableError`](/reference/react-dom/client/hydrateRoot#hydrateroot) 回调函数仍然会触发，所以你也可以获取到一些关于这个异常错误的提示信息。
+如果在客户端重试渲染 `Posts` 成功了，加载中的后备方案将被替换为客户端渲染的内容。这样一来用户感知到服务端出现了异常错误。不过，服务端的 `onError` 回调函数和客户端的 [`onRecoverableError`](/reference/react-dom/client/hydrateRoot#hydrateroot) 回调函数仍然会触发，所以你也可以获取到一些关于这个异常错误的提示信息。
 
 ---
 
@@ -605,4 +605,4 @@ setTimeout(() => {
 }, 10000);
 ```
 
-React 将会刷新内容，把剩余的加载动画转为 HTML，然后尝试在客户端渲染剩下的内容。
+React 将会刷新内容，把剩余的加载中的后备方案转为 HTML，然后尝试在客户端渲染剩下的内容。