一句话摘要

2011 年 Parse 开创了 BaaS（后端即服务）：开发者只写前端，数据库、推送、用户认证全交给 Parse 托管——它几乎重新定义了移动开发的效率，2014 年服务超过 50 万款应用，是当时最成功的开发者服务之一。2013 年 Facebook 用 8500 万美元收购 Parse，2016 年却宣布关闭（2017 年 1 月停服），几十万应用的”后端”一夜之间要搬家。Parse 死于”被母公司当战略棋子”——买来补 Facebook 的移动短板，战略转向后随手扔掉。

发生了什么

• 2011 年：Parse 成立——“让移动开发不再需要写后端”的理念迅速走红
• 2013 年 4 月：Facebook 以 8500 万美元收购 Parse——当时 Facebook 正被”不会做移动端”的舆论困扰，Parse 被视为补短板的关键
• 2014 年：巅峰期——服务超过 50 万款应用（包括很多知名 App）；开发者社区庞大
• 2015-2016 年：Facebook 战略转向（移动生态已由自家 SDK 主导），Parse 在 FB 内部地位边缘化
• 2016 年 1 月：Facebook 宣布关闭 Parse 服务，给开发者一年迁移期
• 2017 年 1 月：Parse 服务正式停止；源码开源（Parse Server），由社区维护

关键数据

指标	数值
生命周期	2011-2017（6 年）
收购价	8500 万美元（2013）
巅峰服务应用数	超 50 万款
停服	2017 年 1 月
死亡方式	母公司战略放弃

为什么会死

1. 被母公司”战略性收购”的命运：用完就扔

Facebook 买 Parse 是为了”解决移动短板”，当 FB 自家的开发者工具成熟后，Parse 就成了可有可无的资产。收购时承诺”独立运营”，三年后一纸公告关停。巨头收购的目的不是”帮你做大”，是”补我自己的短板”。

2. 商业模式存疑：BaaS 的盈利难题

Parse 免费层太好用，付费层的用户比例太低——多数开发者用免费额度就够。BaaS 要赚钱要么靠量大（Firebase 模式靠 Google 生态），要么靠细分场景——Parse 两头都不占，自己也不赚钱，母公司更没有养它的理由。

3. 平台依赖的代价：开发者的至暗时刻

Parse 关闭时，数十万应用一夜之间”后端没了”——迁移到自建服务器或替代品要数月时间。“用 BaaS 省下的开发时间，在平台关闭时加倍还回去”——这就是平台依赖的风险溢价。

4. 先驱的遗产：开源续命

Parse 源码开源为 Parse Server，至今仍有大量团队自托管运行。它用生命证明了 BaaS 的需求真实存在（后来 Firebase/Supabase 都验证了），但”谁来长期经营”是 BaaS 的世纪难题。

可复用的教训

• 依赖第三方平台的核心服务，必须有”逃生通道”。 数据可导出、API 可替换——平台翻脸时你才不至于一夜瘫痪。
• 巨头的收购承诺不可尽信。 “独立运营”大概率只是过渡话术，战略一变就是弃子。
• BaaS/托管服务要思考”长期谁来养”。 免费策略吸引用户，但必须想清楚付费转换或生态绑定，否则就是给巨头做嫁衣。