Navicat的“Viewer”“Editor”等角色仅控制客户端内资源可见性与编辑权限，不干预数据库实际操作权限；真正数据权限必须由MySQL/PostgreSQL等数据库原生RBAC机制通过GRANT/REVOKE等命令配置。
navicat 本身不定义“项目成员角色”，它没有 rbac（基于角色的访问控制）模型；你看到的「viewer」「editor」「can manage」等选项，只是 navicat team 或 navicat cloud 对客户端内资源（连接、查询、模型）的可见性与编辑权限开关，和数据库实际能做什么完全无关。
Navicat Team 的「角色」只控制客户端里能看到/改什么
这些角色不传给数据库，也不影响 SQL 执行结果。哪怕你把某人设为 Viewer，只要他本地 Navicat 连接配置里填的是 root 账号，双击连上后照样能 DROP TABLE。
- 「Viewer」：能查看项目里的 Connection、Query、Model，但不能编辑或导出结果（除非项目级开启
Allow exporting result sets） - 「Editor」：可编辑 Query 内容、修改 Connection 配置（如密码、端口），但不能增删项目成员或重命名项目
- 「Can manage」：可管理成员、重命名项目、关闭项目，但依然不能代替你在 MySQL 里执行
GRANT
关键点：所有这些操作，都只在 Navicat 客户端界面生效。权限变更后，成员必须重启 Navicat 或等待最长 15 分钟后台轮询，才可能刷新。
真正起作用的权限在数据库里，不是 Navicat 里
你想让开发只能查 orders 表的 id 和 created_at 字段？想让报表用户不能删 users 表？这些必须靠数据库原生授权机制：
- MySQL 8.0+：用
GRANT SELECT(id, created_at) ON mydb.orders TO 'dev'@'%'，再加FLUSH PRIVILEGES - PostgreSQL：先
GRANT USAGE ON SCHEMA public TO dev，再GRANT SELECT ON TABLE users TO dev；行级控制得配 RLS 策略 - SQL Server：用
GRANT SELECT ON OBJECT::[dbo].[orders] TO [dev_user]，列级需GRANT SELECT (id, created_at) ON ...
Navicat 的「用户向导」只支持库级粗粒度授权；细粒度必须关掉向导，手写 SQL 或用「对象权限」标签页（仅部分版本支持，且 MySQL 列级权限需 8.0+）。
常见权限失效的三个真实原因
不是 Navicat 没点对，而是底层权限链断了：
-
Access denied for user 'xxx'@'%'：账号 host 匹配失败（比如 Navicat 填了%，但数据库里只建了'xxx'@'10.20.30.40'），或认证插件不兼容（如 caching_sha2_password 未被客户端支持） - 连上了却看不到库/表：MySQL 缺
SHOW DATABASES权限，或 PostgreSQL 缺CONNECT+USAGE ON SCHEMA，Navicat 会直接显示为空列表 - 测试库配好了，上线就报错：Navicat 不同步权限到其他实例；UAT/生产环境的
mysql.user表是独立的，必须手动或脚本重复执行GRANT
导出数据失败，往往卡在两个地方
你以为开了「Viewer」就能导出？其实要过两道关：
- Query 文件本身要有
Execute权限（否则点运行都报错） - 项目设置 →
Permissions → Advanced Settings必须开启Allow exporting result sets（默认关闭，仅 Owner 可开）
即使这两项都满足，导出路径仍由成员本地 Navicat 设置决定，Team 端无法干预——也就是说，你没法强制他导出到服务器或指定目录。
最常被忽略的一点：Navicat Team / Cloud 的权限变更，不会触发数据库权限刷新。你改完「Viewer」，他本地 Navicat 还在用旧缓存；你执行完 GRANT，没 FLUSH PRIVILEGES（MySQL）或没 REASSIGN OWNED（PostgreSQL），权限也不会立刻生效。两者完全独立，必须分别确认。
