# General Translation Changelog: gt-next 6.2.0: 使用 SWC 进行构建时处理
URL: https://generaltranslation.com/zh/blog/gt-next_v6_2_0.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 
Authors: Ernest McCarter
Published: 2025-08-19

## 概述

在 **gt-next 6.2.0** 中，我们借助一个 **SWC 插件**，朝着将处理从运行时迁移到构建时迈出了重要一步。
这种方式带来了编译时哈希、预渲染翻译和更严格的校验等新能力，同时不会增加运行时开销。

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

* **编译时哈希**
* **按需翻译**
* **构建时 lint 规则**

***

## 编译时哈希

虽然这只是一个比较小的优化，但我们现在会在**构建时计算哈希**，而不是在运行时期间计算。
像 [`getGT()`](/docs/react/nextjs/reference/functions/get-gt) 和服务端 [`<T>`](/docs/react/reference/components/t) 这样的函数不再需要在每次调用时都计算并缓存哈希，因此性能表现会更加稳定。

***

## 按需翻译

对开发者而言，开发时必须刷新页面才能看到字符串的实时更新，一直是最令人头疼的问题之一。

[`getGT()`](/docs/react/nextjs/reference/functions/get-gt) 和 [`useGT()`](/docs/react/reference/hooks/use-gt) 遵循常见的 i18n 模式：

```tsx title="page.tsx" copy
export default function Page() {
  const gt = useGT()
  // const gt = await getGT(); 用于服务端

  return (
    <>
      {gt('some content to translate')}
      {gt('some other content to translate')}
    </>
  )
}
```

我们刻意将 `gt()` 设计为同步，以与其他 i18n 库保持一致。
缺点是需要经过一个`两步翻译流程`：

1. 向 API 注册文本。
   2.	等待第二次渲染后才显示翻译结果。

现在，借助编译器，可翻译内容会预先扫描，并在编译时直接传入 [`useGT()`](/docs/react/reference/hooks/use-gt) 或 [`getGT()`](/docs/react/nextjs/reference/functions/get-gt)。
这意味着翻译在运行时即可立即使用——无需刷新页面。

***

## 构建时 Lint 检查

此前，要检测 [`<T>`](/docs/react/reference/components/t) 组件的错误用法，需要运行带有自定义 linter 的 `gtx-cli`。
这会导致**开发环境**和**生产环境**的行为不一致。

从 6.2.0 起，lint 规则现已直接由 SWC 插件强制执行。
如果有任何可翻译内容未包裹在 [`<T>`](/docs/react/reference/components/t) 组件中，你会收到**构建时报错**，从而确保问题能尽早发现。

***

## 为什么选择 SWC (目前) ？

我们从运行时迁移到构建时仍处于早期阶段。
我们先从 Next.js 开始，但很快也会支持其他框架。
具备相同功能的 Babel 插件也已列入路线图。

***

`gt-next 6.2.0` 为更快、更可靠的翻译工作流打下了基础。
通过将逻辑转移到构建时，我们在降低运行时复杂性的同时，也让翻译变得更即时、更可预测。

## Sitemap

See the full [sitemap](https://generaltranslation.com/sitemap.md) for all pages.