Navicat 17 的协作必须启用 On-Prem Server，因其是所有协作能力的唯一运行时环境；未启用时，17 与 16 在协作上基本无区别，协作逻辑从覆盖式同步升级为服务端注册、对象级变更管理和 Pull-Resolve-Push 流程。
Navicat 17 的团队协作不是“比16多几个按钮”，而是彻底换了一套协作底座——On-Prem Server 不是可选插件，是所有协作能力的运行前提；没启用它，17 和 16 在协作上基本没区别。
为什么 Navicat 17 的协作必须启用 On-Prem Server？
Navicat 16 的协作靠 Navicat Cloud 同步文件（如 .nqp 查询），本质是覆盖式上传下载，无冲突检测、无操作追溯。Navicat 17 把协作逻辑下沉到本地部署的 On-Prem Server，所有对象（查询、代码段、BI 工作区、数据字典）都注册在服务端，客户端只做状态同步和权限校验。
这意味着：
-
On-Prem Server启动后自动监听localhost:8080，不依赖 Docker 或反向代理，首次启动即提示启用 - 关闭
On-Prem Server后，右键拖拽共享、Pull-Resolve-Push 流程、实时在线头像等全部失效 -
Navicat Cloud账号和On-Prem Server管理员账号完全隔离，无法单点登录互通
协作流程从“覆盖保存”变成“对象级变更管理”
Navicat 16 中两人同时编辑同一查询，后保存者直接覆盖前者的全部内容，无提示、无日志、无法回滚。Navicat 17 强制走 Pull → Resolve → Push 流程，类似轻量级 Git，但面向数据库对象而非文本文件。
关键变化包括：
- 每次保存触发服务端校验：若对象已被他人修改，弹出锁定提醒，强制拉取最新版再解决冲突
- 变更日志精确到语句级，例如日志里明确记录
ALTER TABLE users ADD COLUMN status VARCHAR(20)是谁、在哪台机器、何时执行的 - 冲突解决聚焦模型本身：右键字段选
Compare with Database，直接显示 nullability 或 default 值差异，不比对 XML 全文
共享方式从“导出再发”变成“拖拽即生效”
Navicat 16 的共享依赖人工操作：导出 SQL、截图、发邮件、丢网盘。Navicat 17 把共享压缩成一次拖拽动作，背后自动完成对象隔离、权限绑定和状态广播。
实操中要注意：
- 把一个查询从
DVD Rental MySQL DB项目拖到On-Prem Server → 查询下，立刻全队可见，无需刷新页面 - 拖入后默认继承项目权限；若需细化控制，必须在
On-Prem Server后台为该对象单独设置角色（Owner/Admin/Member/Guest） -
Guest角色用户界面中复制按钮灰色不可用，且连接生产库的按钮直接禁用，杜绝误操作
同步范围和跨平台一致性大幅提升
Navicat 16 的 Navicat Cloud 只同步连接、查询、模型和虚拟组；Navicat 17 补齐了关键缺口，所有同步对象按项目组织，且跨平台行为一致。
典型表现：
- 代码段、BI 工作区、数据字典原生支持上传/下载，Mac 上建的
订单分析 BI项目，Windows 同事打开就能直接编辑，不会混进其他项目图表 - 固定查询结果支持带注释快照：点工具栏图钉按钮，结果集存为带时间戳的快照，并可附加说明（如
这是促销活动前的用户分布） - 所有同步动作日志落盘在
~/.navicat17/log/sync.log，排查“为什么我改了没同步”时，第一眼就能确认是网络中断还是权限拒绝
真正容易被忽略的是：On-Prem Server 的权限体系是按项目 + 资源类型双重控制的，比如同一用户可在 DVDRental MySQL DB 项目是 Member，在 Analytics PostgreSQL 项目却是 Guest；这种细粒度控制一旦配置错误，协作就卡在“看不见”或“改不了”，而不是报错提示。
