静态博客多语言架构设计：从“翻译问题”到“三层分离模型”
这几天我完成了一件拖了很久的事：把自己的 Hexo 博客改成双语站点。
但真正让我想清楚的，不是配置怎么写，而是一个更本质的问题：多语言站点的核心不是翻译，而是架构分离。
在改造过程中，我逐渐把问题拆成了三个层级。这也是我这次最大的收获。
一、多语言博客的三层模型
在实践之前，我犯的第一个错误，是把“界面多语言”和“内容多语言”混为一谈。实际上，它们是三层不同的机制。
第一层是界面层（UI 文案），包括菜单、按钮、分页、提示语。这是主题层解决的问题，它只负责两件事：语言切换、文案映射。它不负责内容隔离。
第二层是路由层（URL 结构）。URL 决定语言空间是否被真正隔离。我的设计原则是：默认语言（中文）保持原有 URL 结构；英文内容统一走 /en/...；同一篇文章通过 id 关联；使用 lang 字段区分语言版本。这一层决定的是语言是否成为“路径维度”，而不是“分类维度”。分类只是内容标签，语言必须是路由结构。
第三层是内容层（列表与统计），也是最容易被忽略的一层。默认情况下，首页、归档、分类页、标签页往往会混合所有语言文章。所以我做了三件事：一是自定义生成器，按 lang 过滤列表页；二是分类和标签总览页增加 helper 过滤；三是切换语言时增加兜底逻辑，避免 404。核心原则很简单：当前语言环境，只展示对应语言内容。
二、我踩过的典型误区
第一个误区是把语言当成分类。最初我以为给文章加一个 English 分类即可，后来发现这条路天然不成立。分类是内容属性，不是语言维度。语言必须进入路由层，才能形成稳定可维护的多语言结构。
第二个误区是追求一次性全站翻译。我最开始的心理压力来自“是不是必须一次翻完所有历史文章”。后来我改变了策略：先完成架构，再逐篇补充。语言架构先搭好，内容可以渐进式完善。
三、技术改动概览
我这次的改动可以归纳为四组：
- Hexo 层：配置
zh-CN + en，修改 permalink 加入语言段，使用统一id + lang管理版本。 - NexT 主题层：启用
language_switcher，补齐自定义语言映射。 - 内容生成层：自定义 generator 过滤列表页，helper 处理分类与标签统计，
body-end增加语言切换 fallback。 - 细节修复：修复语言下拉宽度异常，修复移动端表格溢出。
四、AI 在这次改造中的角色
AI 在这件事里的价值，不是“自动写完代码”，而是帮我快速定位问题边界、验证假设、提供实现方向、减少试错时间。最终的架构选择和取舍，仍然由我决定，但效率显著提升。
五、我现在的双语策略
我给自己定下三个规则：第一，先确保界面多语言稳定；第二，内容按价值逐步补英文；第三，用统一 id + lang 管理版本。双语站点不是一个按钮，而是一套清晰的内容管理策略。
六、一个更大的认知收获
这次改造让我意识到，多语言问题本质是信息结构问题。当结构清晰后，翻译变得可控，内容扩展变得自然，维护成本也可预期。
接下来，我会逐步把更有代表性的历史文章补成英文版本，让英文区从“可用”慢慢走向“好用”。