---
createdAt: 2026-04-20
updatedAt: 2026-05-18
title: 2026 年 Solid 最佳 i18n 解决方案 - 基准报告
description: 比较 Solid 国际化（i18n）库，如 solid-primitives、solid-i18next 和 Intlayer。关于包大小、泄漏和反应性的详细性能报告。
keywords:
  - benchmark
  - i18n
  - intl
  - solid
  - performance
  - intlayer
slugs:
  - doc
  - benchmark
  - solid
author: Aymeric PINEAU
applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
history:
  - version: 8.9.8
    date: 2026-05-18
    changes: "添加 GitHub 明星对比"
  - version: 8.7.12
    date: 2026-01-06
    changes: "初始化基准"
---

# Solid i18n 库 - 2026 基准报告

此页面是 Solid 上 i18n 解决方案的基准报告。

## 目录

<Toc/>

## 交互式基准

<I18nBenchmark framework="vite-solid" vertical/>

## 结果参考：

<ClickToOpenIframe
  src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md"
  width="100%"
  height="600px"
/>

> [查看完整的基准测试数据](https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-vite_solid.md)

查看完整的基准仓库 [此处](https://github.com/intlayer-org/benchmark-i18n/tree/main)。

## 简介

国际化解决方案是 Solid 应用中最重的依赖项之一。主要风险是发送不必要的内容：单个路由包中包含其他页面和其他语言的翻译。

随着应用增长，这个问题会迅速增加发送到客户端의 JavaScript，并减慢导航速度。

实际上，对于优化最差的实现，国际化页面的重量可能是非 i18n 版本的几倍。

另一个影响是开发者体验（DX）：如何声明内容、类型、命名空间组织、动态加载以及语言更改时的反应性。

## TL;DR

- **Intlayer**: 需要高级功能和优化的专业 Solid 应用的推荐选择（v8.7.12）。
- **@solid-primitives/i18n**: 简单项目的绝佳轻量级替代方案，但缺乏延迟加载等高级功能。
- **solid-i18next**: 标准但沉重的选项（约为 Intlayer 的 4.7 倍），具有与 React i18next 相同的缺点。
- **Paraglide**: 创新的方法，但在某些设置中 DX 复杂且存在 tree-shaking 问题。

## 测试您的应用

为了快速发现 i18n 泄漏问题，我建立了一个免费扫描仪，可在 [此处](https://intlayer.org/i18n-seo-scanner) 试用。

<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>

## 问题所在

限制多语言应用成本有两个关键杠杆：

- 按页面 / 命名空间拆分内容，这样在不需要时就不会加载整个字典
- 仅在需要时动态加载正确的语言

了解这些方案的技术限制：

**动态加载**

如果没有动态加载，大多数解决方案会从首次渲染开始将消息保留在内存中，这对于具有许多路由和语言的应用会产生显著开销。

使用动态加载，您接受一个权衡：减少初始 JS，但有时在切换语言时会有额外的请求。

**内容拆分**

围绕 `t('a.b.c')` 构建的语法非常方便，但往往鼓励在运行时保留大型 JSON 对象。这种模式使 tree-shaking 变得困难，除非库提供真正的按页面拆分策略。

## 研究方法

在此基准测试中，我们比较了以下库：

- `Base App`（无 i18n 库）
- `solid-intlayer` (v8.7.12)
- `@solid-primitives/i18n` (v2.2.1)
- `solid-i18next` (v17.0.2)
- `@inlang/paraglide-js` (v2.17.0)

框架是 `Solid`，应用包含 **10 个页面** 和 **10 种语言**。

我们比较了 **四种加载策略**：

| 策略         | 无命名空间（全局）                     | 具有命名空间（分层/scoped）                             |
| :----------- | :------------------------------------- | :------------------------------------------------------ |
| **静态加载** | **Static**: 启动时所有内容都在内存中。 | **Scoped static**: 按命名空间拆分；启动时加载所有内容。 |
| **动态加载** | **Dynamic**: 按需按语言加载。          | **Scoped dynamic**: 按命名空间和语言进行细粒度加载。    |

## 策略摘要

- **静态 (Static)**: 简单；初始加载后无网络延迟。缺点：包体积大。
- **动态 (Dynamic)**: 减轻初始重量（懒加载）。当您有多种语言时非常理想。
- **分层静态 (Scoped static)**: 保持代码有序（逻辑分离），无需复杂的额外网络请求。
- **分层动态 (Scoped dynamic)**: _代码拆分_ 和性能的最佳方法。通过仅加载当前视图和活动语言所需的内容来最小化内存使用。

## GitHub 星数

GitHub 星数是项目受欢迎程度、社区信任和长期相关性的有力指标。虽然星数不是技术质量的直接衡量标准，但它们反映了有多少开发人员发现该项目有用、关注其进展并可能采用它。在评估项目价值时，星数有助于比较不同方案的吸引力，并提供对生态系统增长的见解。

[![Star History Chart](https://api.star-history.com/chart?repos=solidjs-community%2Fsolid-primitives%2Cmbarzda%2Fsolid-i18next%2Copral%2paraglide-js%2Caymericzip%2Fintlayer&type=date&legend=top-left)](https://www.star-history.com/#solidjs-community/solid-primitives&mbarzda/solid-i18next&opral/paraglide-js&aymericzip/intlayer)

## 结果详情

### 1 - 应当避免的解决方案

> Solid 生态系统中没有明确应当避免的解决方案。

### 2 - 可接受的解决方案

**(solid-i18next)** (`solid-i18next@17.0.2`):

`solid-i18next` 可能是最受欢迎的选项，因为它是最早满足 JavaScript 应用 i18n 需求的解决方案之一。它还拥有一套广泛的社区插件来解决特定问题。

该包很重（~14.6kb，约为 `solid-intlayer` 的 4.7 倍）。

尽管如此，它与基于 `t('a.b.c')` 构建的栈具有相同的主要缺点：优化是可能的，但非常耗时，且大型项目面临不良实践（命名空间 + 动态加载 + 类型）的风险。

**(@solid-primitives/i18n)** (`@solid-primitives/i18n@2.2.1`):

Solid primitive 非常轻量且高效，我推荐将其用于轻量级项目，但对于包含 cookie 管理、代理重定向、格式化器等在内的专业解决方案，它可能会迅速显现功能不足。
它还缺乏延迟加载和分层命名空间以进行页面大小优化。

**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):

`Paraglide` 提供了一种创新且深思熟虑的方法。尽管如此，在此基准测试中，他们宣传的 tree-shaking 在我的实现中没有按预期工作。工作流程和 DX 也比其他选项更复杂。
我个人不喜欢在每次推送前重新生成 JS 文件，这会通过 PR 在开发者之间造成持续的合并冲突风险。
最后，与其他解决方案相比，Paraglide 不使用 store（例如 Solid signal）来检索当前语言以渲染内容。对于解析的每个节点，它都会从 localStorage / cookie 等请求语言。这导致执行不必要的逻辑，从而影响组件的反应性。

### 3 - 建议

**(Intlayer)** (`solid-intlayer@8.7.12`):

出于客观性考虑，我个人不会对 `solid-intlayer` 做出评价，因为它是我的个人解决方案。

### 个人笔记

此笔记仅代表个人观点，不影响基准测试结果。尽管如此，在 i18n 领域，您经常会看到围绕 `const t = useTranslation('xx')` + `<>{t('xx.xx')}</>` 模式的翻译内容共识。

在 Solid 应用中，将函数作为 `JSX.Element` 注入在我的观点中是一种反模式。它还增加了可避免的复杂性和 JavaScript 执行开销（即使几乎察觉不到）。
