供应商锁定逃生预案：一人团队的依赖分级与迁移手册

每个 vibe coder 的架构图里都藏着一张看不见的账单。你的应用跑在别人的认证服务上、数据躺在别人的数据库里、账单走别人的支付网关、邮件经别人的 SMTP 发出——你以为自己在"独立开发"，实际上只是在七八家 SaaS 公司的夹缝里租了一条命。它们涨价，你就得跟着涨价；它们改条款，你的产品就得跟着改；它们关门，你的项目当场陪葬。

这不是危言耸听。下面这篇文章要讲的就是：如何在一人团队的资源条件下，给每个外部依赖做"分级"，给每个核心依赖写"逃生预案"。先把结论放在前面——锁定本身不是问题，没有预案的锁定才是。成熟团队靠合同和法务对冲风险，一人团队靠的是另一套东西：可导出的的数据、标准的协议、和每年演习一次的逃生路线。

一、为什么锁定对一人团队是致命的：杠杆的两面

先说一个反直觉的判断：vibe coder 比大公司更依赖 SaaS，也更经不起 SaaS 的背叛。大公司有专职的平台团队、有备选供应商的商务谈判筹码、有法务逐字审查 SLA。一个人没有这些。你用 Auth0 做登录不是因为它最好，而是因为你没时间自己写 OAuth；你用 Stripe 不是因为费率最优，而是因为三天就能收款。这种"用钱买时间"的交易本身没错，错的是很多人签完字就把这件事忘了——直到账单翻倍的那天。

SaaS 供应商伤害你的方式有四种，按常见程度排序：

1. 涨价：最常见，也最温和。Auth0 在 2023 年被 Okta 收购后调整定价结构，B2C 档的超量单价直接翻了几倍，不少独立开发者的月账单从两三百美元跳到数千美元。你的收入没变，成本先变了。
2. 免费层收缩：Heroku 在 2022 年 8 月宣布取消免费层，11 月 28 日正式下线免费 Dyno、免费 Postgres 和免费 Redis。十几年来靠免费层跑着的 side project，一夜之间要么掏钱要么搬家。没人维护的项目直接黑屏。
3. 条款与功能变更：API 限流收紧、关键功能被挪到企业版、数据保留期缩短。这种死法最阴险——服务还在，但你的用法突然"违规"了。
4. 关停：最极端，也最干脆。Facebook 在 2016 年 1 月 28 日宣布关闭 Parse 托管服务，给了整整一年的迁移窗口，并开源了 Parse Server。算业界良心了。即便如此，仍有大量无人维护的老应用在 2017 年 1 月 30 日之后彻底停止工作。

注意这四种伤害的共同点：它们都不需要你犯错。你的代码可以写得完美无缺，产品可以持续增长——伤害来自你控制范围之外。这就是为什么"逃生预案"不是悲观主义，而是独立开发者的基本职业素养。把依赖当成会变质的食材，而不是地基。

二、依赖分级评估矩阵：先分级，再谈预案

一人团队的时间是最稀缺的资源，不可能给每个依赖都写预案。所以第一步是分级：只给"核心"依赖写逃生预案，"重要"依赖做定期复查，"可替"依赖随缘。分级的依据是三个维度——

• 替换成本：换掉它要花多少钱（含新供应商费用、双跑期间的重叠账单、用户迁移的隐性成本）。
• 迁移工时：换掉它要花你多少小时。对一人团队来说，工时比钱更贵。
• 数据可导出性：你的数据能不能完整、机器可读地拿出来。这是锁定程度的试金石——导不出来的依赖，锁的就是你的命。

三个维度各打 1–3 分（1=低，3=高），加总即为"锁定指数"。对照下表定级：

锁定指数	级别	定义	处置动作
7–9 分	核心依赖	替换成本高、迁移工时长、数据难导出。典型：主数据库、认证体系、支付网关。	必须写一页逃生预案；每季度复查一次；保持导出脚本可用。
4–6 分	重要依赖	替换有代价但可承受。典型：对象存储、邮件服务、错误监控、CDN。	记录备选供应商名单；每年验证一次导出能力；不写完整预案。
3 分	可替依赖	标准协议、无状态、随时可换。典型：DNS、纯静态托管、一次性工具库。	不做预案。选型时偏好标准协议即可。

举个例子帮你校准手感。假设你的应用用 Supabase（Postgres + Auth + Storage 一体）：数据库替换成本 3 分（数据量大了之后迁移是体力活）、迁移工时 3 分（RLS 策略、Edge Function 都要重写）、数据可导出性 1 分（Postgres 就是 Postgres，pg_dump 全量可导）。总分 7，核心依赖——但注意，它的可导出性是满分项，这就是它值得用的原因。再看一个反例：某无代码后端，数据只能通过它自己的 API 分页爬出来，没有批量导出——替换成本 3、迁移工时 3、可导出性 3，总分 9。这种依赖，哪怕免费也别碰，因为它锁的不是你的代码，是你的数据。

这里有个关键判断要强调：分级看的不是"这个服务有多好"，而是"它背叛你时你有多疼"。好用和安全是两回事。vibe coder 选型时最容易犯的错误，就是把"接入快"误当成"风险低"。接入越快，耦合往往越深，疼起来越狠。

三、核心依赖的逃生预案：一页纸模板

每个核心依赖一页纸，存在你的项目文档里（Notion、README、都行，关键是找得到）。模板如下，照着填：

字段	填什么	示例（以邮件服务为例）
依赖名称 / 用途	一句话说清它在架构里的位置	Resend：注册验证、密码重置、订单通知邮件
锁定指数与定级理由	三个维度的打分和一句话理由	5 分（重要→核心边界）：发信域名信誉沉淀在它名下，换服务商要重做域名预热
数据 / 资产清单	它手里攥着你的什么东西	邮件模板、退订列表、发送统计、域名 DKIM/SPF 配置
导出方式	具体怎么拿出来，命令或截图路径	模板存在仓库的 /emails 目录（已版本化）；退订列表每月 1 号手动导出 CSV 存档
备选方案（2 个）	现在就能说出名字的替代品，含预估迁移工时	A. AWS SES（约 4 小时：换 SMTP 配置+重做域名验证）；B. Postmark（约 3 小时）
触发条件	什么情况下启动迁移，别等火烧眉毛	涨价超 50%、免费额度砍半、连续两次故障超 4 小时、被收购
迁移步骤（≤10 步）	写给三个月后的自己看的操作清单	1. 在备选服务商开户并验证域名 → 2. 导入退订列表 → 3. 灰度 10% 流量 → … → 10. 下线旧服务
上次演习日期	空着就是没做，诚实填写	2026-04-12（仅验证了导出脚本，未做真实切换）

注意模板里最毒的一行是"触发条件"。大多数人迁移失败不是因为技术难，而是因为犹豫——"再等等看""也许只是暂时的""迁移好麻烦"。预先写好触发条件，就是把决策权从情绪手里夺回来，交给纸上的规则。涨价 50% 就走，不讨论、不开会、不纠结。一人团队没有"开会"，只有你和你的拖延症，规则是唯一能战胜它的东西。

另一个容易被忽略的字段是"数据/资产清单"里的隐性资产：发信域名的信誉、OAuth 应用在各平台的审核状态、支付网关的风控白名单、CDN 的缓存预热。这些东西不在数据库里，导不出来，只能重建。预案里必须把它们列出来，否则你会低估迁移工时至少一半。

四、选型时的反锁定十问

最好的逃生预案，是在选型那天就让自己"不容易被锁"。下面十个问题，引入任何新依赖之前过一遍。答不上来的，默认按最坏的情况打分：

1. 我的数据能完整导出来吗？有没有官方的批量导出（不是分页 API 爬虫）？导出的格式是不是开放格式（CSV、SQL、JSON）？
2. 有没有基于开放标准的替代品？它用的是 Postgres / S3 兼容 / SMTP / OAuth 这种标准协议，还是自创的私有 API？标准协议意味着整个生态都是你的备选。
3. 免费层和付费层的边界在哪里？边界是"用量"还是"功能"？历史上这个边界是变宽还是变窄？（Heroku 的教训：免费层是恩赐，不是权利。）
4. 定价的"第二档"是多少钱？别只看免费和第一档。算一下用户翻 10 倍时的账单，看看曲线是线性还是阶梯——阶梯式定价是独立开发者的坟场。
5. 这家公司靠什么赚钱？如果它主要靠融资活着、主营业务和你用的产品线无关（比如大厂的"战略性免费产品"），那它随时可能被砍。Parse 就是死于"战略调整"。
6. 被收购了怎么办？查一下它的融资历史和收购传闻。被巨头收购后涨价改条款是标准剧本（参考 Auth0 被 Okta 收购后的定价调整）。
7. 它的状态页历史好看吗？打开 status page，看看过去一年的故障次数和时长。顺手确认它有没有公开的 SLA 和赔偿条款。
8. 社区里有人成功迁移出去吗？搜"migrate from X to Y"。如果搜不到任何迁移案例，说明要么没人用，要么出去的人都死了——两种都很可怕。
9. 我的代码和它耦合了几处？是不是封装了一层适配器？如果它的 SDK 调用散落在 40 个文件里，迁移工时直接乘以三。vibe coding 生成的代码尤其容易出现这种"满天星"式耦合，生成完记得收敛。
10. 最坏情况下，我有多少时间？它的服务条款里，关停或重大变更的通知期是多久？30 天对一人团队可能不够，90 天才算体面。写进你的触发条件里。

这十问里，第 9 问是 vibe coder 的专属陷阱。AI 生成代码的速度越快，你在各处随手 import 第三方 SDK 的速度也越快。一周后你自己都记不清哪里调了它的 API。我的建议是硬性的：任何核心依赖，必须包一层你自己的模块（比如 lib/email.ts、lib/auth.ts），所有业务代码只调你这一层。迁移时你只需要重写这一个文件，而不是全文搜索替换。这条规则的成本是 10 分钟，收益是迁移工时减半。

五、真实翻车案例剖析

案例 1：Parse 关停（2016–2017）——"模范分手"依然有人受伤

2013 年 Facebook 以 8500 万美元收购了移动后端平台 Parse，到 2014 年号称支撑了 50 万个应用。2016 年 1 月 28 日，Facebook 宣布关闭 Parse 托管服务，服务在 2017 年 1 月 28 日（实际延续到 1 月 30 日）正式下线。作为补偿，Facebook 开源了 Parse Server（Node.js 实现），并提供了数据库迁移工具，开发者可以把数据迁到任意 MongoDB，再用自托管的 Parse Server 接着跑，客户端代码几乎不用改。

这是教科书级别的"体面分手"：整整一年窗口期 + 开源替代品 + 官方迁移工具。但即便如此，结局依然惨烈——大量无人维护的老应用根本没人去迁，下线那天直接停止工作。教训有三层：第一，迁移窗口的长度只对"还活着"的项目有意义，没人维护的项目给十年也没用；第二，Parse 敢这么体面，是因为它的数据层就是 MongoDB（标准技术），迁得出才谈得上体面——如果你的数据被锁在私有格式里，供应商想体面都体面不了；第三，不要把"大厂背书"当成安全垫，Facebook 亲儿子说关就关，你的供应商没有任何"大到不会倒"的豁免。

案例 2：Heroku 砍掉免费层（2022）——温水煮青蛙的反面教材

2022 年 8 月 25 日，Salesforce 旗下的 Heroku 宣布取消所有免费计划：免费 Dyno、免费 Postgres、免费 Redis，11 月 28 日正式下线，10 月 26 日起先删除一年未登录的闲置账户。官方理由是"打击欺诈和滥用耗费了团队 extraordinary 的精力"。免费了十多年的国民级 PaaS，一夜之间最低消费变成每月 7 美元（Dyno）起。

这次事件的杀伤力在于它没有"迁移"，只有"断供"。Parse 至少给了替代品，Heroku 给的是账单。无数跑在免费层上的 side project、教学 demo、开源项目的在线演示站，要么掏钱，要么在三个月内搬去 Render、Railway、Fly.io。搬得走的是幸运儿——它们的共同点是"应用本身是标准的"（Dockerfile / Procfile / Postgres），换平台只是换跑道。搬不走的，是那些深度用了 Heroku 插件生态、把配置写死在平台里的项目。

对一人团队的启示非常直接：永远不要把生产流量放在"免费层"上，哪怕它现在是免费的。免费层是获客手段，不是慈善事业。你的逃生预案里应该有一条铁律：任何承载真实用户的依赖，必须跑在付费档——付费客户才有 SLA，才有通知期，才有谈判资格。Heroku 事件里最惨的不是多花了 7 美元的人，而是那些连"自己在用免费 Postgres 跑生产"都没意识到的人。

案例 3：Auth0 调价（2023）——涨价比关停更常见

2023 年 11 月 1 日，Okta 旗下 Auth0 上线新的定价体系：B2C Essentials 起价 35 美元/月对应 500 MAU，超量部分按每 MAU 0.07 美元计费——相比之前的 0.023 美元涨了约三倍。有开发者公开自己的账单从每月 240 美元涨到 3729 美元，用户量只增长了 1.67 倍。认证是最难迁移的核心依赖之一：换 IdP 意味着所有用户的会话、密码哈希（导不出明文，只能走"渐进式迁移"让用户下次登录时无缝切换）、社交登录的 OAuth 应用配置都要动。

这个案例说明了为什么认证必须定为"核心依赖"并提前写预案。Auth0 的锁定指数里最狠的一项不是价格，而是密码哈希导不出来——这是安全设计的必然结果（好的 IdP 就不该让你导出密码），但也意味着迁移注定是"双跑 + 渐进式"的脏活。如果你一开始就用标准协议（OIDC）封装了认证层，迁移只是换个 issuer 地址；如果你把 Auth0 的 Rules/Actions 写满了业务逻辑，那迁移就是重写半个登录系统。2026 年 11 月 Auth0 的 Rules 也将彻底停止运行——看，连"不换供应商"的人，都被迫迁移了一次代码。

六、SOP：把预案变成肌肉记忆

预案写完不演习，等于没写。一人团队的演习不需要搞混沌工程那套，三个动作，每年做一次：

1. 导出演习：对每个核心依赖，实际跑一遍导出流程，确认导出的文件能打开、行数对得上、恢复脚本能跑通。Parse 时代活下来的人，都是平时能 pg_dump 出来的人。
2. 备选开户：给每个核心依赖的备选方案开个免费账户，跑通最小链路（发一封测试邮件、存一条测试数据）。真到迁移那天，你最不想做的事情就是"注册账号等审核"。Stripe 的备选开户甚至涉及企业资质审核，提前量要以"月"计。
3. 依赖清单复查：打开你的 package.json、环境变量、DNS 记录，把"正在用但忘了"的依赖找出来，重新打分定级。vibe coding 的项目依赖膨胀速度极快，一年不清理，清单和现实早就对不上了。

再加一条日常纪律：任何新依赖进项目，先填它的"一页纸"再写代码。顺序不能反。写代码是 10 分钟的事，填一页纸也是 10 分钟的事，但后者决定了前者未来会不会变成 100 小时的迁移地狱。把这条写进你的开发 checklist，跟"写测试"放在同一行。

结语：锁定的反面不是自建一切，而是"有选择"

读到这里，你可能会得出一个错误的结论：为了不被锁，什么都自己造。这恰恰是另一种灾难——一人团队自己造轮子的死亡率，比被 SaaS 涨价害死的概率高得多。真正的目标不是"零依赖"，而是"每个依赖都有 Plan B"。

换个角度想：逃生预案最大的价值，甚至不是逃生那天。它逼你在选型的第一天就想清楚三件事——我的数据在哪、换人接手要多久、什么情况下我会走。想清楚这三件事的人，选出来的架构天然就是松耦合的。而松耦合的架构，不光防供应商，也防你自己的代码腐烂。

所以，别再把"用了多少 SaaS"当成技术债的反义词。去数一数你的架构里有几个核心依赖，今晚就给第一个写一页逃生预案。Parse 的用户有一年时间准备，Heroku 的用户有三个月，Auth0 涨价的用户只有一封邮件——下一次，你未必有这么体面。