我跟你说，Docker这玩意儿刚火起来那会儿，很多人觉得它就是个装软件的“玩具”，跑跑小项目还行，真上了生产环境就怕掉链子。可这几年下来，谁还敢这么说？尤其是数据库这种“娇贵”的东西，以前谁敢用容器跑？现在Docker装PostgreSQL（就是 PG 数据库）都快成标配了。为啥？因为省事啊。你想想，以前装个 PG，得先捣鼓操作系统、装依赖库、配权限、搞数据目录，折腾半天还容易出错。现在一行命令搞定，连环境隔离都帮你做好了，再也不用担心“在我机器上能跑啊”这种破事儿。
具体怎么装呢？先确保 Docker 已经装好。没有的话就去官网下个 Docker Desktop，Windows 和 macOS 都有，Linux 用户更简单，一条 （或对应的包管理命令）就完事。装好后打开终端，先跑个 看看能否正常输出，能的话说明 Docker 在干活了。接下来就是拉镜像。PG 的官方镜像在 Docker Hub 上，版本号写得很清楚，比如想用最新的 15 版，就敲 。这条命令会把镜像从远程仓库拉到本地，大小几百兆，网速好的话几分钟搞定。你可能会问，“为啥不直接用 16 版？”别急，版本选择有讲究，后面会细说。
镜像拉下来之后，启动容器才是重头戏。最简单的命令是。这条命令干了什么？ 给容器起个名字，方便以后操作； 设置环境变量，这里必须给 PG 设置密码，不然容器启动会报错； 表示后台运行，不占用终端窗口。跑完后，用 看看，如果看到 mypg 的状态是 Up，那恭喜你，PG 已经跑起来了。这时可以用 进去，执行 列出数据库，能显示说明一切正常。
不过，这仅仅是“能用”，离“好用”还差得远。容器一删，数据全丢了，谁受得了？所以必须挂载数据卷。比如。 参数把宿主机的 目录映射到容器里的数据目录，这样即使容器删了，数据仍保存在宿主机上，随时可以挂回来。还有端口映射，默认 PG 监听 5432 端口，容器里也是 5432，你需要用 把宿主机端口映射进去，才能用客户端工具连上去。这一步很多人会忘，结果连不上就开始怀疑人生。
说到版本选择，我得提醒一句：别盲目追新。PG 16 刚出来时，有些扩展插件还没适配，坑不少。我一般推荐用 15 或 14，这些版本更稳定，社区支持也成熟。镜像标签也有讲究，别用 ，它指向最新版，万一官方把默认版本升级了，你之前的脚本可能就炸了。指定具体版本号，比如 ，更稳妥。生产环境里记得查看镜像的 sha256 摘要，确保拉下来的镜像是官方签名的，别被人投了毒。细节看着烦，但真出事时，它们能保命。
配置调优这块儿，很多人图省事直接用默认参数，但 PG 的默认配置是为开发环境准备的，生产环境根本扛不住。比如共享缓冲区（sharedbuffers）默认只有 128 MB，你机器有 32 GB 内存，这不是浪费吗？可以在 命令里加 来调整。workmem 默认 4 MB，做点复杂查询就会爆内存。这些参数可以通过 传进去，或者把自定义的 文件挂载到容器里。我习惯把配置文件和初始化脚本放在同一个目录，然后挂载进去，这样升级时只改配置文件即可，不必重新构建镜像。
安全方面也得唠叨两句。别用 root 用户跑数据库容器，这是大忌。Docker 容器默认是 root，但可以用 指定普通用户 ID，或者创建专门的系统用户来跑。还有网络隔离，别把数据库暴露到公网上，除非你已经配置了 SSL 和严格的访问控制。如果需要对外提供服务，记得在 里加 参数，把数据库放到自定义网络，只让需要的服务容器能够访问。我见过不少案例，因为图方便把数据库端口暴露到 0.0.0.0，结果被扫描到密码直接被盗。
说点实用的。日常维护里，备份和恢复是基本功。可以用 导出数据，恢复时用。但别只靠手动执行，写个 cron 脚本定时备份到远程存储（比如 S3 或 NAS）更靠谱。还有个技巧：用 Docker Compose 编排，把 PG 容器、应用容器、Redis 缓存等写在一个 yml 文件里，一条 全搞定。这样团队其他人拉下来就能跑，开发、测试、生产环境保持一致，省去无数“环境不一致”的扯皮时间。说实话，Docker 加 PG 这套组合拳，只要把数据持久化、配置调优、安全隔离做好，比裸机部署还稳当。别怕踩坑，多试几次，你会爱上这种“一键部署”的爽感。
