连接PostgreSQL时出现 FATAL: database "xxx" does not exist，说明客户端已经到达目标实例，但请求的数据库名称在该实例中不存在。这与密码错误、端口拒绝或DNS解析失败不是同一类问题。
最常见的误区是只指定用户名而没有指定数据库名，psql会按默认规则选择数据库。
先记录实际连接目标
明确主机、端口、用户和数据库四个参数，不要只看一段被框架隐藏的连接串：
env | grep -E '^PG(HOST|PORT|USER|DATABASE|SERVICE)='
printf '%s\n' "$DATABASE_URL"输出连接串时要遮住密码。同名数据库可能存在于另一台服务器，确认实例身份比直接创建数据库更重要。
为什么省略数据库名会报错
psql和libpq会为缺失参数应用默认值。未指定 -d 或 PGDATABASE 时，默认数据库名往往与数据库用户名相同：
psql -h 127.0.0.1 -p 5432 -U appuser这会尝试连接名为 appuser 的数据库。角色存在并不代表同名数据库也存在，因此身份验证前后都可能看到容易混淆的连接错误。
连接维护库查看数据库清单
改为连接明确存在的维护库，再查询数据库：
psql -h 127.0.0.1 -p 5432 -U postgres -d postgres进入后执行：
SELECT datname, datallowconn FROM pg_database ORDER BY datname;也可以使用 psql -l。不要把template0当作应用连接目标，它默认不接受普通连接。
修正命令和连接字符串
在命令中明确指定数据库：
psql -h db.example.internal -p 5432 -U appuser -d appdbURI形式要把数据库名放在路径部分：
postgresql://appuser@db.example.internal:5432/appdb用户名和密码包含特殊字符时必须按URI规则编码。环境变量、systemd单元、容器Secret和应用配置可能同时定义连接参数，应确认最终生效值。
判断数据库被重命名还是删错了
检查部署记录、备份任务和管理审计，确认目标数据库是否刚被重命名、恢复到新名称或误删。不要看到不存在就立刻执行CREATE DATABASE，否则可能生成一个空库并让应用误写。
若原库被删除，应先停止自动重试写入，核对恢复点、WAL归档和备份完整性，再按既定恢复流程处理。
确实需要时再创建数据库
确认这是全新应用且数据库本来就应新建后，由管理员执行：
CREATE DATABASE appdb OWNER appuser;需要先演练初始化和迁移脚本时，可使用 萤光云 或 LightNode 建立隔离实例。创建数据库后还要运行受版本控制的结构迁移，不能把能连接当作业务可用。
修复后怎样验收
用应用实际账号和明确数据库名重新连接：
psql -h db.example.internal -p 5432 -U appuser -d appdb -c 'select current_database(), current_user;'验收标准是返回的实例、数据库和用户都符合预期，应用迁移版本正确，并且没有误连到空库或测试库。
FAQ
postgres用户存在，为什么postgres数据库也可能不存在？ 角色和数据库是两类独立对象，数据库可以被重命名或删除。
能否把用户名改成现有数据库名？ 不应为了绕过默认值混淆身份。更稳妥的做法是明确填写 -U 与 -d。
温馨提示
修改生产连接串时应同步检查Secret、连接池和部署环境。连接池重建后再验收，旧连接不会自动采用新参数。
