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 变更脚本，或在应用层加审计字段。
