Remotely-Save插件在iOS设备上的存储配额问题分析与解决方案

问题背景

Remotely-Save是一款用于Obsidian笔记同步的插件，支持多种云存储服务。近期有用户反馈在iOS设备上同步包含800个项目的保险库时出现"quota has been exceeded"错误，而同步200个项目的小型保险库则能成功。该问题在Windows和macOS上未复现，且与使用的云服务(S3/Dropbox)和加密设置无关。

技术分析

经过深入排查，发现问题根源在于iOS的"安全保护模式"(Security Protection Mode)。安全保护模式是苹果为高风险用户提供的极端安全保护功能，它会严格限制多种系统功能，包括：

1. Web存储限制：安全保护模式下会禁用IndexedDB和LocalStorage API
2. 存储配额缩减：显著降低网页应用的存储配额限制
3. API访问限制：阻止某些浏览器API的正常工作

Remotely-Save插件默认使用IndexedDB作为存储后端，当检测到IndexedDB不可用时，会回退到LocalStorage。但在安全保护模式下，两种存储机制都受到限制，导致插件无法正常存储同步计划历史数据。

问题表现

具体表现为：

• 同步过程中抛出"DOM Exception 22: The quota has been exceeded"错误
• 错误发生在LocalStorage存储操作时
• 临时删除remotelysavedb/syncplanshistory/[id]数据可暂时解决问题，但下次同步会再次出现

解决方案

临时解决方案

1. 关闭安全保护模式：在设置 > 隐私与安全性 > 安全保护模式中完全禁用
2. 部分豁免：在安全保护模式的"配置网页浏览"设置中单独排除Obsidian应用

长期技术方案

从技术实现角度，插件可以考虑以下改进方向：

1. 显式指定存储后端：强制使用IndexedDB而非自动回退到LocalStorage
2. 文件系统存储：改用iOS提供的文件系统API存储同步数据
3. 内存缓存：对于临时数据，可考虑纯内存缓存方案
4. 配额检测：在操作前检查可用存储配额并提前预警

技术建议

对于开发者而言，处理iOS特殊模式时应注意：

1. 特性检测：应主动检测运行环境是否处于安全保护模式
2. 优雅降级：为受限环境设计替代方案
3. 错误处理：对存储操作进行完善的错误捕获和恢复
4. 容量管理：实现自动清理旧数据的机制

总结

iOS安全保护模式下的存储限制是导致Remotely-Save同步失败的根本原因。虽然目前可通过调整系统设置临时解决，但从长远看，插件需要适配这种特殊安全环境。建议用户在关键工作流程中暂时禁用安全保护模式，或等待插件未来版本对受限环境的更好支持。

对于开发者社区，这也提出了一个值得思考的问题：如何在保证安全性的前提下，为安全敏感用户提供可用的同步功能。文件系统存储方案可能是最有前景的解决方向。