密码库同步冲突怎么解决：先辨三种冲突，再选合并顺序
两台设备都改过同一个条目，第二天打开发现密码是旧的；或者密码库里突然冒出好几个「conflicted copy」文件，条目少了几十条。这类问题最麻烦的地方不是报错，而是没有报错，数据被旧版本悄悄盖掉。
很多人一看到同步失败就去搜报错码，结果被 409、冲突副本这些词绕晕。正确顺序应该反过来：先判断属于哪种冲突，再决定合并还是覆盖，最后才看具体报错。顺序错一步，轻则丢几条新改的密码，重则整库回滚到上周。
一、先分清三种冲突，处理方式完全不同
「同步冲突」是笼统说法，实际至少三类，危险程度差很多。分不清就动手，容易把能救的数据一起覆盖掉。
| 类型 | 典型表现 | 丢数据风险 | 处理方向 |
|---|---|---|---|
| 文件级冲突 | 目录里出现「副本」「conflicted copy」「(1)」等同名文件 | 低：两份都在，需人工合并 | 比对修改时间与条目数，保留更全的一份 |
| 覆盖式冲突 | 没有报错，条目回到旧值，新增条目消失 | 高：旧文件盖掉了新文件 | 立刻停同步，从历史版本或本地备份取回 |
| 锁与写入冲突 | WebDAV 返回 409、423，提示文件被占用 | 中：写入被拒，原文件通常完好 | 清缓存与锁文件，重新拉取后再提交 |
判断技巧：先看目录里有没有多出来的副本文件。有副本，说明工具替你留了两份，可以从容处理；没有副本但内容变旧，属于第二类，必须马上停手，因为下一次同步还会继续覆盖。
二、动手前的三步固定动作
不管哪一类，前三步都一样，目的是把「可能被覆盖的东西」先固定下来。
- 停掉所有设备的自动同步。关网盘客户端、退出密码库、关掉手机端同步开关。只留一台在同步，合并过程也会被它再盖一次。
- 把当前库复制一份到别的目录。文件名带日期，例如
vault-20261028.kdbx，这份副本不参与同步，是最后的兜底。 - 记下每份文件的条目数和修改时间。多数库在「数据库信息」里能看到条目总数，比肉眼翻列表可靠得多。
三步花不到三分钟。特别提醒：不要在有冲突时继续新增条目，新增的往往正是被覆盖的那批。
三、按同步通路决定处理顺序
| 同步通路 | 冲突根源 | 处理顺序 |
|---|---|---|
| 网盘客户端（坚果云、OneDrive、iCloud） | 按文件整体覆盖，慢一步上传就等于旧版获胜 | 关客户端 → 本地比对两份 → 保留较新的一份改回原名 → 再开客户端 |
| WebDAV 直连 | 版本号或 ETag 不匹配、遗留锁文件 | 清缓存 → 删残留的锁与临时文件 → 重新下载 → 再上传 |
| 密码库自带云同步 | 条目级合并，同一字段两边都改会保留一边 | 在同步历史里逐条比对 → 手工补齐被丢弃的字段 |
最容易踩坑的是第一种：网盘同步的是文件，不是条目。两台设备各改一条，最终只有一个文件胜出。所以用文件同步时，最重要的习惯是「改完等它同步完成，再换设备」。
WebDAV 反复返回 409 时，多数不是密码错，而是上次写入留下了锁。清空客户端缓存、删掉服务器上以 .~lock、.tmp 结尾的残留文件，重新打开即可；仍失败就把库下载到本地编辑，另存新文件名后让客户端改指向，比反复重试快得多。
四、合并还是覆盖：三条判断标准
两份文件摆在面前最怕凭感觉选，按这三条依次判断基本不会错。
- 看条目数。多的那份通常含更多新增；但若多出来的是一批重复条目，反而说明它经历过异常合并。
- 看时间戳，但不迷信时间戳。被旧文件覆盖后，时间会变成覆盖那一刻。只有时间新且条目数没减少才可信。
- 看关键条目是否还在。挑三条最近新增的账号去搜，搜不到就说明这份是旧版。
两份各有新增时别手工挑条目：以条目多的为主库，把另一份独有的条目导入补齐，导入后核对总数。导入前先关自动同步，否则导入本身又会触发一次冲突。
五、防复发：五条设置比事后抢救便宜
- 只让一个通道同步。网盘客户端和 WebDAV 指向同一文件，冲突概率翻倍。
- 开启历史版本。网盘历史版本与库的自动备份都打开，保留期不少于 30 天。
- 给同步加延迟。支持「修改后等待 N 秒再上传」的客户端，能吸收连续保存的中间状态。
- 换设备前手动同步一次。手机端后台同步经常被系统杀掉，看着同步了其实没有。
- 每月核对条目总数。数字突然变小就是最早的警报，参考备份 3-2-1 策略怎么落地把库也纳入备份。
设备越多冲突越频繁。先想清楚哪些设备真需要离线库，其余用只读或访客方式接入，能少掉大半麻烦，边界见一个密码管理器能装几个设备。
常见问题
同步冲突会导致密码泄露吗？
冲突本身不会。副本文件仍是加密的，只是多一份拷贝。真正的风险是副本被传到聊天工具或公共网盘，那时加密强度与主密码强度就直接决定后果。
手机提示「保留本地」和「保留云端」，选哪个？
先看两边的修改时间与条目数，不要默认选本地。本地刚改完还没传上去就选本地；本地只是打开过没编辑，选云端更安全。
冲突修好后旧密码还有效吗？
若冲突期间旧密码曾被同步到某个站点，服务端可能仍短暂有效。修完库后，把涉及的几个账号各改一次密码，是最稳妥的收尾。
能完全避免冲突吗？
用文件同步就无法完全避免，只能降低概率：少设备、单通道、改完等同步完成。想彻底绕开，得换成条目级同步方案，代价是依赖服务商。
小结
核心顺序是：先停同步保住现场，再分清文件级、覆盖式还是锁冲突，按同步通路选步骤，最后才谈合并。合并时以条目多、关键条目在的那份为主库，独有条目导入补齐。真正省事的是事后那五条设置——单通道、开历史版本、延迟上传、换设备前手动同步、每月核对条目数。冲突不可怕，可怕的是没备份就点了「覆盖」。