Navicat Cloud不支持冲突检测与合并，仅单向覆盖文件；真正协同需启用On-Prem Server，其提供Pull-Resolve-Push流程、字段级差异比对及完整操作上下文。
Navicat Cloud根本不处理编辑冲突
它没有冲突检测、不保留历史版本、也不提供合并界面——所谓“多人编辑”，实际是后保存者直接覆盖前者的全部改动，且无任何提示。
这是因为 Navicat Cloud 的同步机制本质是单向文件托管：你本地保存一个 .nqp 查询文件，它就原样上传覆盖云端同名文件；同事下载时拿到的是最新一版，旧版已不可追溯。
- 两人同时打开同一个查询 → 各自修改 → 先点保存的人内容被存到云端 → 后点保存的人点击后，整个文件被新内容完全替换（不是局部更新）
- 操作日志里只记“
Updated query.sql”，不记录谁改了哪一行、改了什么值 - 即使你导出项目为
.npz包，解包后看到的也只是最终版 XML，没有 diff 或版本树
为什么你感觉“好像能协同”，其实是错觉
Navicat Cloud 会实时同步文件列表、项目结构、BI 工作区布局等元数据，让人误以为协作已就绪。但真正涉及逻辑变更的内容（如 SQL 文本、模型字段定义），它不做任何协调。
常见错觉场景：
- 你在 Windows 上改完一个
.nqp查询并保存 → 同事在 macOS 上打开，看到的是你的最新版 → 他以为这是“协同结果”，其实只是文件覆盖 - 你删掉一个 BI 图表的筛选器 → 同事没刷新页面，仍看到旧状态 → 他手动刷新后，筛选器消失 → 这不是同步生效，而是客户端重新拉取了当前最新快照
- 项目里显示“3 人在线”，但没人知道他们正在编辑哪个对象，更无法锁定或通知
真要解决冲突，必须换用 On-Prem Server
Navicat 17 的 On-Prem Server 才具备真正的冲突应对能力，但它和 Navicat Cloud 完全无关——不部署它，就等于没启用协作底层。
关键行为差异：
- 第二次提交同个对象时，客户端会弹出
Pull → Resolve → Push流程，强制你先拉取最新版再解决差异 - 冲突定位精确到字段级：比如右键表结构选
Compare with Database，能直接标出default值或NOT NULL状态是否被他人修改 - 所有变更带完整上下文：谁、在哪台机器、何时、对哪个对象执行了
Create/Update/Delete
注意：On-Prem Server 默认监听 localhost:8080，首次启动即自动激活；如果你没手动启用它，那 Navicat 17 和 16 在冲突处理上毫无区别。
临时规避冲突的实操底线
在只能用 Navicat Cloud 的现实约束下，靠流程补技术短板：
- 约定“谁建查询谁维护”，禁止跨人修改同一
.nqp文件，改名另存为query_v2.nqp - 所有 SQL 变更必须走 Git 管理：用 Navicat 导出
.sql文件 → 提交到代码仓库 → 通过 PR 评审后再导入 - 禁用
Auto-save connection passwords（菜单File → Options → General），避免密码加密块随项目同步导致意外泄露 - 定期从云端导出
.npz备份，但别指望它能还原某次误覆盖——它只存最后一版
最常被忽略的一点：Navicat Cloud 的“同步完成”图标（云朵打勾）只表示文件上传成功，不代表内容安全、一致或可回滚。它不校验语义，也不验证 SQL 是否还能执行。
