把双语 MDX 内容流真正跑起来

大多数站点在说“支持双语”的时候，真正支持的只是按钮和少量界面文案。只要开始写文章或项目详情页，问题就立刻暴露出来。

双语最容易出问题的地方

最常见的三种失控方式是：

1. 中文和英文内容放在同一个文件里，后续维护时相互干扰。
2. 页面组件里塞太多语言判断，导致模板越来越重。
3. URL 没有明确 locale 语义，导致分享和收录都不清楚。

这些问题在一两篇内容时不明显，但一旦内容数量起来，改错和补内容都会非常痛苦。

现在这套方式为什么更稳

当前项目把双语作为内容层的第一原则来处理，而不是后补：

• 路由直接使用 /zh/... 与 /en/...
• 每个 locale 下单独维护对应内容目录
• 列表页和详情页模板只关心 locale 和 slug

这样处理以后，页面层并不知道文章正文来自中文还是英文，它只负责渲染 metadata 和正文组件。这一点会极大降低后续维护成本。

对写作和运营层面的实际影响

这种结构最实际的好处，是“新增内容”这件事变简单了。

以后加一篇文章时，不再是“我要怎么改页面”，而是：

• 先确定 slug
• 新建对应目录
• 写 index.mdx
• 填 metadata

这意味着双语站点的维护成本不再主要来自工程结构，而更多来自你是否愿意持续写内容。这个区分很重要。

后续还需要做什么

现在结构已经跑通，后面更值得投入的事情其实是编辑层面的：

• 如何保证中英两边的发布时间和版本关系清楚
• 是否需要在列表页显示“译文 / 原文”关系
• 哪些内容值得双语，哪些只保留单语

这些问题比“技术能不能做”更接近真实运行时会遇到的约束。