当网站只有中文的时候，很多事情都很简单。导航、博客、项目页，想到什么写什么就行。直到我决定给个人网站增加英文版本。原本以为国际化只是多维护一份翻译文件，结果真正开始动手之后才发现，它影响的不只是文案，而是整个项目的路由结构、SEO策略以及后续的维护成本。使用普通路由，通过组件逻辑切换语言。使用 state 管理 locale，实现所谓的“国际化”。开始重构路由结构，引入 next-intl。 locale 成为 URL 的一部分，SEO 和维护问题同时得到解决。如果网站未来有国际化计划，建议一开始就把 URL 结构设计好。后面重构的成本，远比想象中高。 ## 🧭 一开始，我把国际化想简单了最开始我的需求其实非常简单： - 支持中文和英文 - 博客能够拥有独立语言版本 - 页面结构保持统一 - 对 SEO 尽量友好当时我觉得这应该不是什么大问题。无非就是准备两份翻译文件，然后根据用户选择的语言进行切换。直到真正开始开发之后，我才发现自己忽略了很多事情。 ## 💥 第一个坑：路由结构从一开始就是错的刚开始我的博客结构是这样的： ```txt /blog/[slug] ``` 然后通过 locale 去动态切换页面内容。看起来似乎没什么问题，但随着页面越来越多，问题开始不断出现： - URL 无法区分语言 - 搜索引擎无法识别不同语言页面 - 所有语言逻辑堆积在组件内部 - 后期维护越来越复杂当时最大的错觉就是：页面能正常显示，所以方案应该没问题。后来我才发现：看起来能用，不代表结构是对的。很多问题在项目初期根本不会暴露出来，但随着页面数量增加，维护成本会迅速上升。 ## 💥 第二个坑：我做的其实是假国际化后来为了快速实现语言切换，我尝试过一种更简单的方案。大概逻辑是： - state 保存当前语言 - 点击按钮切换 locale - 页面重新渲染对应文案实现确实很快。但问题也很明显： - URL 没有变化 - 分享链接无法保留语言状态 - 页面刷新后状态容易丢失 - SEO 几乎没有帮助那个时候我才意识到：国际化不是切换文字，而是切换路由结构。 ## 🧩 最终方案：next-intl + App Router 折腾了一段时间之后，我最终选择了 next-intl。最主要的原因是：它和 Next.js App Router 的结合非常自然。目前我的项目结构大概是这样：语言直接成为路由的一部分： ```txt /zh/blog/nextjs-intl-i18n /en/blog/nextjs-intl-i18n ``` 这样做之后，很多问题突然就变简单了。 ## ⚙️ 为什么最终选择 next-intl ### 1️⃣ 路由天然支持 locale 不再需要自己维护语言状态。当前 URL 就代表当前语言。逻辑简单了很多。 ### 2️⃣ 更适合 App Router 相比传统 i18n 方案，next-intl 对 App Router 的支持明显更友好。很多配置都是围绕新架构设计的。 ### 3️⃣ 组件使用体验更舒服以前我需要频繁导入翻译文件。现在只需要： ```txt const t = useTranslations("home"); return (

{t("title")}

); ``` 就可以直接获取对应语言内容。组件内部会干净很多。 ### 4️⃣ SEO 结构更清晰独立 URL 意味着： - 搜索引擎更容易索引 - 不同语言内容不会混在一起 - 分享链接更准确 - 后续支持 hreflang 更方便 ## 🔨 我是怎么一步步重构过来的其实整个过程并不是一次完成的。中间试过很多方案，也推翻过很多方案。网站只有中文版本，所有页面都使用普通路由结构，例如 /blog/[slug]。为了快速实现语言切换，我选择用 state 管理 locale，根据当前语言动态切换页面文案。随着页面增多，我发现 URL 无法区分语言版本，分享链接、SEO 和维护成本都开始出现问题。对比了 Next.js 官方 i18n、next-intl 等多个方案后，开始尝试基于 App Router 重构国际化架构。将 locale 提升到路由层级，引入 app/[locale] 结构，并重新适配博客、项目页和导航组件。最终采用 App Router + next-intl 方案，locale 成为 URL 的一部分，同时解决了 SEO、分享链接和维护成本的问题。 ## 🌍 国际化为什么会影响 SEO 很多开发者第一次做国际化的时候，关注点通常都在翻译。但对于搜索引擎来说，它更关注的是： - 不同语言是否拥有独立 URL - 页面语言是否明确 - 是否存在重复内容 - 是否正确配置 hreflang 如果只是切换页面文字，而 URL 完全不变，那么搜索引擎很可能仍然把它们视为同一个页面。这也是我最终放弃状态切换方案的重要原因。 ## 🧠 回头看这次重构做完之后再回头看，我最大的感受其实是：国际化本质上不是一个翻译问题，而是一个架构问题。翻译文件只是最后一步。真正决定项目是否好维护的，是前期的路由设计和内容组织方式。如果这些没有规划好，后面只会越来越乱。 ## ✨ 写在最后现在这套方案当然算不上完美。但至少它满足了我当前的需求： - 路由清晰 - SEO 友好 - 维护成本可控 - 后续扩展方便对于个人网站来说，我觉得已经足够了。未来如果继续升级的话，我大概率会继续优化： - 博客多语言同步策略 - 自动生成 Metadata - hreflang 支持 - MDX 内容管理方案如果让我重新做一次，我会在项目创建的第一天就把国际化路由规划好，而不是等网站快写完了再回头重构。后者花费的时间，远远超过配置 next-intl 本身。

SIWOER