PostgreSQL 角色权限怎么分？数据库、schema 与表授权
PostgreSQL 权限需要分别考虑连接数据库、访问 schema 和操作对象。账号能够登录，并不代表它能查询每张表；表权限正确，也可能因 schema 或序列权限不足而失败。本文以 PostgreSQL 16 为例，示例角色和 schema 必须按真实环境替换。
先区分登录身份与对象所有者
角色可以用于登录，也可以作为权限分组。应用运行身份、迁移身份和对象所有者应有清楚安排，避免日常请求一直使用超级用户。让运行账号拥有表，可能赋予它超出普通数据读写的控制能力。
已有系统不要直接改变所有者或撤销公共权限。先列出角色成员关系、连接方式及后台任务依赖，再决定如何拆分。角色概念与管理范围可参考PostgreSQL 数据库角色说明。
分别给 schema、表和序列授权
假设应用已经能按受控规则连接目标数据库，运行角色为 app_runtime，业务对象在 app schema。由合法对象所有者或管理员在正确数据库中按需授权：
GRANT USAGE ON SCHEMA app TO app_runtime;
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA app TO app_runtime;
GRANT USAGE, SELECT
ON ALL SEQUENCES IN SCHEMA app TO app_runtime;
这些只是常见运行需求，不包含任意建表或管理角色的能力。序列权限需要结合应用使用方式核对，不能因为某次插入失败就授予整个数据库的所有权限。数据库连接权限、schema 使用权限与对象权限的关系见PostgreSQL GRANT 文档。
公共 schema 的默认权限可能因数据库创建版本、升级历史和模板而不同，应查看现状。不要假定所有 PostgreSQL 16 数据库都来自同一套全新默认值。
新建对象还需要默认授权安排
对现有表执行授权，并不自动覆盖以后创建的表。应针对实际创建对象的角色设置默认权限，例如由 app_migrator 创建业务表时：
ALTER DEFAULT PRIVILEGES FOR ROLE app_migrator IN SCHEMA app
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_runtime;
如果应用还会创建序列，应按需要安排对应默认权限。默认授权取决于创建对象时的角色，不会因为名称相近就自动作用到另一个迁移账号，也不会追溯修改现有对象。默认权限官方说明
迁移工具使用 SET ROLE 或不同部署账号时，要确认最终谁是创建者。否则可能出现旧表正常、新版本刚创建的表却无法访问的间歇性权限故障。
用应用真实身份验证
从应用实际连接方式检查当前用户、会话用户与搜索路径，再测试必要只读操作。不要只在超级用户会话里执行查询，因为它可能绕过了应用面临的限制。
验证一条受控写入流程和相关序列行为，同时确认应用不能访问无关业务数据。搜索路径中如果包含不可信用户可创建对象的 schema，也需要按实际安全边界调整，不能只解决眼前的“表找不到”。
测试拒绝行为时使用专门测试对象，不要对生产表执行破坏性语句。日志与授权导出应妥善保存，分享时去除连接凭据与业务敏感信息。
权限回退应针对明确变更
变更前保存角色成员关系、对象所有者和授权清单。撤回多余权限前检查定时任务、报表和迁移流程，避免网站首页正常而夜间任务失败。
出现问题时恢复刚才撤掉的必要权限，并继续确认真正需求，不应直接把运行账号提升成超级用户。最终将当前对象授权、未来对象授权和创建者安排一并交接，才能让后续数据库发布保持一致。