Astro 6 多语言 fallback 构建报 response body was empty

默认语言页面生成正常，缺少翻译、应当回退的语言页面却没有落盘，构建日志出现：

(file not created, response body was empty)

如果项目使用 Astro 6.1.1、i18n.fallback 和 fallbackType: 'rewrite'，可以核对多语言回退的预渲染路径。正式版 Astro 6.2.2 已包含这一空正文修复；不要因为构建过程最后退出成功，就认定所有语言文件都已生成。

rewrite 应当保留语言地址并生成回退内容

下面是配置的相关部分，需要与原配置合并，adapter 和其他构建设置保持项目自己的组合：

import { defineConfig } from 'astro/config';

export default defineConfig({
  i18n: {
    defaultLocale: 'en',
    locales: ['en', 'es', 'fr'],
    fallback: { es: 'en', fr: 'en' },
    routing: {
      prefixDefaultLocale: false,
      fallbackType: 'rewrite',
    },
  },
});

这里的 es、fr 是示例语言。rewrite 的预期是访问缺失翻译的语言地址时使用英文内容，地址仍留在目标语言路径。它不同于 redirect，后者让客户端跳转到回退语言 URL。

定位时选一个真实缺少译文、确实符合回退规则的页面，比较默认语言产物与目标语言产物。已有完整翻译的页面、真正的 404 和会抛出业务异常的页面，应分别看待，不能把它们全部当成正常回退。

修复涉及内部 fallback 响应的判断

受影响路径会为待回退路由生成内部响应，再交给 i18n 中间件处理。修复后的中间件根据内部 fallback 路由标记识别这一状态，用于回退计算，不再让这个空响应绕过应有的回退处理。

这不要求应用把所有 500 改成 404，也不需要给每个页面补一个新的 Response。直接改构建依赖中的错误状态，可能掩盖真实服务器错误，还会在下次安装时丢失。仅给页面追加 prerender = true 也没有修复这个判断；该形态本来就可能发生在预渲染期间。

在兼容分支上，把实际使用的 Astro 更新到包含修复、且与现有 adapter 兼容的版本。6.2.2 是已核对的正式修复节点，不是要求所有项目降到这个版本。保留原清单和锁文件，按项目现有包管理流程调整并检查差异，不必先删除锁文件让整个工具链重新漂移。

如果短期只能用 redirect，应先确认产品允许地址跳转，再改 fallbackType，并逐条检查目标 URL；这会改变导航语义，不能作为对 rewrite 行为完全等价的替换。

看输出文件，也看部署后的回退地址

重新构建后，确认原来缺失的目标语言页面已经实际生成且正文非空。打开对应输出文件，检查默认语言内容确实进入目标路径，同时保留已翻译页面的自身内容。再用正式部署方式访问这些地址，确认托管规则没有把它们改成 404 或不必要的跳转。

回退页面承载的是默认语言内容。语言标记、canonical 及站点的多语言链接仍需按实际内容策略核对，不能因为文件生成成功就把它当成已经完成翻译。若升级后仍有空正文，而该路由没有进入 i18n fallback，应保留新的日志继续查页面渲染、适配器和部署产物；不要把所有 Astro 空输出都归给这项修复。