概览

在 gt-next 6.2.0 中，我们通过一个 SWC 插件，在将处理逻辑从运行时迁移到构建阶段方面迈出了重要一步。 这种方式解锁了编译期哈希、预渲染翻译和更严格的校验等新能力——而且不会增加运行时开销。

为保持聚焦，我们先从三个关键改进入手。

• 编译期哈希
• 按需翻译
• 构建期 lint 规则

编译时哈希

虽然这只是一个相对较小的优化，但我们现在会在构建阶段执行哈希计算，而不是在运行时执行。
像 getGT() 和服务端的 <T> 这样的函数不再需要在每次调用时计算并缓存哈希，从而带来更稳定且一致的性能表现。

按需翻译

开发者在开发过程中最大的痛点之一，是不得不不断刷新页面才能看到字符串的实时更新。

getGT() 和 useGT() 遵循熟悉的 i18n 模式：

export default function Page() {
  const t = useGT()
  // const t = await getGT(); 服务器端使用

  return (
    <>
      {t('待翻译的内容')}
      {t('其他待翻译的内容')}
    </>
  )
}

我们刻意让 t() 保持同步，以与其他 i18n 库保持一致。 代价是形成了一个 两步翻译流程：

1. 先通过 API 注册文本。
2. 等待第二次渲染来显示翻译结果。

现在，多亏了编译器，可翻译内容会被提前扫描，并在编译时直接传递给 useGT() 或 getGT()。 这意味着翻译在运行时即可立即可用——无需刷新页面。

构建时代码检查

之前，要检测对 <T> 组件的不正确使用，需要通过自定义 linter 运行 gtx-cli。 这会导致开发环境和生产环境中的行为不一致。

从 6.2.0 开始，代码检查规则直接在 SWC 插件中强制执行。 如果有任何可翻译内容没有包裹在 <T> 组件中，你会在构建阶段收到错误，从而确保尽早发现问题。

为什么目前选择 SWC？

我们从运行时向构建时迁移还处于早期阶段。 我们先从 Next.js 开始，但很快也会支持其他框架。 提供同等功能的 Babel 插件已经在路线图上了。

gt-next 6.2.0 为更快速、更可靠的翻译工作流打下了基础。 通过将逻辑前移到构建阶段，我们在降低运行时复杂度的同时，让翻译更加即时、可预测。