最近帮一位同事排查数据库服务器，连上去一看，他居然把 Postgres 装在 Windows 上跑生产，还抱怨“启动好慢、连接一多就卡”。我当场就建议他换 Linux 环境重装一版，结果他又问我要一份详细的安装步骤。这题我熟，因为光是 PostgreSQL 安装，这几年我在各种机器上折腾过不下几十次，从编译到二进制包，再到 Docker，踩坑无数，也攒了不少经验。这次干脆把“基础之安装”这件事一次讲清楚，覆盖源码编译、发行版仓库、Docker、Windows 安装器这几种主流路子，并重点拆解 Linux 源码安装的全过程，从依赖准备、参数配置到数据库初始化，每步都说清“为什么这么做”，最后集中整理安装阶段最常遇到的报错和排查方法，给新手朋友一份可以照着做、碰到问题也能翻答案的实战笔记。
安装 PostgreSQL 看起来简单，无非下载、编译、初始化、启动，但真正操作起来，版本选择、目录规划、配置文件这些细节会直接影响后续的使用体验。本文适合刚接触 Postgres 的新手，也适合正在服务器上部署、想搞懂每个步骤原理的运维和开发者来看，读完你可以独立完成一次干净、合规、可维护的安装。
1. 安装前必须想清楚的几件事
1.1 三个问题：装什么、装哪里、怎么装
我见过很多人直接apt install postgresql，然后什么都不管，最后数据目录丢在系统盘，版本也跟着系统走，后面升级、迁移都麻烦。所以安装前先花三分钟回答三个问题。
第一个问题是“装哪个版本”。PostgreSQL 每年发布一个大版本，官方维护周期一般是五年左右。如果你是新项目，选当前最新的稳定大版本是最省心的选择，比如目前的 16 或更高版本；如果是要兼容老项目的现有库，那就选与生产环境一致的大版本，避免版本差异引入行为变化。这里有个小技巧：大版本升级不是原地无缝的，通常要借助pg_upgrade或 dump 恢复，所以选版本时别太激进，也别太保守，跟着官方支持节奏走即可。
第二个问题是“装在哪里”。这里包含两层，一是操作系统，二是在系统里的目录位置。PostgreSQL 对 Linux 的支持最好，Windows 虽然可用，但建议只用于开发测试，不要跑重要生产。目录方面，一定要把“程序目录”和“数据目录”分开，数据目录（也就是 PGDATA）建议放在独立的数据盘上，权限收紧，沉淀的业务数据不会因为系统盘重装或空间不足而受到影响。
第三个问题是“安装方式选哪种”。不同方式有各自的适用场景，下面开一张表对比。
1.2 安装方式横向对比
| 安装方式 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| Linux 发行版仓库（apt/yum） | 命令简单、自动处理依赖、有系统服务脚本 | 版本可能偏旧、目录分散、定制性弱 | 个人开发环境、不追求高度定制的生产环境 |
| 源码编译安装 | 版本可由自己指定、目录集中可控、编译参数可定制 | 步骤多、耗时较长、需要手动管理服务 | 生产环境、需要定制功能的场景 |
| Docker 容器部署 | 一键启动、隔离环境、方便迁移 | 数据持久化需要挂载卷、网络配置需要理解容器网络 | 微服务环境、快速测试、CI/CD |
| Windows 安装器 | 图形化界面、引导式安装、自带初始化 | 仅限 Windows、生产环境不推荐 | Windows 本地开发、学习练习 |
在我个人看来，如果你要在服务器上认真跑数据库，源码编译或官方提供的可重定位二进制包是首选，不是因为它“显得专业”，而是因为目录结构可控，参数可以按需调整，后续做备份、迁移、升级都更顺手。本文会把源码编译这条最完整的路线讲透，其他方式作为补充方案也会给到步骤。
提示：如果你的机器内存很小，预算紧张，建议安装前看一眼官方文档对内存的基础要求。数据库这玩意，内存小确实能跑，但连接一多立刻露馅，别指望靠调参数救回来。
2. 环境准备三步走：依赖、用户、目录
2.1 装好编译依赖，少走弯路
源码编译前先确认系统里有没有需要的库和工具。PostgreSQL 编译最基础的依赖包括编译器（gcc、make）、系统头文件，以及几个可选但推荐安装的库：readline（命令行历史功能）、zlib（压缩支持）、openssl（SSL 连接）、libxml2（XML 解析）、gettext（多语言支持）。这些库缺失时不一定立刻失败，但要么功能受限，要么在 configure 阶段直接报错。
在 Ubuntu/Debian 系的系统上，可以这样一次性装齐：
sudo apt update sudo apt install -y build-essential libreadline-dev zlib1g-dev \ libssl-dev libxml2-dev libgettextpo-dev flex bison在 CentOS/Rocky 这类 Red Hat 系系统上，需要用 yum：
sudo yum install -y readline-devel zlib-devel openssl-devel \ libxml2-devel gettext-devel flex bison gcc make这里有个很容易被忽视的点：编译库和运行库是两份东西。只装运行库（比如 libreadline 本体）不装-dev或-devel开发包，configure 一样找不到头文件。新手报错“readline library not found”时，八成不是真的没有 readline，而是没装开发包。
2.2 创建专用用户：让数据库住在自己的房间里
PostgreSQL 极度不建议直接用 root 运行。原因很简单，数据库进程一旦被利用，如果以 root 权限运行，攻击者就有可能拿到系统最高权限；而且 root 的所有者是系统管理员，数据库产生的文件、日志混在一起也不安全。所以一定要创建一个专用系统用户。
sudo useradd -m postgres sudo passwd postgres这个用户不需要有登录 shell 之外的特殊权限，甚至可以不设密码。很多配置文档直接sudo su - postgres切换过去使用，密码就省了。我在生产环境中一般还会顺手把postgres用户的家目录放到/home/postgres，方便放备份脚本和归档文件。
2.3 目录规划：程序目录与数据目录分开
这是我从早期踩坑总结出来的铁律：程序目录、数据目录、日志目录、归档目录，至少数据目录要单独设置。
假设我们把 PostgreSQL 安装到/usr/local/pgsql，数据目录放在独立的/data/pgsql，那么创建目录并授权的方式如下：
sudo mkdir -p /usr/local/pgsql sudo mkdir -p /data/pgsql sudo chown -R postgres:postgres /usr/local/pgsql sudo chown -R postgres:postgres /data/pgsql为什么单独强调 chown？后面用initdb初始化时，当前用户必须是数据目录和程序目录的属主，如果不是 root 创建的默认属主，会直接报权限错误。我见过有人反手chmod 777解决问题，那是非常不可取的，相当于把数据库的保险柜门卸了，改成玻璃门。
3. 手把手源码编译安装：configure、make、initdb 全流程
3.1 下载源码并解压
源码包可以从 PostgreSQL 官网指定下载地址获取，也可以到国内镜像下载。这里以一篇虚构的最新稳定版本为例：
# 切换到 postgres 用户 sudo su - postgres cd /home/postgres wget https://example.com/postgresql-16.4.tar.bz2 tar -xjf postgresql-16.4.tar.bz2 cd postgresql-16.4实际使用时，最好核对一下下载文件的校验和，防止文件不完整或下载过程中被篡改。之前我在某镜像站下载过一次，包不大但编译出来老出诡异问题，后来才发现是压缩包被截断了。校验这一步不是浪费时间，十分钟的编译不值得用一次随机失败去赌。
3.2 configure 参数：每个选项都想清楚再填
configure 是编译安装里信息量最大的一步，它决定了一大批编译期行为。这里列几个最常用的参数及含义：
| 参数 | 作用 | 我的建议 |
|---|---|---|
--prefix=/usr/local/pgsql | 指定程序安装位置 | 推荐，集中管理 |
--with-pgport=5432 | 设置默认端口 | 不用改，除非 5432 被占用 |
--with-openssl | 启用 SSL 支持 | 推荐，生产需要加密连接 |
--with-libxml | 支持 XML 数据 | 如无需要可不加 |
--with-perl/--with-python | 支持 PL/Perl、PL/Python 存储过程语言 | 按业务需要 |
--enable-debug | 保留调试信息 | 生产不加，源码学习可加 |
--with-data-checksums | 启用数据页校验（重要！） | 强烈推荐，见下方解释 |
--with-data-checksums这个参数是在initdb阶段生效的，也可以在初始化时加-k开启。它的作用是给每个数据页计算校验和，一旦磁盘出现损坏或内存问题，PostgreSQL 能提前发现并报错，而不是默默读出污染数据。这个能力一旦开启，后续如果没开想要补开，必须停机整库走走一遍，相当麻烦。我建议从一开始就带上它，虽然会稍微增加 CPU 开销，但对数据安全完全是值得的。
一个完整的 configure 命令大致是：
./configure --prefix=/usr/local/pgsql \ --with-pgport=5432 \ --with-openssl \ --with-libxml \ --with-perl \ --with-python \ --with-data-checksums如果你对某些选项没把握，先跑一遍./configure --help查看说明，再决定加不加。configure 阶段如果报缺少库，直接看错误信息去装对应的-dev包即可，不用重新解压源码。
3.3 编译安装：make 的小知识
配置完成后，开始编译：
make -j4-j4表示同时用 4 个并行任务，如果你的机器核数是 8 或 16，可以写成-j8、-j16，能明显缩短编译时间。但也不要贪心，把核数全占满会导致机器卡到连 ssh 都反应慢，尤其是还在跑业务的机器。我一般保守一点，用物理核数的一半左右。
编译完成后，执行安装：
make install这时候如果看到类似 “PostgreSQL installation complete.” 的信息，就说明编译安装成功了。装完后，/usr/local/pgsql/bin下会有一堆可执行文件，包括后面要用到的initdb、psql、pg_ctl、pg_dump等等。
3.4 环境变量配置：让命令随处可用
安装完程序后，需要把 bin 目录加入 PATH，同时设置 PGDATA 环境变量，这样日常操作会方便很多。在postgres用户的.bashrc或.bash_profile里加上：
export PATH=/usr/local/pgsql/bin:$PATH export PGDATA=/data/pgsql加完后执行source ~/.bashrc生效。这里解释一下为什么单独设置PGDATA：PostgreSQL 一堆命令都默认从环境变量里读数据目录，比如pg_ctl start时不带-D参数，它就会去找$PGDATA。设好之后，日常启停就少打好多字，也降低搞错目录的风险。
3.5 初始化数据目录：initdb 是关键动作
数据库程序装好了，不等于数据库就存在了，还需要用initdb在目标目录中初始化一套初始数据。这一步经常被新手漏掉，或者不知道初始化参数怎么选。
sudo su - postgres initdb -D /data/pgsql \ --encoding=UTF8 \ --locale=en_US.UTF-8 \ --data-checksums这里三个参数值得解释：
--encoding=UTF8：指定数据库集群的默认编码。既然业务数据大多数情况要存中文，UTF8 是首选，否则可能出现乱码或后续迁移编码转换的麻烦。--locale=en_US.UTF-8：指定排序规则和语言环境。不要小看这个参数，它影响字符串的排序结果和大小写比较行为。如果选错了 locale，后面发现 order by 结果不对，改起来相当麻烦。--data-checksums：对应前面 configure 阶段的选项，明确开启数据页校验。
如果 initdb 进程执行成功，会看到类似 “Success. You can now start the database server” 的输出，此时/data/pgsql下生成了PG_VERSION、postgresql.conf、pg_hba.conf、base/等结构和文件。
3.6 修改核心配置：postgresql.conf 与 pg_hba.conf
初始化完毕后，在启动之前，通常会先动两个文件：postgresql.conf和pg_hba.conf。
先看postgresql.conf里几个关键参数：
listen_addresses = 'localhost' port = 5432 max_connections = 100 shared_buffers = 128MBlisten_addresses：决定数据库监听哪些网络接口。默认localhost只允许本机连接，这在测试环境没问题；如果允许其他机器连接，要改成'*'或具体 IP。注意这里改了之后，防火墙和安全组也要同步放行，否则看起来“配置了但连不上”。max_connections：默认 100，对大部分中小型应用够用。它跟shared_buffers、系统内存互相制约，不是想调多高就调多高，每个连接都要占内存。shared_buffers：这是共享内存池大小，默认 128MB 比较保守。经验公式大概是内存的 1/4，比如 16GB 内存的机器可以设 4GB，但不能超过系统可用内存。改完要重启生效。
再来看pg_hba.conf，这是客户端认证控制文件，决定哪些 IP 用什么方式登录。我经常见到“连接被拒绝”“密码认证失败”的问题，一半以上是这里的规则写错了或顺序不对。
一个常见的基础配置：
# 类型 数据库 用户 地址 方法 local all all peer host all all 127.0.0.1/32 scram-sha-256 host all all 0.0.0.0/0 scram-sha-256这里说几点：
- 第一行
local控制本机 Unix socket 连接，一般用peer认证，意思是操作系统用户与数据库用户名一致就放行。 - 第二行
host控制本机 TCP/IP 连接，scram-sha-256比md5安全得多，新版本默认支持，推荐使用。 - 第三行是允许任意地址连接，生产环境务必不要这样裸奔，应该改成具体网段，比如
10.10.0.0/24。
pg_hba.conf的规则是自上而下匹配的，匹配到第一条就不再往下看，所以更严格的规则放在前面。比如想拒绝某个 IP 同时允许整个网段，就要把拒绝那条放在允许那条前面，顺序反了等于规则失效。
3.7 启动、停止与状态查看
配置改完后，启动服务：
pg_ctl -D /data/pgsql start启动成功后，可以用pg_isready检查端口是否就绪：
pg_isready -h 127.0.0.1 -p 5432如果返回 “accepting connections”，说明数据库已经正常监听。
停止服务用：
pg_ctl -D /data/pgsql stop-D如果已经在环境变量里设了PGDATA，可以省掉。但我实际经验是：在脚本多、切换环境多的情况下，显式写-D更稳妥，不容易出现脚本引用了错误目录的情况。
3.8 注册 systemd 服务：让数据库开机自启
源码编译安装不会自动生成系统服务，这意味着重启机器之后数据库不会自动起来。我在生产环境上一定会写一个 systemd unit 文件，放到/etc/systemd/system/postgresql.service：
[Unit] Description=PostgreSQL database server After=network.target [Service] User=postgres Type=forking ExecStart=/usr/local/pgsql/bin/pg_ctl -D /data/pgsql start ExecStop=/usr/local/pgsql/bin/pg_ctl -D /data/pgsql stop ExecReload=/usr/local/pgsql/bin/pg_ctl -D /data/pgsql reload PIDFile=/data/pgsql/postmaster.pid [Install] WantedBy=multi-user.target然后依次执行：
sudo systemctl daemon-reload sudo systemctl enable postgresql sudo systemctl start postgresql注意区分enable和start，只start不enable，重启后还是会停。很多人在源码安装后忘记这步，重启机器就一脸蒙地问“数据库怎么没了”。
4. 几种替代安装路径：仓库包、Docker、Windows
4.1 系统仓库安装：三分钟跑起来
如果你不是要深度定制，只是本地测试或开发，用系统包管理器是最快的。在 Ubuntu 上：
sudo apt install postgresql postgresql-contrib安装完成后，系统会自动创建postgres用户，并初始化一个数据目录，还会自动注册 systemd 服务。直接运行：
sudo systemctl status postgresql就能看到服务状态。此时连接数据库：
sudo su - postgres psql这种安装方式最大优点是省事，缺点是比较难定制初始参数，而且各个发行版的 PostgreSQL 版本有差异。我这里提醒一下，仓库包的安装时间长了，apt upgrade 的时候可能直接给你的 PostgreSQL 做大版本升级，这是有风险的操作，生产环境要谨慎对待，别让包管理器在你不经意间升级了数据库。
4.2 Docker 部署：一条命令包含全套环境
Docker 方式在开发、测试、以及容器化生产环境里越来越常见。拉取镜像并启动：
docker pull postgres:16 docker run -d \ --name pg16 \ -e POSTGRES_PASSWORD=mypassword \ -p 5432:5432 \ -v pgdata:/var/lib/postgresql/data \ postgres:16这里-v pgdata:/var/lib/postgresql/data是数据持久化的关键。如果不挂载卷，容器一删，数据就全没了，前面跑的东西全部归零。POSTGRES_PASSWORD是镜像初始化时给超级用户设置的密码，首次启动时必须给，否则容器起不来。
Docker 方式最大的优势是环境一致性，本机和服务器可以做到一模一样。但也有一个新坑：容器里的 Postgres 默认只监听容器内的5432，-p映射只解决主机到容器的转发，如果还需要跨主机访问，还得配合网络插件、防火墙规则等，复杂度比裸机部署反而高一些。所以我个人的习惯是：测试和 CI 用容器，长期跑数据的库还是放在裸机上，管理起来直接明了。
4.3 Windows 安装器：给不想碰 Linux 的人
Windows 下的官方安装器实际上是一个图形化向导，双击运行后一路点 Next，选数据目录、设超级用户密码、选端口，最后点击完成，服务就自动装好并启动了。整个过程大约五分钟，几乎不会有意外。
但我也要说句实话，PostgreSQL 在 Windows 上的整体体验，比 Linux 上差一大截：文件句柄限制、内存分配模型、路径大小写敏感度，各种环境差异会在高负载下露出马脚。Windows 装一个做个人开发、做本地测试完全没问题，但别把它作为核心生产环境。真要跑线上，老老实实上 Linux 服务器才是正路。
5. 安装成功后的验证与基础保养
5.1 验证安装：连接并执行第一句 SQL
启动完成后，花两分钟做一次基本体检。先看进程：
ps -ef | grep postgres正常情况下会看到postmaster（主进程）、checkpointer、background writer、walwriter、autovacuum launcher等一堆后台进程，这说明数据库的各个子系统都正常拉起。
然后连库执行一句 SQL：
psql -h 127.0.0.1 -U postgres -d postgres # 执行 SELECT version();如果返回 PostgreSQL 版本信息，说明客户端连接链路正常，服务端版本正常，库也能正常访问。此时可以建一个测试表插入几条数据，再查出来，确认读写路径没有问题。
5.2 设置超级用户口令
initdb 初始化时不会设置密码，此时本地 peer 认证可以登录postgres用户，但远程连接还不行。建议立刻给超级用户设置密码：
ALTER USER postgres WITH PASSWORD '强密码';设置后，记得重启或 reload 使pg_hba.conf中新的认证方式生效。这里再强调一次：不要在生产库上用trust认证，那等于公开裸奔；也不要继续用 md5，新的scram-sha-256在防抓包破解方面更可靠，新版本默认就是这个。
5.3 配置归档与基础备份习惯
安装完成后不要就以为万事大吉。下一步就是开启 WAL 归档和定期备份，这是数据库跑上生产前就该做好的功课。至少要在postgresql.conf里开启：
wal_level = replica archive_mode = on archive_command = 'cp %p /data/pgsql_archive/%f' max_wal_senders = 10归档目录要提前建好并授权给 postgres 用户，否则归档命令执行会失败，导致 WAL 不断堆积。备份策略建议采用“全量基础备份 + WAL 归档”的组合：定期跑全量pg_basebackup，平时靠归档日志滚动恢复，这样即使磁盘损坏，也能把数据恢复到最近的时间点。
5.4 修改监听与防火墙：让数据库可以被业务机器连接
如果你的数据库需要接受来自其他服务器的连接，除了前面改listen_addresses和pg_hba.conf之外，防火墙很可能是一堵隐形的墙。Ubuntu 上如果开了 ufw，需要放行端口：
sudo ufw allow 5432/tcpCentOS 上用 firewalld 的话：
sudo firewall-cmd --permanent --add-port=5432/tcp sudo firewall-cmd --reload以及云服务器安全组也需要放行对应入方向规则。这一步排查起来常让人抓狂：明明数据库监听正常、认证配置正确，就是连不上，最后发现是防火墙规则没放行。建议安装完成后直接用远程机器测试一次连接，别等到业务上线才发现连不通。
6. 常见报错排查实录
6.1 编译阶段报错：缺库、缺依赖、configure 失败
| 报错信息 | 原因 | 解决方式 |
|---|---|---|
configure: error: readline library not found | 缺 readline 开发包 | 安装 libreadline-dev / readline-devel |
configure: error: zlib library not found | 缺 zlib 开发包 | 安装 zlib1g-dev / zlib-devel |
make: command not found | 没装编译工具链 | 安装 build-essential / gcc make |
flex: command not found或bison: command not found | 缺词法/语法分析器 | 安装 flex 和 bison |
这类问题通常看错误提示就明白了，装好对应包重跑 configure。这里建议依赖包一次装全，避免反复 configure 浪费时间。我常用的判断口诀是：configure 阶段报错，先补-dev/-devel；make 阶段报错，多数还是缺头文件或编译工具，不是代码的问题。
6.2 initdb 阶段报错：权限、编码、目录
| 报错信息 | 原因 | 解决方式 |
|---|---|---|
initdb: error: could not create directory ... Permission denied | 当前用户无权操作目标目录 | 确认使用 postgres 用户，且目录属主正确 |
initdb: error: invalid locale name | locale 参数写错或系统未生成对应 locale | 用locale -a查看已有 locale，或安装对应语言包 |
initdb: error: file system is not allowed as data directory | 数据目录所在文件系统不允许落盘 | 检查挂载选项或换目录 |
这里特别提一下 locale 问题。很多新手在 Debian 系统上发现en_US.UTF-8不存在，因为系统默认只生成了C或POSIX这种最小 locale。解决办法是安装locales包并生成对应 locale，或者直接用initdb --locale=C.UTF-8。另外提醒，集群初始化后 locale 不能随意更改，所以提前想好，避免办完才发现排序行为不符合预期。
6.3 启动阶段报错：端口、目录、权限
| 报错信息 | 原因 | 解决方式 |
|---|---|---|
could not create listen socket for ... Address already in use | 5432 端口被占用 | netstat -tlnp查占用进程，换端口或停掉占用 |
data directory "/data/pgsql" has invalid permissions | 数据目录权限过宽或属主不对 | 数据目录应为 700，属主为 postgres |
postmaster.pid exists ... removing stale pid file | 上次异常退出留下旧 pid | 先确认没有残留进程，再手动删 pid 文件或用pg_ctl正常启动 |
FATAL: could not open file ... No such file or directory | 数据目录缺失或损坏 | 检查 PGDATA 路径是否正确，必要时从备份恢复 |
启动类问题中，“端口被占用”是最常见的。尤其是机器上装了多个数据库实例，或者另一个进程恰好用了 5432，都会导致 Postgres 启动失败。不要一上来就换端口，先看是谁占用的，如果是 MySQL、其他 PostgreSQL 实例，要规划好端口分配。必要时用ss -tlnp看清监听进程，再决定下一步。
6.4 连接阶段报错：认证、监听、防火墙
| 报错信息 | 原因 | 解决方式 |
|---|---|---|
FATAL: password authentication failed for user "postgres" | 密码不对，或认证类型设置不对 | 检查pg_hba.conf方法，用正确密码 |
FATAL: pg_hba.conf rejects connection ... | HBA 规则匹配拒绝 | 编辑pg_hba.conf，添加对应地址规则并 reload |
psql: could not connect to server: Connection refused | 数据库没启动或监听地址不对 | 检查启动状态、listen_addresses配置、端口 |
psql: FATAL: database "abc" does not exist | 目标库不存在 | 用\l查看数据库列表，创建所需库 |
连接阶段的坑往往不在 Postgres 本身，而在客户端参数。我在排查时通常按这个顺序走一遍：先pg_isready看服务是否在听，再psql -h 127.0.0.1测试本机连接，最后换远程 IP 测试外部连接，逐步缩小范围。把简单问题复杂化的常见原因，是改完postgresql.conf后没有重启，或改完pg_hba.conf后没有 reload。这两个参数文件虽在同一个目录，生效方式完全不一样，前者需要 restart，后者只需要 reload。
6.5 数据目录损坏与校验和报错
如果你按本文开启了数据页校验，启动或查询时可能遇到：
WARNING: page verification failed, calculated checksum does not match stored checksum这意味着某个数据页的校验和不一致，大概率是硬件层出了问题：磁盘坏道、内存故障、文件被外部修改都可能导致这种情况。此时要马上停止对这个实例的写入，立刻准备备份恢复，并根据备份时间点做 PITR（时间点恢复），不要抱着侥幸心理直接重启继续跑。数据页损坏如果不及时处理，小则单条记录读不出来，大则索引结构损坏、整个表不可用。这个警告背后的价值就体现在这里：没有开启校验和的时候，这类损坏可能要等很晚才暴露出来。
7. 最后再分享几个我自己的实操习惯
安装这种事情，次数多了自然就会总结出一套顺手流程。我现在每次装 PostgreSQL，不管装在哪台机器，都会固定做这样几件事。
第一，安装完成后立刻在本地写一个README文件，记录安装时间、版本、数据目录、编译参数、初始端口、超级用户名等信息。这个习惯救过我很多次。数据库迁维护、换人接手时，一份安装记录比任何口头交接都可靠，省去大量考古时间。
第二，配置完成后主动跑一轮压测脚本，模拟比日常高两三倍的连接数，观察系统资源占用和连接排队情况。不要等到业务高峰期让数据库在线上“裸考”，先在自己可控的范围内暴露瓶颈。实测下来，很多性能问题在压测阶段就能发现并解决，尤其 shared_buffers 和连接数配置是否合理，压一压最直观。
第三，安装文档里提到的检查和排查手段，我建议你自己亲手做一遍，比如把配置故意改错，看报错信息长什么样，再做一遍修复。这个“故意踩坑”的练习法，比背十遍文档都管用。因为报错信息在紧张时是找问题的线索，而不是干扰项，你见过一次、修过一次，记忆就非常深刻。
PostgreSQL 的安装只是万里长征第一步，后面还有备份、监控、高可用、性能调优等一堆活。但地基打得好不好，直接决定上面盖的楼稳不稳。把今天的安装步骤吃透，数据和配置都规划到位，后面的路会顺很多。
