重复数据的迁移实践：从 N 个文件到 1 个真相源

当你在第一个文件中修改一个 Reddit post ID 时，系统照常运行。当你在第五个文件中忘记修改时，bug 出现了。当你在第十个文件中不确定是否该修改时，你意识到系统失控了。

这不是记忆力的问题，而是配置组织方式的问题。

分散配置的隐性成本

假设你有一个 AI 模型展示网站（如 Studio 系统）。每个模型页面都需要显示 Reddit 社区讨论。最直观的做法是在每个模型的配置文件中写入 8 个 Reddit posts：

content/models/i18n/en/sora2.json          ← 8 个 posts
content/models/i18n/en/claude-ai.json      ← 又是相同的 8 个 posts
content/models/i18n/en/flux-ai.json        ← 再次重复
content/models/i18n/zh-cn/sora2.json       ← 同样的 8 个 posts
...

第一次复制时，你觉得这很正常。每个模型有自己的配置，互不干扰。

但当你发现某个 Reddit post 需要替换时，问题暴露了。你需要打开每个文件，找到那个 post，逐一修改。如果有 10 个模型 × 5 种语言 = 50 个文件，你需要修改 50 次。

更糟的是，你不一定记得所有用到这个 post 的地方。你可能改了 45 个，漏了 5 个。系统在不同页面展示不一致的数据，但你不知道。

这种隐性成本不体现在代码行数上，而是体现在认知负担上。每次修改前，你都要思考"这个改动会影响哪些文件"。每次添加新页面，你都要复制一遍配置。维护成本随文件数量线性增长，而一致性风险呈指数上升。

集中式配置的实践逻辑

集中式配置的核心是建立一个权威的数据源。所有页面从这个源读取，而不是各自持有副本。

创建 lib/reddit-collections.ts：

export const REDDIT_COLLECTIONS = {
  'sora2': {
    name: 'Sora 2 Discussions',
    posts: {
      'en': [
        { postId: '1o8cylw', subreddit: 'StableDiffusion', featured: true },
        { postId: '1o8bc90', subreddit: 'OpenAI', featured: true },
        // ... 其他 6 个 posts
      ],
      'zh-cn': [
        { postId: '1o8cylw', locale_note: '对比评测...' },
        { postId: '1o8bc90', locale_note: '社区反馈...' },
        // 同样的 post IDs，不同的语言注释
      ]
    }
  }
};

各个页面的配置文件简化为一行引用：

{
  "redditCard": {
    "collectionName": "sora2"
  }
}

数据流向变得清晰：

这个设计的关键不在于"文件更少"，而在于"修改只发生在一处"。当你需要更新某个 post 时，你只需要改 reddit-collections.ts。所有引用它的页面自动同步。

系统保证了一致性，而你不需要做任何额外工作。

迁移的决策时机

从分散配置迁移到集中式配置有成本。你需要重构现有代码，更新所有文件，测试所有页面。什么时候这个成本是值得的？

现在立即迁移，如果：

• 你的项目还很小（1-3 个文件），迁移成本低
• 你预见到未来会有更多文件需要相同配置
• 你已经遇到过一次配置不一致的 bug

推迟迁移，如果：

• 每个页面的数据确实完全不同，没有重复
• 你不确定数据结构是否稳定，可能频繁变化

但要注意，推迟迁移意味着技术债务累积。当你有 50 个重复配置时再迁移，成本会是现在的 10 倍。

迁移的具体步骤

假设你决定现在迁移。实际操作需要四个步骤。

第一步：提取现有配置

打开现有的 JSON 文件，复制所有 Reddit posts 配置。按主题分组，按语言隔离。确保 post IDs 在不同语言间保持一致。

第二步：创建集中配置文件

将提取的配置写入 lib/reddit-collections.ts。给每个主题一个有意义的名称。

第三步：更新数据获取逻辑

修改 lib/reddit-content.ts（或你项目中负责获取 Reddit 数据的模块），添加从集中配置读取的逻辑：

import { REDDIT_COLLECTIONS } from './reddit-collections';

export function getRedditCollection(
  collectionName: string,
  locale: string
): RedditDiscussionConfig[] {
  const collection = REDDIT_COLLECTIONS[collectionName];
  if (!collection) {
    throw new Error(`Collection "${collectionName}" not found`);
  }
  return collection.posts[locale] || collection.posts['en'];
}

第四步：简化页面配置

逐个打开 JSON 文件，删除完整的 discussions 数组，替换为 "collectionName": "主题名"。

测试每个页面，确认数据显示正常。

数据量的对比

迁移前后的文件大小变化直观展现了配置冗余：

迁移前（en/sora2.json）：

{
  "seo_metadata": { ... },
  "model_info": { ... },
  "redditCard": {
    "discussions": [
      { "postId": "1o8cylw", "subreddit": "StableDiffusion", ... },
      { "postId": "1o8bc90", "subreddit": "OpenAI", ... },
      // ... 6 more posts
    ]
  }
}

文件大小：~900 行

迁移后（en/sora2.json）：

{
  "seo_metadata": { ... },
  "model_info": { ... },
  "redditCard": {
    "collectionName": "sora2"
  }
}

文件大小：~650 行

每个文件减少 250 行，减少 28% 的冗余。当有 50 个文件时，总共减少 12,500 行重复配置。

但更重要的不是行数，而是维护表面积的缩小。修改一个 post 从改动 50 个文件变成改动 1 个文件。

配置方式反映系统观

分散配置和集中配置不只是代码组织的差异，而是对系统复杂度的不同态度。

分散配置假设"每个页面是独立的"。这在数据确实独立时成立。但当数据在逻辑上是同一个实体时，分散存储制造了虚假的独立性。你需要手动保持多份副本的一致性，这是人力对抗熵增。

集中配置承认"这些页面共享同一份数据"。它把一致性维护交给系统结构，而不是人的记忆。修改时，你只需要考虑"这个数据应该是什么"，而不是"这个数据在哪些地方"。

技术选择背后是认知模型的选择。当你选择集中式配置，你不只是在写更少的代码，你是在简化系统的心智模型。这种从意图到架构的思考过程，决定了系统最终的可维护性（参见 from-intent-to-architecture）。

配置的组织方式是系统设计的缩影。每个选择都在回答"谁负责保证一致性"这个问题。分散配置把责任交给开发者，集中配置把责任交给系统结构。

当系统规模增长时，人的记忆力不会线性增长。把复杂度交给结构，而不是交给人。