用唯一约束实现幂等

痛点：移动端请求容易被重复执行：连续点击、WorkManager 重试、进程重启恢复任务，都可能 提交同一个业务动作。

@Entity(
tableName = "ledger",indices =
)
data class LedgerEntity(
@PrimaryKey val id: Long = 0L。
@ColumnInfo val requestId: String,@ColumnInfo val accountId: Long,val amount: Long,@ColumnInfo val createdAt: Long
)

唯一约束是数据库层的最终防线。即使两个任务同时检查“记录不存在”，也只有一个插入可以成功。业务层可以捕获 )，查询已有流水并返回已完成结果。

Caution:

• @OnConflictStrategy.REPLACE` 并非通用去重方案；它会删除旧行再插入新行，可能改变自增主键并破坏外键关系。
• B​A​B‑type 幂等推荐使用 A​BORT` 配合唯一键；若需要忽略重复数据，可使用 @OnConflictStrategy.IGNORE` 并检查返回值。

多端同步需要明确冲突规则

痛点：远端同步把并发问题从单进程扩大到了多设备。若仅采用“服务端覆盖本地”策略，会抹掉尚未上传的本地修改。

@Entity
data class NoteEntity(
@PrimaryKey val id: String,val content: String,val version: Long,val syncState: SyncState,val updatedAt: Long
)

S​QL 条件更新确保版本匹配：

@Query(
"""
UPDATE note
SET content = :content,version = version + 1。syncState = :pending,updatedAt = :updatedAt
WHERE id = :id AND version = :expectedVersion
"""
)
suspend fun updateIfVersionMatches(
从id来看，String,content: String,expectedVersion: Long,pending: SyncState,updatedAt: Long
): Int

If affected row count is 0,version has already changed;caller must reload and apply a conflict‑resolution strategy . The database only helps us reliably detect conflicts;business logic decides how to resolve m.

Flow 观察与事务提交的配合

Trouble:P​age UI may see intermediate states when multiple tables observed by separate Flows are updated in sequence.

data class AccountOverview(
@Embedded val account: AccountEntity。@Relation(
parentColumn = "id",entityColumn = "account_id"
)
val ledgers: List
)
@Transaction
@Query
fun observeOverview: Flow

The @Transaction` ensures Room reads master and related tables within a single consistent snapshot,eliminating “主表已更新、明细表还没更新”的短暂不一致。这 addresses read‑consistency concerns distinct from write‑transaction issues.

协程 Mutex 什么时候有用

Pain point:A developer may think a simple in‑process lock can solve all concurrency bugs.

• The lock does not work across processes or after app restart.
• The lock cannot protect against server‑side or multi‑device races.
• If used。treat it as an optimization to reduce contention,not as a correctness guarantee.

If you decide to use M utex ,place it around code that decides *wher* to hit DB,not around DB call itself – DB must still enforce its own constraints.

 p>
状态 切 换 使用 条 件 更新，如 ：只有 PENDING 才 能变 成 UPLOADING。启 动 任 务 时 回 收 超 时 停 留 在 UPLOADING 的记录，防 止 永 久 无 法 重试。服务端 接口 同 样 接 收 同 一 个 requestI d，实现 端 到 端 幂 等。/ p>

如何测试并发正确性

 p>
单 次 成 功 流 程 不 足 以 揭 示 竞 爭 问题。在 instrumented test 中 使用 真 实 Room 数据 库，同 时 启 动 多 个 协 程 抢 占 同 一份 数据。/ p>
pre>@Test

 ul>
li> 查 找 “ 查询 后 再 更新 ” 的代码，确认 判 定 与 写 入 是否 原 子。/ li>
li> 检 查 跨 表 写 入 是否 位 于 同 一个 withTransaction 中。/ li>
li> 检 查 业 务 唯一 键 是 否 真 正 建立了 数据 库 唯一 索 引。/ li>
li> 确认 冲 突 策 略，尤 别 留 意 REPLACE 带 来 的 删除 再 插 入 语义。/ li>
li> 检 查 网络 调 用 或 耗 时 計算 是否 占 用了 数据 库事 务。话说回来，/ li>
li> 对 照 WorkManager 和 接口 重试 日 志。确认 请求 标识 是否 稳定。/ li>
li> 为关键 更新记录受影响 行 数 、版 本号 与 请求 标识 做 日志，避免仅记录 异 常 堆 栈。/ li>
/ ul>

 p>
Room 的 并 发 靠谱 性 建立 在 明 确 的 数据 不变量 上 . 单 字 段变 更 优先 使用 条 件 更新,跨 表业 务 使用 短 事 务,重复 操 作 靠 唯一约束 和 稳 定 请求 标识。多端 修改 通 过版 本号 暴露 冲 突 . Flow 、 协 程 与 Mutex 可 改 善 调 用 方 式 与 效率,但 最终 正确 性 必 须 靠 Transaction 与 数据库约束 保证 .
/ p>
p>
当这些规则渗透到表结构 、DAO 返回 值 和 自动化测试 中 后,并 发 问题 将 不 再 是 “调用顺序应该没问题” 的 假设,而 是 能 被 检测 、 拒绝 与 恢复 的 可 确定 行 为 .
/ p>