先确保 pg_connect() 连通，再处理语法细节；90% 问题源于连接字符串格式错误、pgsql 扩展未启用或 PostgreSQL 权限配置不当。
直接说结论：别从“学 pgsql 扩展”开始，先确认 pg_connect 能跑通，再补参数细节和错误处理——90% 的卡点不在语法，而在连接字符串格式、扩展未启用或权限配置。
pg_connect() 连不上？先检查这三件事
不是代码写错，而是环境没准备好。常见现象是 Warning: pg_connect(): Unable to connect to PostgreSQL server 或直接返回 false。
- PHP 是否加载了
pgsql扩展：运行php -m | grep pgsql（Linux/macOS）或查看phpinfo()页面里有没有pgsql和pdo_pgsql；没出现就说明扩展没启用 - 连接字符串格式是否合法：必须用
key=value键值对拼接，不能漏空格，不能用 URL 形式（比如postgresql://...不被pg_connect()原生支持）；正确示例："host=localhost port=5432 dbname=testdb user=postgres password=123" - PostgreSQL 服务是否允许该用户从该 host 连入：检查
pg_hba.conf是否有类似host all all 127.0.0.1/32 md5的规则，且执行过pg_ctl reload或重启服务
pg_query() 执行失败但没报错？大概率是 SQL 注入防护反噬
新手常把变量直接拼进 SQL 字符串，比如 "SELECT * FROM users WHERE id = $id"。这在数据干净时能跑，但一旦 $id 是 1; DROP TABLE users; 就完蛋——而更隐蔽的问题是：PostgreSQL 对类型敏感，WHERE status = 'active' 和 WHERE status = 1 可能因字段类型不匹配静默失败。
- 改用
pg_query_params()：它自动处理类型转换和转义，参数单独传，SQL 模板里用$1,$2占位，例如：pg_query_params($conn, "SELECT * FROM users WHERE id = $1 AND status = $2", [123, 'active']) - 避免
pg_escape_string()：这个函数已废弃，且不区分上下文（它只做字符串转义，不处理标识符如表名、字段名），真要拼动态表名请用pg_escape_identifier() - 查错时别只看
pg_query()返回值：加一句if (!$result) { echo pg_last_error($conn); }，否则错误信息被吞掉
查询结果取不出来？注意资源类型和内存边界
pg_query() 返回的是 resource（PHP 7.x）或 PgSql\Result（PHP 8.1+），不是数组。直接 print_r($result) 看不到数据，还可能触发 Warning: print_r() expects parameter 1 to be array。
立即学习“PHP免费学习笔记（深入）”；
- 用
pg_fetch_assoc()逐行取：适合大多数场景，返回关联数组，键名默认是小写字段名 - 大数据集别用
pg_fetch_all()：它把全部结果一次性载入内存，10 万行文本字段可能吃光 512MB 内存；应改用游标（DECLARE cur CURSOR FOR ...+FETCH 1000 IN cur）或分页LIMIT/OFFSET - 字段名大小写敏感：PostgreSQL 默认把未加引号的字段名转为小写，所以
SELECT UserName FROM users实际返回的键是username，不是UserName；要用就写成SELECT "UserName" FROM users
连接池和长连接容易被忽略的坑
Web 请求模型下，每次请求都 pg_connect() + pg_close() 看似稳妥，但频繁建连开销大；想复用连接又怕超时断连或状态污染。
-
pg_pconnect()不等于连接池：它是进程级持久连接，Apache prefork MPM 下每个子进程维护一个，但 Nginx + PHP-FPM 场景下基本无效（worker 进程不共享） - 别依赖
pg_connection_status()判断连接是否可用：它只反映 socket 层是否断开，不保证事务状态干净；更可靠的是执行一条轻量 SQL，如SELECT 1，捕获异常再重连 - 连接泄露很隐蔽：如果某段逻辑抛出异常没走到
pg_close()，连接会一直占着直到脚本结束；建议用try/finally包裹，或改用 PDO 并设PDO::ATTR_PERSISTENT => true让底层管理
真正难的不是函数怎么写，而是你得同时盯住 PHP 扩展状态、PostgreSQL 认证配置、SQL 类型系统、以及 Web 生命周期里的资源生命周期——四个层面只要一个断链，pg_connect() 就只是个返回 false 的黑盒。
