navicat on-prem server 不管理数据库用户权限，仅实现协作层权限隔离，通过项目角色（owner/admin/member/viewer）控制用户对连接、查询等资源的可见性与操作权，连接凭据默认不共享且不可跨客户端强制同步。
Navicat On-Prem Server 本身不直接管理数据库用户权限（如 GRANT / REVOKE），它做的是「协作层权限隔离」——即控制谁能在 Navicat 桌面端看到、编辑、共享哪些连接、查询、模型或 BI 工作区。真正的数据库对象级权限（比如某用户能否 SELECT 表 users）仍由 MySQL/MariaDB/PostgreSQL 自身的权限系统执行。
Navicat On-Prem Server 的项目角色权限怎么配？
项目是权限隔离的基本单位。你不能按数据库名或服务器 IP 分配权限，只能在「项目」维度设置角色：
- 创建项目后，点击右上角「成员」→「邀请」添加用户，必须为每人指定一个角色：Owner / Admin / Member / Viewer
-
Owner可删除项目、修改所有设置；Admin可管理成员和文件但不能删项目；Member能创建/编辑/删除自己上传的文件；Viewer只读，且默认看不到「连接设置」这类敏感内容（除非显式共享） - 角色权限不可自定义，也不能叠加——比如不能给某人同时赋予
Member和Viewer权限 - 注意：
Viewer角色无法看到他人保存的SQL 查询或聚合管道，即使这些内容在同一个项目里
为什么「连接设置」默认不共享？
Navicat On-Prem Server 把连接凭据视为最高敏感项，做了硬性隔离：
- 每个用户在本地 Navicat 中配置的连接（含密码、SSH 隧道、SSL 设置等）默认仅自己可见
- 若需共享连接，必须手动右键该连接 →「共享至项目」→ 选择目标项目，并勾选「包含密码」（否则被共享方需另行输入密码）
- 即使你是项目
Owner，也无法直接查看其他成员未主动共享的连接配置；系统日志中也**不会记录明文密码**，只记录「连接已共享」动作 - 这个设计意味着：不能靠 On-Prem Server 实现跨团队的统一连接池管理，它只解决「协作可见性」，不替代数据库账号体系
如何避免团队成员误删生产环境连接？
误操作风险集中在「连接」和「查询」两类资源上，关键防护点如下：
- 禁用自动同步：在 Navicat 桌面端，进入「工具」→「选项」→「常规」→ 取消勾选「自动同步连接设置」，防止本地误删立刻同步到服务器
- 用只读连接模板：为生产库创建连接时，在「高级」页签勾选「只读模式」，该设置会随连接一同同步到 On-Prem Server，所有协作者执行查询时都会受此限制
- 启用活动日志审计：On-Prem Server 后台的
activity_log表会记录每条「删除连接」「覆盖查询」操作，含操作人、时间、IP，但**不记录 SQL 内容本身**——所以敏感操作仍需数据库层开启general_log或审计插件 - 不要把 DBA 账号的连接共享给开发成员：哪怕设为
Viewer，一旦连接被共享且含密码，对方就能直连生产库执行任意命令
真正需要隔离数据库访问权限时，必须回到 MySQL 的 mysql.user 表或 PostgreSQL 的 pg_roles 做管控；On-Prem Server 的权限模型只管「谁能看到 Navicat 里的哪些按钮和文件」，它不是数据库防火墙，也不替代 GRANT 语句。最容易被忽略的一点是：成员退出项目后，其本地 Navicat 仍保留已同步的连接和查询副本——On-Prem Server 不会远程擦除客户端数据。
