Notifio 的自动回复功能会记录用户回复以创建未来的自动化响应，并将此数据本地存储，不上传至任何外部位置。该敏感数据的完整安全边界即为用户磁盘上的本地文件。Electron 的 safeStorage 提供加密功能，但其可用性无法在所有 Linux 环境中得到保证，因此需要实现优雅的降级处理。为此，Notifio 写入的每个文件都在其"Envelope"结构中包含一个"enc"字段，明确声明该文件是加密保存还是以明文形式保存。这避免了加密数据与损坏数据之间的歧义，否则两者均可能表现为解析失败。"writeEnvelope"函数在 safeStorage 可用时对其进行加密；否则，将其保存为明文 JSON 字符串。此设计做出了明确的选择：在无法加密的场景下（例如在没有运行 keyring 的 Linux 机器上），优先考虑可用性而非机密性。在这种情况下，数据以明文形式保存在用户的家目录中，以确保功能仍可正常运行。"readEnvelope"函数会显式检查"enc"字段，拒绝猜测文件格式，并在无法解密加密数据时抛出错误。"Envelope"本身拥有一个版本号，与内容的版本号相互独立，承认容器格式与内容形态可独立变更。"canEncrypt"函数能够优雅地处理 safeStorage 可能不可用的情况，返回 false 而非在 Electron 环境之外抛出错误。这种方法确保了模块可以可靠地加载和测试，而无需依赖平台特定的 API。至关重要的是，读取路径明确拒绝猜测文件格式。如果文件声称已加密但 safeStorage 不可用，则抛出特定错误，防止尝试将密文解析为内容。这种清晰的错误报告对于支持和调试至关重要，能够区分加密失败与一般性损坏。虽然读取损坏的文件可能会返回降级结果，从而导致覆盖，但这一风险通过数据的特定性质得到缓解（例如，单个布尔值，或仅在添加新内容时写入的录音）。设置文件和录音文件使用相同的信封格式，简化了加密路径，并在出现持久性问题时便于调试。当数据结构演进时，迁移过程可能会丢弃某些仍需为遗留目的访问的字段。在这种情况下，特定的"legacyMessage"函数会绕过主迁移流程以检索旧数据，承认删除字段并非完全没有代价。总体规则是：文件应明确声明其写入方式，从而促进清晰的错误处理，并支持在不执行特定代码的情况下进行外部分析。