执行 psql、createdb 或应用启动连接PostgreSQL时出现 FATAL: role "name" does not exist，说明客户端提交的登录角色在当前数据库集群里不存在。PostgreSQL每次连接都以某个角色建立会话，角色名不是随便填写的备注字段。
先确认连的是哪一台实例、客户端实际提交了哪个用户名，再决定改连接配置还是创建角色。 看到错误就创建同名超级用户，会把一个配置错误升级成权限风险。
为什么不写用户名也会出现角色名
psql 没有收到 -U 或连接串中的user参数时，会使用当前操作系统用户名作为默认数据库角色。Linux账号叫deploy，而PostgreSQL里没有deploy，就可能出现：
psql: error: FATAL: role "deploy" does not exist先显式指定已有角色和数据库：
psql -h 127.0.0.1 -p 5432 -U app_user -d app_db操作系统用户、PostgreSQL角色和数据库名称是三个不同概念，名称可以相同，但不会自动互相创建。
核对应用最终使用的连接参数
检查应用实际加载的环境变量、配置文件和服务启动参数：
env | grep -E '^(PGHOST|PGPORT|PGUSER|PGDATABASE)='
systemctl cat myapp容器环境还要查看容器内部，而不是只看宿主机：
docker exec APP_CONTAINER sh -lc \
'env | grep -E "^(PGHOST|PGPORT|PGUSER|PGDATABASE)="'连接URL里的特殊字符需要正确编码，变量替换失败也可能让user字段变成旧值。输出配置时必须隐藏密码。
应用日志中的报错角色名才是服务端收到的值，不能只根据某个.env文件推断。
先确认没有连错PostgreSQL实例
同一台服务器可能同时运行系统安装版、Docker容器和托管数据库代理。主机或端口写错时，目标实例里当然找不到预期角色。
使用具备登录权限的管理账号连接后检查：
SELECT current_user, current_database();
SELECT inet_server_addr(), inet_server_port();
SHOW data_directory;托管数据库可能不允许读取全部路径信息，此时结合服务端点、证书和控制台实例标识判断。容器环境核对端口映射和网络别名。
先证明目标实例正确，再修改角色；连错环境时创建角色只会在错误实例留下额外账号。
查看角色是否存在以及能否登录
用管理员角色查询：
SELECT rolname, rolcanlogin, rolsuper, rolcreatedb, rolcreaterole
FROM pg_roles
WHERE rolname = 'app_user';没有返回记录，才表示角色不存在。存在但 rolcanlogin 为false时，错误往往会变成role is not permitted to log in，而不是does not exist。
角色名加双引号创建时会保留大小写，例如 "App_User" 与未加引号的 app_user 不是同一个名称。生产连接账号尽量使用小写字母、数字和下划线，减少大小写与转义问题。
应该改连接配置还是创建新角色
应用本来就应该复用现有账号，只是部署变量写错，那么修正连接配置更合适。应用确实需要独立身份、审计和权限边界时，再创建新角色。
判断时核对部署文档、旧环境配置、密钥管理记录和数据库所有者。不要因为角色名与服务器登录用户名相同，就认定它应该存在。
账号创建应来自明确的权限设计，而不是为了让报错立即消失。
以最小权限创建可登录角色
由具备创建角色权限的管理员执行：
CREATE ROLE app_user LOGIN PASSWORD 'use-a-generated-secret';PostgreSQL官方说明，CREATE ROLE 默认是NOLOGIN，而 CREATE USER 默认包含LOGIN。使用CREATE ROLE时要显式写LOGIN，语义更清楚。
不要在Shell历史或工单截图里暴露真实密码。可以在受控psql会话中设置密码，或通过团队密钥管理流程生成和分发。
普通应用账号不需要SUPERUSER、CREATEDB或CREATEROLE，除非业务有经过评审的明确需求。
授予数据库和Schema所需权限
能登录不代表能访问业务对象。按应用职责授权数据库连接、Schema使用和表权限：
GRANT CONNECT ON DATABASE app_db TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA public TO app_user;序列、自定义Schema和未来新建对象需要单独设计默认权限。不要为了省事直接把应用账号设为数据库所有者或超级用户。
迁移工具账号与在线应用账号也应分开。迁移需要建表、改结构，而在线服务只应拥有运行所需权限。
检查pg_hba.conf与认证方式
角色存在后，连接可能继续遇到密码认证、证书或pg_hba.conf规则问题。查看当前规则文件位置：
SHOW hba_file;修改前先备份，并使用版本对应的工具或查询检查规则。pg_hba.conf按顺序匹配，前面的规则可能先命中。创建角色并不会自动放开远程来源地址。
role does not exist只说明角色解析阶段失败，后续认证和对象权限仍需独立验证。
Docker初始化变量为什么改了却没生效
PostgreSQL官方镜像的初始化变量一般只在数据目录首次初始化时创建用户和数据库。已有数据卷再次启动时，修改环境变量不会自动补建角色。
先确认容器使用的数据卷和数据库是否已初始化：
docker inspect POSTGRES_CONTAINER \
--format '{{json .Mounts}}'
docker logs POSTGRES_CONTAINER --tail 100不要为了让初始化变量重新执行就删除数据卷。正确做法是连接现有实例，按变更流程创建或调整角色。
数据卷里有正式数据时，重建初始化环境属于高风险操作，不能拿它当账号修复方式。
在隔离环境验证连接和权限
使用与应用相同的网络位置、数据库名和用户名执行连接测试，但不要把密码直接写进命令历史。连接后验证身份和最小业务操作：
SELECT current_user, current_database();
SELECT has_schema_privilege(current_user, 'public', 'USAGE');需要复现角色与权限流程时，可以在 萤光云 创建隔离数据库主机，也可以用 LightNode 部署临时节点。只使用测试数据和独立密码，不要复制生产备份与密钥。
修复后的验收标准
重新启动应用或重建连接池后，确认错误日志不再出现role does not exist，并检查服务端会话：
SELECT usename, datname, client_addr, state
FROM pg_stat_activity
WHERE usename = 'app_user';随后验证应用能完成所需读写，却无法执行越权操作。检查连接池数量、失败重试和旧凭据是否已经移除。
合格修复不仅是连接成功，还应证明目标实例正确、角色权限最小、密码受控，并且应用不再使用旧账号。
常见问题
角色不存在和数据库不存在有什么区别？
角色错误发生在登录身份解析阶段；数据库不存在表示目标数据库名错误或尚未创建。两者需要分别核对user和dbname。
能把Linux用户名直接创建成数据库超级用户吗？
不建议。便利不等于安全。应根据用途创建最小权限登录角色，管理员操作使用独立受控账号。
修改容器的POSTGRES_USER后为什么还是报错？
已有数据卷不会重新执行首次初始化。应连接现有集群检查并创建角色，不要删除卷重新初始化。
温馨提示
PostgreSQL角色错误经常来自默认用户名、连错实例或环境变量未加载。先还原真实连接参数，再决定修配置或建角色，最后用最小权限验收，才能避免留下不必要的高权限账号。
