为何Navicat Cloud中文件同步出现版本冲突_手动选择保留本地或云端版本

Navicat Cloud“conflict detected”是数据库记录级冲突，源于本地与云端对同一主键/唯一键记录的修改差异，采用时间戳+变更摘要的乐观锁机制，不比对字段值；需通过Cloud Sync Status查版本号、Compare with Cloud对比数据，并优先筛查主键或唯一键重复行定位真冲突源。

navicat cloud 显示“conflict detected”不是文件系统级冲突，而是数据库记录级冲突——它根本没在同步“文件”，而是在校验同一张表里、同一个主键（或唯一键）值的两条记录是否被本地和云端各自修改过。所谓“保留本地”或“保留云端”，本质是单向覆盖整行，不是合并字段。

为什么 Navicat Cloud 不告诉你哪一行、哪个字段冲突

它不比对字段值，只比对「变更摘要 + 时间戳」。当本地和云端都对 users 表中 id = 123 的记录执行过 UPDATE，哪怕只改了不同字段（本地动了 email，云端动了 phone），Navicat Cloud 就判定冲突，弹窗只提示 conflict detected，不会高亮具体字段。

• 后台机制是乐观锁：每条记录带隐式版本号（非真实字段），修改时校验该版本是否未变
• Compare with Cloud 功能仅支持 MySQL/PostgreSQL；SQLite 直接不可用，连对比入口都不显示
• 冲突提示出现后，Cloud Sync Status 里的 Local version 和 Cloud version 数字会不一致，但不会标出差异在哪张表——得靠你手动点开每个带 ⚠️ 图标的表去看

选 “Use Local” 后发现云端改的字段没了，是 bug 吗

不是 bug，是设计如此。Navicat Cloud 的 merge 是整行覆盖，不是字段级合并。比如云端把 status 改成 'shipped'，本地把 updated_at 改成当前时间，你选 Use Local，结果就是 status 被打回旧值。

• 导出前务必右键表 → Export Wizard → 格式选 SQL，勾选 Only INSERT/UPDATE statements，先看本地到底改了什么
• 再连上云库执行 SELECT * FROM users WHERE id = 123，确认云端当前值
• 如果必须保双方修改，不能靠界面 merge：得切到 SQL 模式，用 SELECT ... FOR UPDATE 锁住行，手写 UPDATE 合并逻辑，再触发同步
• merge 操作不可撤回，且不会触发外键级联或触发器——这点极易被忽略

多人协作时，为什么总在同一张表反复冲突

因为 Navicat Cloud 的同步粒度是「整张表」，不是「某几行」。只要有人提交了 orders 表任意一行的变更，其他人再编辑该表任何其他行，下次同步就会触发冲突检查——哪怕改的是完全不重叠的数据。

• 高频更新的大表建议按业务域拆分：比如 orders_2024_q1、orders_2024_q2，用视图统一查询，物理隔离降低冲突概率
• 禁用自动同步：Settings → Cloud → Auto-sync on save 取消勾选，改用 navicat-cli --sync 配合定时任务控制节奏
• 团队需约定「编辑窗口期」：例如每天 10:15–10:30 统一提交，其余时间只读，避免零散修改叠加触发校验

真正麻烦的不是选“本地”还是“云端”，而是默认机制不暴露冲突细节、不支持字段级合并、也不记录谁在什么时候改了哪一行——这些都得靠外部手段补足，比如用 Git 管理 DDL 变更脚本，或在应用层加审计字段。