Navicat Cloud 同步失败不会直接导致数据丢失，但会引发本地与云端状态脱节，造成误操作覆盖、merge策略误选或同步未生效却误以为已成功。
navicat cloud 同步失败本身不会直接导致数据库里的数据丢失，但会引发本地模型、查询文件或连接配置与团队实际状态脱节——你看到的“数据不见了”，大概率是同步中断后误操作覆盖、选错 merge 策略，或根本没同步成功却以为已生效。
同步提示 “Conflict detected” 但没说哪行冲突
Navicat Cloud 不做字段级比对，只校验整张表的版本哈希和最后修改时间戳。一旦多人改同一张表（哪怕不同行），后提交方就会被拦下，弹窗只显示 conflict detected: remote version is newer，不标红、不定位。
- 先停掉所有正在编辑该表的 Navicat 实例（包括同事），避免二次冲突
- 打开
Tools → Cloud Sync Status，找带 ⚠️ 图标的表，点开看Local version和Cloud version号 - 右键该表 →
Compare with Cloud（仅 MySQL/PostgreSQL 支持）；SQLite 无法用此功能，得手动连库查SELECT * FROM table WHERE id = ? - 重点筛
PRIMARY KEY或UNIQUE列值相同的行——这些才是真冲突源，其余差异只是“看起来像冲突”
点 “Use Local” 后发现云端改动没了
Navicat 的 merge 是单向覆盖，不是字段合并。比如本地改了 name，云端改了 email，选 Use Local 就会把 email 强制回滚到旧值。
- 别急着点 merge：先导出本地变更，右键表 →
Export Wizard→ 格式选 SQL，勾选Only INSERT/UPDATE statements - 再手动连云端数据库执行
SELECT，确认哪些字段当前值是你真要保留的 - 如果必须保双方修改，得切到 SQL 模式，用
SELECT ... FOR UPDATE锁住行，手写UPDATE合并逻辑，再同步 -
merge操作不可撤回，且不会触发外键级联或触发器——这点常被忽略
同步后 SQL 查询文件或连接配置“消失”了
这不是同步失败，而是同步对象压根没被纳入范围。Navicat Cloud 默认只同步「已保存的 .sql 文件」和加密的 connections.ncx，其他都当空气。
- 未命名/未保存的查询标签页（如
Untitled-1）永远不参与同步；日志里出现Skipped: unsaved tab 'Untitled-1'就是铁证 - 新建查询后立刻右键标签页 →
Save As，存到团队共享路径（需提前在Tools → Options → Cloud → Sync Folders中添加） -
connections.ncx文件路径可能错位：检查Tools → Options → General → Configuration Folder是否真实可读写；若修改时间滞后，说明 Navicat 正在用另一个配置文件工作 - 绝对不要手动编辑
connections.ncx——它被加密且带签名，改完会导致同步拒绝加载
ERROR 1062 报错卡死，或同步后数据量变少
报 ERROR 1062: Duplicate entry 说明两边主键/唯一键冲突，Navicat 默认中断而非跳过。所谓“数据少了”，其实是重复记录被拒之门外，不是删了旧数据。
- 改用“仅数据同步”模式，在同步向导 →
选项 → 错误处理页勾选Skip duplicate key errors（Navicat 15+ 才有） - 启用前确认业务允许“以目标库为准”；否则可能静默丢掉本该保留的冲突记录
- 检查主键字段是否含时区敏感值（如
DEFAULT CURRENT_TIMESTAMP），本地和云端时区不一致会导致值重复 - 同步日志里若出现
Skipped: table 'log_table'，说明你没在向导里勾选该表——Navicat 不自动同步日志表，得手动加
最易被忽略的一点：Navicat Cloud 的同步粒度是「整张表」或「整个查询文件」，没有行级、字段级、语句级控制。你以为改了一行就只传一行，其实它拉的是全表快照比对；你以为删个字段就只更新字段，其实它重建整个模型。协作中真正要防的，从来不是网络或权限，而是对同步机制的误判。
