navicat的“viewer”“editor”等角色仅控制客户端界面可见性与操作权限，不干预数据库实际权限；真正细粒度权限必须由mysql/postgresql等数据库通过grant/revoke原生配置。
Navicat 本身不绑定、不传递、也不管理数据库角色——你看到的「Viewer」「Editor」等选项，只是客户端界面的可见性开关，和 MySQL 的 GRANT、PostgreSQL 的 GRANT USAGE ON SCHEMA 完全无关。
Navicat 的“角色”只控制菜单和按钮，不控制 SQL 权限
你在 Navicat Team 里把某人设为「Can manage」，他依然不能执行 DROP TABLE，除非他连接时用的数据库账号本身有该权限；反过来，哪怕你把他设为「Viewer」，只要他本地 Navicat 连接配置里填的是 root 或 postgres 账号，连上就能删库。
- 「Viewer」：禁用右键导出、禁用双击编辑 Query、隐藏「新建连接」按钮，但不影响已保存连接的执行能力
- 「Editor」：允许改 SQL 文本、改连接密码字段，但改完不点「测试连接」或不重启 Navicat，变更不会生效
- 所有这些角色变更后，成员需手动重启 Navicat，或等待最长 15 分钟后台轮询才可能刷新界面
真正绑定数据库角色，必须在数据库里配 GRANT
开发人员 A 只能查 orders 表的 id 和 created_at 字段？开发人员 B 只能写 logs 表？这些规则必须由数据库原生授权机制落地：
- MySQL 8.0+：
GRANT SELECT(id, created_at) ON mydb.orders TO 'dev_a'@'%'，然后FLUSH PRIVILEGES - PostgreSQL：
GRANT USAGE ON SCHEMA public TO dev_b+GRANT INSERT ON TABLE logs TO dev_b，行级需额外建 RLS 策略 - SQL Server：
GRANT SELECT (id, created_at) ON OBJECT::[dbo].[orders] TO [dev_a] - Navicat 内置的「用户向导」只能做库级粗粒度授权（比如整个
mydb可读），细粒度必须关掉向导，手写 SQL 或进「对象权限」标签页操作
常见权限失效，90% 是因为没对齐认证凭据
开发人员连上了 Navicat 却看不到表、执行 SELECT 报错 Access denied，大概率不是 Navicat 没设对，而是底层权限链断了：
- 数据库里建的是
'dev_a'@'192.168.1.%'，但他用的是公司公网 IP 或 Docker 容器内网 IP 连接，匹配不上 host - MySQL 用了
caching_sha2_password插件，但 Navicat 版本低于 15.0.24（旧版不支持），导致认证失败静默降级为拒绝 - PostgreSQL 缺
CONNECT权限，或 schema 上缺USAGE，Navicat 就直接显示空列表，不报错也不提示 - 权限只在测试库配了，UAT/生产环境没同步执行相同
GRANT语句 —— Navicat 不会帮你跨实例复制权限
最易被忽略的一点：Navicat 里的「连接」是独立配置项，每个连接都对应一个数据库账号。你要让开发人员 A 始终以 dev_a 身份操作，就得确保他只用那个预设好账号的连接，而不是自己新建一个填了 root 的连接——后者完全绕过你辛苦配的所有数据库角色。
