PostgreSQL 容器最重要的不是端口能连上，而是初始化边界、数据目录、账号隔离和备份前置。

\n
PostgreSQL 放进 Docker 后，最容易让人误会的一点是：容器可以删了重建，数据库状态也像配置一样会自动跟着变。实际正好相反。数据库容器的生命线在 data 目录里，只要那个目录已经初始化，很多环境变量后面再改都不会重新生效。

我部署 PostgreSQL 时会先把这件事写在维护记录第一行：初始化只发生在空数据目录首次启动。理解这条边界，比记住一堆 Compose 参数更重要。

初始化变量只首次生效

官方镜像里的初始化账号、初始化密码和初始化库名变量，只在数据目录为空时创建初始账号和库。容器已经跑过一次以后，再改 .env，不会自动重命名已有账号，也不会自动改已有库名。很多“我明明改了变量，为什么登录不上”的问题都出在这里。

所以我会把第一次启动当成正式动作：先确认 data 目录是新目录，再确认 .env 变量名和 Compose 引用都展开正确，最后启动容器。若发现初始化错了，测试阶段可以停容器、清空测试 data 目录后重来；正式数据目录不能这么处理，必须按数据库迁移和权限变更来做。

data 目录不要混进缓存

PostgreSQL 的 data 目录不是普通应用缓存。它包含表数据、索引、事务日志和数据库内部状态，不能和临时文件、应用缓存、导出文件混放。我会把它单独放在明确路径，例如 ./data:/var/lib/postgresql/data，备份目录则用另一个路径，例如 ./backup:/backup。

这样做有两个好处。第一，备份策略清楚，data 目录属于高优先级数据，不会被清理脚本误删。第二，磁盘占用好判断，数据库增长、备份增长、应用缓存增长不会混在一个目录里。数据库目录一旦出问题，排查要的是确定性，不是到处翻文件。

应用账号要隔离

家庭服务器规模小，也不代表所有应用都该共用管理员账号。我的习惯是给每个应用单独建库、单独建账号，只授予它需要的权限。这样一个应用配置泄露或写错迁移脚本时，不会顺手影响其他库。

管理员账号只用于维护动作，应用连接串里不要长期使用它。账号命名也要能看懂，例如 nextcloud_app、notes_app，比一堆 user1、app 更容易在日志里定位来源。密码照样进密码库，不写在文章或截图里。

健康检查从 pg_isready 开始

页面连不上数据库时，我不会先猜网络。先在容器侧确认数据库是否接受连接：

docker compose config
docker compose ps
docker exec db pg_isready -U app -d appdb
docker inspect db --format '{{json .Mounts}}'
docker compose logs --tail=160 db

pg_isready 只能说明服务可达，不代表账号权限完全正确，但它能把问题先分成“数据库没起来”和“应用连不上”。如果容器健康，下一步再看应用所在网络、连接主机名、库名、账号和密码。排查要一层层来，不要把所有错误都归到 PostgreSQL 本身。

备份要在正式使用前准备

数据库一旦承载应用，就不能等出问题才想备份。我的最低要求是：上线前能导出一次，能把导出文件放到备份目录，能在临时库里恢复。哪怕数据还很少，也要把流程跑通。否则等应用已经有真实数据，再补备份，往往会因为权限、路径或账号问题卡住。

主版本升级也要提前规划。PostgreSQL 的大版本数据目录不保证直接兼容，不能简单把镜像从 15 改到 16 就期望一切正常。升级前先做逻辑导出，再在临时容器里恢复，应用能启动并读写后，再安排正式维护窗口。

备份前置还包括权限前置。导出账号能不能访问目标库，备份目录在容器里是不是可写，宿主机备份目录会不会被清理任务误删，这些都要在第一天确认。数据库备份不是额外装饰，而是部署清单的一部分。

我还会保留一份最小连接说明：应用使用哪个服务名、哪个库名、哪个普通账号，以及遇到连接失败时先跑哪条检查命令。以后换人维护或隔几个月再看，能少很多猜测。

我对 PostgreSQL 容器的要求不复杂：初始化边界写清楚，data 目录独立，应用账号隔离，pg_isready 能检查，备份流程先于正式数据。端口能连上只是第一步，真正的稳定来自这些看起来不显眼的前置约束。