掉签之后最常见的追问是：我重新签一次、重新装一遍，原来的聊天记录、游戏存档、登录状态还在吗？答案是——换签名重装，本地数据基本会全部清空，而且这不是服务商技术不到位，是 iOS 的存储机制决定的。

一句话结论

iOS 给每个 App 划了一块独立的存储区，叫沙盒（Sandbox，沙箱：App 只能读写自己的那块空间，不能碰别人的）。这块存储区的身份钥匙是包名（Bundle ID，应用的唯一身份标识）。重签名时包名一旦改变，系统就会认为「这是一个全新的 App」，给它分配一个全新的空沙盒，旧数据留在原地、但新 App 根本看不到。

沙盒里到底存了什么

一个 App 的本地数据几乎全在沙盒里，大致分四类：

• 用户产生的内容：聊天记录、草稿、图片缓存、离线下载的文件、游戏存档。
• 登录凭证：存在钥匙串（Keychain，系统级的加密存储，专门放密码和令牌）里的账号令牌，以及存在偏好设置里的登录态。
• 配置与缓存：App 的设置项、已加载过的资源缓存。
• 数据库文件：绝大多数 App 用本地数据库存结构化数据，这些文件同样躺在沙盒里。

这四类里，只有钥匙串的存储规则比较特殊——它不完全跟着包名走，而是跟着「开发者团队标识 + 应用标识前缀」走。这就解释了为什么有时候换签名后账号还在，有时候又要求重新登录：取决于签名方用的是不是同一个开发者账号。跨服务商重签，几乎必然换账号，登录态也就一起没了。

卸载重装和换签名重装，不是一回事

这里有个容易混淆的点值得单独说清楚：

• 只重装、不换签名：包名没变，但卸载这个动作本身会清空沙盒。除非之前做过系统备份，否则本地数据同样会丢。
• 覆盖安装、不卸载：包名一致时直接覆盖安装，沙盒会保留，数据通常还在。这也是最理想的更新方式。
• 换签名后安装：包名变了，系统会当成两个不同的 App。如果旧版本还没删，你会看到桌面上出现两个图标，各自有各自的数据，互不干涉。

所以「换签名商」这个动作本身，就把数据继承这条路堵死了一大半。

哪些数据其实不在沙盒里

也不是所有东西都会丢。判断标准很简单：数据存在哪儿，就跟着哪儿走。

• 存在服务端的账号数据：只要你的账号体系是服务器存的，重新登录就能全部回来。这是最稳妥的一类。
• 手动导出到系统相册、文件 App 的内容：导出之后就不属于原 App 的沙盒了，换什么签名都不影响。
• 系统备份里的内容：如果之前做过整机备份，且备份时 App 数据被纳入了备份范围，理论上可以从备份恢复。但注意，恢复的是整机状态，操作成本不低，而且换包名之后能否正常关联，需要实测确认。

能不能提前预防

能，而且成本很低，关键是别等掉签了才想起来：

• 推动 App 把关键数据上云。开发方只要把存档、记录同步到服务端，签名怎么换都不影响。
• 在 App 内做导出入口。把重要数据导出成文件、存到系统文件或相册，是用户能自己操作的最后一道保险。
• 养成定期导出的习惯。对于没有云同步的 App，隔一段时间导一次，比事后抢救现实得多。
• 选签名服务时把「包名是否固定」问清楚。有些方案能保持包名不变，后续升级就能走覆盖安装，数据可以继承。

小结

换签名重装丢数据，不是谁的失误，而是沙盒（Sandbox）机制与包名绑定关系共同作用的必然结果。真正能救数据的只有三样：服务端同步、提前导出、保持包名不变的覆盖升级。把这三件事做在前面，掉签就只是一次重装，而不是一次事故。

---

我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920　微信：A-mk5888）