Cloud Firestore：更新单个字段与合并整文档的成本差异官方确认

问题背景 #

我正在开发一款以Firebase作为BaaS的UIKit应用，用户需要修改用户名。Firestore中存储的用户配置文档包含用户名、邮箱等字段。想确认是否有官方依据说明：从客户端重新保存整个文档（启用merge:true合并现有内容）比单独更新用户名字段的成本更高？目前我觉得让Firestore自动合并整文档的实现方式更便捷，附上Swift示例代码：

class DatabaseController {
    let db: Firestore
    let authController: AuthControllerProtocol
        
    init(
        db: Firestore = .firestore(),
        authController: AuthControllerProtocol
    ) {
        self.db = db
        self.authController = authController
    }
    
    // 方法一：每次保存整个文档，与现有内容合并（如果存在）
    func save(_ profile: Profile) async {
        guard let currentUserUid = authController.auth.currentUser?.uid else {
            print(">>> \(Self.self).\(#function): 无法获取当前用户UID")
            return
        }
        
        do {
            let encodedProfile = try Firestore.Encoder().encode(profile)
            do {
                try await db.collection("users").document(currentUserUid).setData(encodedProfile, merge: true)
            } catch {
                print(">>> \(Self.self).\(#function): 无法更新用户配置：\(error.localizedDescription)")
                return
            }
        } catch {
            print(">>> \(Self.self).\(#function): 无法编码用户配置：\(error.localizedDescription)")
        }
    }
    
    // 方法二：仅更新已知需要修改的特定字段
    func save(_ username: String) async {
        guard let currentUserUid = authController.auth.currentUser?.uid else {
            print(">>> \(Self.self).\(#function): 无法获取当前用户UID")
            return
        }
        
        do {
            try await db.collection("users").document(currentUserUid).setData(["username": username], merge: true)
        } catch {
            print(">>> \(Self.self).\(#function): 无法更新用户名：\(error.localizedDescription)")
            return
        }
    }
}

成本分析与官方依据 #

Firestore的成本主要由文档写入次数和数据传输量两部分决定：

• 写入次数成本：不管是整文档合并更新，还是单独字段更新，只要是对同一个文档进行修改，都只会算作1次文档写入操作，这部分成本完全一致。
• 数据传输成本：整文档合并会发送整个Profile对象编码后的所有字段数据，而单独字段更新只发送用户名字段的键值对。显然后者的数据传输量更小，带宽消耗更低。

Firestore官方明确说明，更新特定字段比替换/合并整个文档更高效，尤其是当文档包含大量字段或大尺寸数据时。不过如果你的用户配置文档字段数量少、数据量小，这种传输量的差异几乎可以忽略，此时整文档合并带来的开发便捷性（无需单独维护各个字段的更新逻辑）反而更有价值。

结论 #

如果你的用户配置文档结构简单、数据量小，选择整文档合并更新的方案完全可行，开发效率的提升远大于那点可以忽略的传输成本；如果文档字段多、数据量大，建议优先使用单独字段更新的方式来减少带宽消耗。

内容的提问来源于stack exchange，提问作者Filippo