Firebase数据库在设计上支持多客户端实时同步，但当多个用户同时修改同一条记录时，简单的写入操作会引发经典的“丢失更新”问题。例如一个计数器当前值为10，两个客户端几乎同时读取到10，然后各自加1并写回11，最终结果应该是12，却变成了11。事务（transaction）正是为这类场景提供的原子操作能力：它读取数据、执行更新函数、写入数据，并且在写入前会再次检查数据是否在读取后被其他客户端修改过，如果发生冲突，事务会自动重新执行更新函数，直到没有冲突或达到重试上限。
事务机制解决了什么问题
在没有事务的并发环境中，对同一个字段的修改往往是不可预测的。假设两个客户端同时向列表中追加元素，或同时调整用户余额，后写入的客户端会完全覆盖先写入的内容，导致其中一次修改永久丢失。Firebase SDK虽然提供了基于版本号的乐观并发控制机制，但开发者手动实现起来较为繁琐，事务则将这些细节封装在内部，开发者只需提供一个更新函数，描述如何根据当前值计算新值即可。
事务的核心在于“读取-计算-写入”三个步骤必须作为一个原子单元执行。在Firebase的实现中，事务函数可能会被多次调用，每一次调用都会从服务器获取最新的数据快照，执行更新函数，然后尝试提交。如果提交时发现数据版本已经发生变化，SDK会自动重新获取最新数据并再次执行更新函数，这就是所谓的自动重试。这种机制保证了最终写入的值是基于最新数据计算出的，从而避免了覆盖丢失。
需要注意的是，事务并不是万能的，它更适合依赖当前值进行计算的场景，比如计数器增减、余额调整、条件更新等。如果更新逻辑不依赖旧值，使用set或update配合安全规则往往更高效。另外，事务的自动重试意味着更新函数必须是纯函数，不能包含对外部状态的修改（例如发送网络请求、写入其他数据库），否则重试会产生副作用。
在Realtime Database中使用事务
Realtime Database的SDK提供ref.transaction()方法，该方法接收一个更新函数和一个可选的完成回调。更新函数会收到当前的数据快照，返回值可以是新的数据值、undefined（表示中止事务）或者一个transaction.abort()的调用。下面用一个计数器示例展示基本用法。
// 获取数据库引用
var db = firebase.database();
var counterRef = db.ref('counters/visits');
// 执行事务
counterRef.transaction(function(currentValue) {
// currentValue 是当前计数器的值，可能为 null（如果节点不存在）
if (currentValue === null) {
return 1;
} else {
return currentValue + 1;
}
}, function(error, committed, snapshot) {
if (error) {
console.log('事务失败: ', error);
} else if (committed) {
console.log('事务成功，当前值为: ', snapshot.val());
} else {
console.log('事务被中止，未应用更新');
}
});
上面的代码中，更新函数每次被调用时都会收到服务器端的最新值currentValue。如果两个客户端同时执行该事务，一个客户端先提交成功，另一个客户端在提交时发现值已变化，SDK会自动重新调用更新函数并传入新的值，最终两个客户端的递增操作都会生效，不会丢失任何一次更新。如果开发者希望在特定条件下放弃更新，可以在更新函数中返回undefined，或者调用transaction.abort()，此时事务会被中止，不会写入任何数据。
需要特别强调的是，Realtime Database的事务更新函数可能被调用多次，因此函数内部不应包含任何有副作用的操作，例如修改闭包外的变量、执行日志写入以外的I/O操作等。同时，该函数应当快速返回，避免阻塞主线程。由于事务需要与服务器进行多次往返，网络延迟会对性能产生影响，不适合高频更新的场景。
Cloud Firestore中的事务操作
Cloud Firestore也提供了事务支持，但其API与Realtime Database略有不同。Firestore使用runTransaction()方法，该方法接收一个异步函数作为参数，函数内部通过transaction.get()读取文档，通过transaction.set()或transaction.update()写入文档。一个典型的转账场景如下：
// 获取 Firestore 实例
var db = firebase.firestore();
// 定义两个账户的引用
var fromRef = db.collection('accounts').doc('userA');
var toRef = db.collection('accounts').doc('userB');
// 执行事务
db.runTransaction(function(transaction) {
// 读取转出账户
return transaction.get(fromRef).then(function(fromDoc) {
if (!fromDoc.exists) {
throw new Error('转出账户不存在');
}
var fromBalance = fromDoc.data().balance;
var transferAmount = 100;
if (fromBalance < transferAmount) {
throw new Error('余额不足');
}
// 读取转入账户
return transaction.get(toRef).then(function(toDoc) {
var toBalance = toDoc.exists ? toDoc.data().balance : 0;
// 更新两个账户
transaction.update(fromRef, { balance: fromBalance - transferAmount });
transaction.update(toRef, { balance: toBalance + transferAmount });
return transferAmount;
});
});
}).then(function(transferAmount) {
console.log('转账成功，金额: ', transferAmount);
}).catch(function(error) {
console.error('事务失败: ', error);
});
在这个示例中，事务函数会依次读取转出账户和转入账户的数据，检查余额是否充足，然后分别更新两个文档的余额。所有读取和写入操作都在同一个事务上下文中完成，Firestore会保证这些操作的原子性——要么全部成功，要么全部失败。如果事务执行期间有其他客户端修改了这些文档，Firestore会丢弃当前事务的写入并重新运行事务函数，直到成功或重试次数耗尽。
与Realtime Database不同，Firestore事务支持读取多个文档并进行组合更新，这为涉及多文档一致性的操作提供了强大支持。但需要注意，事务中读取的文档数量不能超过一定限制（默认是100个），而且事务函数必须是异步的，并且不能包含任何非事务性的读写操作，否则会被SDK拒绝。此外，Firestore事务不支持离线执行，必须在设备在线时才能提交。
事务使用时的注意事项与最佳实践
无论是Realtime Database还是Cloud Firestore，事务都存在一些共同的使用限制。首先，事务更新函数不应包含对外部状态的修改，因为函数可能因冲突被重复调用，修改外部状态会导致不可预期的副作用。其次，事务应保持简短，尽量减少读取和写入的数据量，因为事务执行时间越长，与其他客户端发生冲突的概率越高，重试次数也会增加，最终可能导致失败。
对于Realtime Database，事务不支持在离线状态下执行，若设备处于离线，事务会立即失败并返回错误。而Firestore的事务同样需要网络连接，离线时无法提交。开发者在设计应用时，应当为事务失败提供合理的回退策略，例如捕获错误后提示用户重试，或者将操作放入队列等待网络恢复。
另一个常见误区是在事务中执行耗时计算或异步操作。Firestore的runTransaction()要求事务函数返回一个Promise，但这并不意味着可以在其中随意加入网络请求或长时间循环。所有操作应尽可能快速完成，避免阻塞事务队列。此外，当事务冲突频繁发生时（例如热门数据的计数器），可以考虑使用分布式计数器或分片技术来降低争用，Firestore官方文档也提供了相关的实现建议。
最后，虽然事务能解决大部分并发更新问题，但它并不适合所有场景。如果更新逻辑非常简单且不依赖旧值，直接使用set或update配合安全规则即可满足需求；如果更新依赖于多个不相关的文档，过度使用事务反而会增加延迟和成本。合理评估业务需求，选择合适的写入策略，是构建高效Firebase应用的关键。