从美国迁移到欧洲：一个开发者的完整数字服务迁移清单和实操经验

为什么要迁移

荷兰设计师Monokai（Wimer Hazenberg，Sublime Text配色方案的作者）在2026年4月发表了一篇详细文章，记录了他将整个数字服务栈从美国迁移到欧洲的完整过程。

迁移的原因并不是阴谋论式的恐惧，而是务实的风险评估：

• 不想让自己的数据存储在可能因政策变化而失去访问权的司法管辖区
• 不想依赖一家美国公司的单一收购或管理层决策来决定自己的业务连续性
• 欧洲的云服务替代品已经成熟到足以支撑日常业务

“数字主权听起来像流行语，但当你仔细想想它的含义时，它意味着知道你的数据存储在哪里。”——Monokai

完整迁移清单

迁移过程中的实际经验

S3迁移耗时最长——将AWS S3存储桶迁移到Scaleway的S3兼容存储，使用rclone持续同步，花了超过一周时间。

总耗时约2个月——包括规划和执行。这不是一个周末能完成的事情。

Proton Mail的限制——即使是Duo套餐，自定义域名也只能配置3个。对于拥有多个域名的站长来说，这可能不够用。

选择巴黎机房——基于Scaleway提供的CO₂排放数据展示功能，巴黎是环境影响最小的选择。

关键发现

• 欧洲云服务比预期更成熟——尤其是Scaleway，API兼容性好，文档完善
• 务实的例外是可以接受的——Cloudflare用于公开数据、GitHub用于开源项目、Claude用于编程辅助，因为这些服务的替代品质量差距较大
• 本地AI模型正在崛起——Qwen等开源模型在本地运行的效果越来越好，”前沿API模型和本地可运行模型之间的差距比大多数人想象的缩小得更快”
• 两个月后一切正常运行，没有遗憾

对国内站长的参考价值

虽然这篇文章针对的是欧洲开发者，但对国内站长也有参考意义：

• 数据备份不要只依赖一家云——至少保留一份离站备份在不同供应商
• 邮件服务要有备用方案——Google Workspace如果突然限制账号，业务邮件全断
• 自托管能力是终极保障——Matomo替代Google Analytics、Bugsink替代Sentry，自托管意味着不依赖任何第三方
• 对象存储迁移的复杂度被低估——如果有大量数据要迁移，提前规划传输时间

简评

这篇文章的价值不仅在于具体的迁移方案，更在于它展示了一种思维方式：作为站长，你是否清楚自己依赖了哪些服务？如果其中任何一个突然不可用，你有B计划吗？数字主权的核心不是恐惧，而是掌控。

来源：Monokai博客 | Hacker News讨论