Navicat Cloud冲突提示“Conflict detected”源于本地与云端对同一主键/唯一键记录的修改差异，采用时间戳+变更摘要的乐观锁机制而非字段比对；需通过Cloud Sync Status查看版本号、Compare with Cloud对比数据，并优先筛查主键或唯一键重复行以定位真冲突源。
同步时提示“Conflict detected”但没说哪行冲突
navicat cloud 不会高亮具体冲突字段或行，只弹窗提示 conflict detected，本质是本地和云端对同一张表的同一主键（或唯一键）记录做了不同修改。它背后用的是基于时间戳+变更摘要的乐观锁机制，不是逐字段比对。
实操建议：
- 先停掉所有正在编辑该表的 Navicat 实例（包括其他同事），避免二次冲突
- 打开
Tools → Cloud Sync Status，查看带 ⚠️ 图标的表，点开后能看到「Last synced」时间和「Local/Cloud version」两个版本号 - 右键该表 →
Compare with Cloud，它会拉取云端快照做结构+数据对比（注意：仅支持 MySQL/PostgreSQL；SQLite 不支持此功能） - 若对比结果太多，优先筛出
PRIMARY KEY或UNIQUE约束列值相同的行——这些才是真冲突源
merge 选“Use Local”还是“Use Cloud”后数据丢了
选错 merge 策略不会“丢数据”，但会导致你预期的那部分变更被覆盖。Navicat Cloud 的 merge 是单向覆盖，不合并字段级差异。比如本地改了 name 字段、云端改了 email 字段，选 Use Local 就会把云端的 email 改回旧值。
实操建议：
- 别直接点 merge，先导出本地变更：右键表 →
Export Wizard→ 格式选SQL，勾选Only INSERT/UPDATE statements - 再手动查一遍云端当前值（连上云数据库执行
SELECT * FROM table WHERE id = ?），确认哪些字段真需要保留 - 如果必须保双方修改，得切到 SQL 模式：用
SELECT ... FOR UPDATE锁住行，手写UPDATE合并逻辑，再同步 - 注意：merge 操作不可撤回，且不会触发外键级联或触发器
多人协作时，为什么总在同一个表上反复冲突
根本原因不是网络或权限，而是缺乏变更隔离。Navicat Cloud 同步粒度是「整张表」，只要有人提交了该表任意一行的变更，其他人再改同一张表就会触发校验——哪怕改的是完全不同的行。
实操建议：
- 把高频更新的大表按业务域拆成子表（例如
orders_2024_q1、orders_2024_q2），用视图统一查询，降低冲突概率 - 禁用自动同步：取消勾选
Settings → Cloud → Auto-sync on save，改用定时任务 +navicat-cli --sync控制节奏 - 给团队约定「编辑窗口期」：比如每天 10:00–10:15 全员只读，10:15–10:30 统一提交，避开零散修改高峰
- 检查表是否有未显式定义主键：Navicat Cloud 依赖主键识别行，无主键表每次同步都会全量重刷，极易误判冲突
同步后发现中文乱码或时间偏差
这不是冲突，是环境层编码/时区不一致导致的「假冲突」。Navicat Cloud 本身不转码、不转换时区，它原样传输字节流和 UNIX 时间戳。
实操建议：
- 确认本地 Navicat 的连接设置里
Character set和云数据库实际character_set_database一致（常见坑：utf8mb4vsutf8） - 检查操作系统时区：Mac/Linux 运行
date，Windows 运行tzutil /g，确保和云数据库所在服务器时区相同（尤其跨地域部署时） - 如果云数据库用的是 RDS 类服务，进控制台查
time_zone参数，不要信 Navicat 右下角显示的时区 - 临时验证方法：在 Navicat 中执行
SELECT @@character_set_client, @@time_zone;，对比本地连接和云连接的结果
最麻烦的从来不是冲突本身，而是冲突发生后没人去看 Cloud Sync Status 里的版本号差异，直接点 merge。版本号差 1 看似小，可能隔着三次未提交的中间状态。
