navicat 桌面产品原生支持 windows、macos 和 linux 跨平台协作，需统一使用 navicat on-prem server 为后端中枢，且全员须使用 navicat 17 及以上版本并安装对应系统官方包；连接须用局域网 ip，注意路径分隔符、utf-8 编码及本地数据源路径规范，权限由服务端强制控制，ui 呈现略有差异。
navicat 桌面产品原生支持 windows、macos 和 linux，跨平台协作本身没有技术障碍——前提是统一使用 navicat on-prem server 作为后端协同中枢，而非依赖个人本地文件或 navicat cloud（后者在 macos/linux 上部分功能受限，且无法满足企业数据不出域要求）。
确认 Navicat 版本与平台兼容性
不是所有 Navicat 版本都默认启用跨平台协同。必须确保团队全员使用 Navicat Premium 17 或更高版本（含 Navicat for MySQL 17、Navicat for PostgreSQL 17 等对应数据库版），且已安装对应操作系统的官方构建包：
- Windows 用户需运行
Navicat_x64.exe（非旧版 32 位） - macOS 用户必须从官网下载带签名的
.dmg包，系统设置中需允许“来自识别开发者”的应用 - Linux 用户应使用
.deb（Debian/Ubuntu）或.rpm（RHEL/CentOS/Fedora）包，避免通过 Snap 或 Flatpak 安装——后者会因沙盒限制无法访问On-Prem Server的本地 socket 或证书路径 - 各平台客户端登录同一
Navicat On-Prem Server实例时，连接字符串中的主机 IP 必须用实际局域网地址（如192.168.1.100），不能写localhost或127.0.0.1（Mac/Linux 下该地址不指向服务器物理机）
同步对象时注意路径与编码差异
跨平台协作中最易被忽略的是文件路径分隔符和字符编码。Navicat On-Prem Server 内部以 UTF-8 存储所有元数据，但本地客户端行为受 OS 影响：
- Windows 客户端保存的查询或代码段若含中文路径（如
C:\项目\报表.sql），在 macOS/Linux 客户端打开时不会报错，但「另存为」时默认路径会变成/Users/xxx/项目/报表.sql——此时文件内容一致，但本地路径已重映射 - BI 工作区或模型工作区中嵌入的本地数据源路径（如 Excel 文件）不会自动转换，需在共享前统一改为相对路径或网络路径（如
smb://server/share/data.xlsx） - Linux 客户端若 locale 设置为
C或POSIX，可能导致 SQL 编辑器中中文注释显示为乱码，需在终端执行export LANG=zh_CN.UTF-8后再启动 Navicat
角色权限在多平台下保持一致，但 UI 呈现有细微差别
Navicat On-Prem Server 的权限模型是服务端强制的，与客户端 OS 无关。但不同平台的 UI 对权限的反馈方式不同：
- Windows/macOS 客户端：当用户角色为
guest时，右键菜单中「编辑」、「删除」选项直接置灰不可点 - Linux 客户端：同样角色下，这些菜单项仍可见，但点击后弹出提示
"You do not have permission to modify this object"——这是 Qt 框架在 Linux 下对禁用状态渲染的差异，不影响实际权限控制 - 所有平台下，
activity log记录完全一致，包括操作时间（UTC）、执行人、对象 ID 和动作类型，可用于审计比对 - 若某成员在 macOS 上创建了一个带特殊符号的虚拟组名（如
dev-✨-team），Windows 客户端可能显示为方块，但不影响功能；建议团队约定仅使用 ASCII 字符命名项目与对象
真正卡住跨平台协作的往往不是 Navicat 本身，而是团队没提前约定好对象存储位置和命名规范——比如有人把 BI 工作区存在本地 Downloads 目录，有人存在 Documents，On-Prem Server 只同步引用关系，不搬运原始数据文件。这类问题在三平台混用时暴露得最快，也最难追溯。
