一周告别美国科技巨头：替换17项技术依赖的实战复盘

一场为期一周的"去美化"迁移

2025年夏天，创业团队 fluado 在构建产品时曾立下一个目标：尽量不依赖美国科技巨头。但在公司注册、产品开发这些繁杂事务面前，这个目标显得"没那么重要"。团队最终选择了熟悉的 Google Cloud 起步——虽然心里有些不情愿，但至少少操一份心。

一年后，他们发现自己对美国服务商的依赖越陷越深：Cloudflare、GCP、Supabase、GitHub、Slack、Google Workspace 一个都没落下。于是在八月底，这个团队下定决心迁离美国技术栈。让作者本人都意外的是，绝大部分迁移工作竟然在一周内完成了。

这篇分享在 Reddit 上引发了不少讨论，核心话题直指一个越来越被欧洲开发者关注的议题：技术主权与供应商多样化。

迁走了什么，换成了什么

作者把这次迁移的对照关系列得很清楚：

迁出（OUT）：

• Google Cloud / Cloud Run
• GitHub
• Supabase Cloud
• Firebase
• Cloudflare
• Slack

迁入（IN）：

• Hetzner（德国老牌云主机与裸金属服务商）
• Forgejo（GitHub 的开源自托管替代，Gitea 的社区分支）
• 自托管 Supabase
• Scaleway（法国云服务商）
• Mattermost（Slack 的开源自托管替代）

从这份清单能看出一条清晰的思路：能用欧洲本土服务商就用欧洲，能自托管的核心组件就自己扛。 Hetzner 与 Scaleway 分别是德国和法国的成熟云厂商，价格和口碑都不差；Forgejo 与 Mattermost 则代表了成熟开源项目对商业 SaaS 的正面替代。

作者特别强调了一个判断：无论你跑在 GCP、AWS 还是 Azure 上，团队所需的大部分能力，都能找到欧洲本土或可自托管的对应方案。这句话是整篇分享的核心论点，也是它最有说服力的地方——迁移不是理想主义的空谈，而是有具体落地路径的工程决策。

Forgejo 是 Gitea 的社区硬分叉（hard fork），诞生于2022年底社区对 Gitea 公司化运营方向的不满。它完全兼容 Gitea 的数据格式和 API，也兼容 GitHub 的大部分工作流习惯（如 Actions CI/CD 语法），意味着从 GitHub 迁移时，现有的工作流脚本通常只需少量修改甚至无需改动。Forgejo 由欧洲自由软件基金会 Codeberg 主导维护，代码库托管在 Codeberg.org，是目前欧洲开发者社区中最受推荐的 Git 托管自建方案之一。

自托管 Supabase 值得单独说明：Supabase 本身就是开源项目（Apache 2.0 协议），官方提供了完整的 Docker Compose 部署方案。这意味着团队可以在自有服务器上运行与 Supabase Cloud 功能几乎完全一致的实例，包括 PostgreSQL 数据库、Auth 服务、Storage、Edge Functions 等。迁移成本主要来自环境配置和运维承接，而非代码层面的改造。

为什么值得关注这类迁移

这类"去美国科技巨头依赖"的实践，近一两年在欧洲开发者社区明显升温。背后的驱动力并非单一：

数据主权与合规。 欧洲对数据本地化、GDPR 合规的要求日益严格，把关键数据和基础设施放在欧洲司法辖区内的服务商手中，能显著降低合规不确定性。

供应商锁定风险。 深度绑定单一生态（尤其是 Firebase、Supabase Cloud 这类一体化平台）会让迁移成本随时间指数级上升。作者的经历本身就是例证——从"少操一份心"到"依赖越陷越深"，正是锁定效应的典型演化。

开源自托管的成熟度提升。 Forgejo、Mattermost、自托管 Supabase 的存在，意味着核心研发协作工具链已经具备了脱离商业 SaaS 独立运行的能力。这在几年前还很难想象。

值得一提的是，作者坦承整个过程的"惊喜"在于速度——原以为是场持久战，结果一周搞定大头。这从侧面说明，如今开源与欧洲替代方案的生态完整度和迁移友好度已经达到了相当可用的水平。

GDPR 与数据本地化在实操层面对技术选型有直接影响。根据 GDPR 第44-49条，将欧盟居民数据传输至"第三国"（即欧盟以外地区，包括美国）需要满足充分性决定（adequacy decision）、标准合同条款（SCCs）或其他合规机制。2023年通过的《EU-US 数据隐私框架》虽然一定程度上简化了合规路径，但欧洲法院此前已两度推翻类似协议（Safe Harbor、隐私盾），使得依赖美国服务商在法律层面始终存在不确定性窗口。将基础设施和数据保持在欧盟司法辖区内，本质上是规避这一不确定性的工程手段，而非纯粹的政治立场。

仍未解决的难题

作者也没有粉饰这次迁移，明确列出了几块"硬骨头"：

Google Workspace 尚未替换。 邮件、文档、日历这类办公协作套件，找一个体验对等且迁移平滑的欧洲方案，难度不小。

编码智能体（coding agents）。 当下主流的 AI 编程助手几乎清一色来自美国厂商，欧洲本土在这一领域缺乏成熟的直接替代品。这也是整个 AI 工具链"去美化"最现实的短板。

Let's Encrypt 无解。 作者坦言没能找到一个可以"即插即用"替代 Let's Encrypt 的欧洲证书颁发机构。免费、自动化、广泛信任的证书服务，短期内确实没有对等选项。

这几个"待办事项"其实比已完成的部分更有信息量——它们精准勾勒出了当前欧洲技术栈生态的能力边界：基础设施、代码托管、协作工具已基本可替代，但办公套件、AI 工具、根基性公共服务（如证书颁发）仍高度依赖美国主导的生态。

Let's Encrypt 的特殊地位需要一些背景说明。Let's Encrypt 由非营利组织 ISRG（互联网安全研究小组）运营，提供免费、自动化的 TLS 证书，其核心协议 ACME（自动证书管理环境）已成为 RFC 标准。它之所以"几乎无可替代"，原因是三重叠加：免费、被所有主流浏览器和操作系统内置信任，以及与 Certbot、Caddy 等工具深度集成的自动化续期体验。现有的欧洲替代选项（如德国的 HARICA 或 SwissSign）大多面向企业付费市场，缺乏同等级别的自动化生态，且免费层级受限。这并非技术能力的差距，而是公共基础设施定位和商业模式的结构性差异，短期内难以弥合。

给同类团队的启示

对于正在考虑供应商多样化的技术团队，这个案例提供了几点可借鉴的思路：

分层评估依赖。 把技术栈按"可自托管""有本土替代""暂无替代"三档分类，优先处理前两档，对第三档保持关注而非强行迁移。

警惕一体化平台的隐性锁定。 Firebase、Supabase Cloud 这类"开箱即用"的便利，往往以未来的迁移成本为代价。若长期看重灵活性，自托管开源方案（如自托管 Supabase）是更稳妥的选择。

迁移窗口比想象中窄。 作者的一周经历表明，越早决策、趁项目复杂度尚可控时动手，迁移成本越低。等到依赖盘根错节，代价只会更大。

这不是一场非黑即白的"抵制"，而是一次关于技术自主权、成本结构与风险分散的理性权衡。无论最终是否要"告别美国科技巨头"，理解自己技术栈的依赖结构和可替代性，本身就是每个团队都该做的功课。