独立开发者的资产韧性：一个人的账号、数据与恢复能力（10 篇）

这是 content/posts/indie/indie-asset-resilience 的目录页，收录 10 篇文章。上一组《平台寄生》讲的是平台会怎么对你；这一组讲的是你自己会怎么失守：域名过期、邮箱丢失、2FA 手机损坏、仓库账号被封、备份和数据库在同一个账号下、收款通道被风控、商店账号找不回来、人突然无法工作。

这个系列解决什么问题

独立开发者习惯了「一个人就是整个公司」。这句话在顺利时是效率，在出事时是单点故障。

一个三人团队里，域名在运维手里、发票在财务手里、App Store 账号在创始人手里、备份在云账号里，任何一个人出事都还有别人。一个人做产品，这些角色全部压在同一个人、同一个邮箱、同一部手机上。不是因为你疏忽，而是因为早期这样最省事。

省事本身没有错。错的是把「暂时能跑」当成「已经可靠」。这个系列要做的，是把隐性的单点故障变成一张能看见、能排序、能演练的清单。

核心主张：可恢复比不可攻破更现实

安全行业有一句话：假设你一定会被攻破，问题只是什么时候、以什么方式。 对独立开发者来说，更准确的说法是：

假设你一定会丢东西，问题只是丢了之后能不能在可接受的时间内恢复。

所以这个系列不追求「绝对安全」，而是追求三个可验证的能力：

1. 看得见：知道自己依赖哪些账号、哪些供应商、哪些唯一副本。
2. 找得回：每个关键账号都有第二条恢复路径，且这条路径不依赖已经失效的东西。
3. 接得上：即使本人暂时无法工作，产品还能继续运行、客户还能被通知、数据还能被取回。

六层资产模型

六层不是并列的。身份层是根：主邮箱一旦丢失，域名、云账号、支付账号的找回流程会同时失效。所以第 03 篇会先处理身份，再处理其他。

10 篇速览

三条阅读路径

路径一：现在就想做一次体检

从 01 开始，用半小时列出「只有一份」的资产；再按 02、03、05 的顺序处理域名、身份和备份。这三件事的投入最小、止损效果最大。

路径二：产品已经有付费用户

先读 05 和 07，确认数据能恢复、收入链路有备路；再读 09，把事故处置流程写成一页纸；最后用 10 检查「如果你住院两周，谁能让产品继续运行」。

路径三：准备上架或换平台

先读 08，弄清个人账号与组织账号的所有权差异；再读 04，确认代码和签名证书不绑在唯一账号上；最后回到 02 和 06，检查域名与云账号的续费和所有者。

与既有专题的划界

本系列只处理一件事：一个人拥有的这些资产，在丢失、被盗、过期、停机或本人无法工作时，怎么恢复和交接。

本组的证据与使用方法

正文已将教学假设、经验评分与官方规则分开。每篇末尾有具体实操验收及直接参考；成本、工时与打分是演示输入，按自己的产品重算。平台账户资格、法律适用和生产操作仍按实际环境核对，不能用目录中的摘要代替正文条件。

关键规则入口

• Git bundle ：Git 引用与对象的备份范围。
• EDPB 泄露指南 ：按角色与风险通知。
• Apple 恢复密钥 ：与通用备用码不同。

使用说明

• 每篇都可以单独读，但 01 是地图，03 是根节点，建议先读这两篇。
• 文中涉及域名、商店、支付平台的规则和费用，都标注「写作时快照」；这些规则会变，使用前请到官方页面核对。
• 系列不提供法律、税务或保险意见。涉及合同、继承、公司主体的部分只给检查清单和官方入口。
• 不要把本文的清单当成合规认证。它是一份个人运维清单，不是 SOC 2，也不是 ISO 27001。