我有一个非常简单的用例，用户可以上传自己的个人资料图片，URL将保存在Firestore中相应用户的条目中。是否有处理原子性问题的最佳实践？
假设用户上传了图像，并且在此过程中他失去连接或应用程序崩溃，结果将是存储中的文件，但是没有与用户数据中的所述文件的连接（如果崩溃发生在上传之后但之前Firestore写道）。
我考虑使用事务来执行此操作，或者实现Cloud Function触发器，该触发器侦听存储并处理更新用户配置文件。
有没有办法处理Firestore规则的问题？
在我的具体应用程序中，我需要处理许多大图像，这就是为什么我想在客户端处理尽可能多的东西，但仍然避免在我的数据库中有大量“死”图像。
由于没有跨服务的事务，因此无法保证防止孤立映像或悬挂引用（取决于首先完成的写入）。
该解决方案通常是健壮的客户端代码（在悬挂引用的情况下）的组合，并且具有定期删除孤立图像的脚本。我还建议首先测试问题的严重程度，特别是如果你先写图像。
降低中断风险的解决方法可能是使用云功能。客户端上传到Cloud Functions，然后执行两次写入。由于云功能在服务器上运行，因此它们被中断的可能性要小得多。
另见：