pgJDBC 的 search_path 只剩一个 schema，检查 currentSchema 是否同时设置

JDBC URL 明明写了多个 schema，SHOW search_path 却只返回其中一个。若 URL 同时带有 currentSchema 和 options=-c ...search_path=...，先消除重复设置，不要继续在 URL 后面追加第三份参数。

例如下面两个入口指定了不同的值：

jdbc:postgresql://db.example:5432/app?currentSchema=app_data&options=-c%20search_path=app_data,shared,public

pgJDBC 会把 currentSchema 作为独立的 search_path 启动参数发送，同时把 options 单独发给服务器。它们不是简单按 URL 中出现顺序依次执行的两条 SET。PostgreSQL 18.3 的这一明确场景中，最终采用的是 currentSchema 的单个值。

一个设置只保留一个入口

需要多个 schema 时，currentSchema 本身就支持逗号分隔列表。以示例地址为例，可改成：

jdbc:postgresql://db.example:5432/app?currentSchema=app_data,shared,public

也可只保留 options，移除 currentSchema：

jdbc:postgresql://db.example:5432/app?options=-c%20search_path=app_data,shared,public

名称与地址都要替换为实际值。若 URL 还有其他必要的连接参数，应保留；options 中若还设置其他服务端参数，也应逐项保留并正确进行 URL 编码，不要直接删掉整个 options 值。

schema 顺序决定未限定表名如何解析。将 public 或其他 schema 加入路径前，要确认是业务原本需要的范围；不要为了“让查询能找到表”任意扩大查找顺序。

在应用实际借到的连接里检查

验证使用：

SHOW search_path;
SELECT current_schema();

两者用途不同：前者显示完整设置，后者只返回当前搜索路径中的首个有效 schema。用 current_schema() 的单个结果判断后续 schema 是否丢失，会造成误判。

必须在应用执行 SQL 的同一连接上查询。管理工具、另一条 JDBC 连接或连接池之外的测试，不会证明当前会话设置相同。检查连接池初始化 SQL、框架默认 schema、角色级和数据库级配置是否还会在连接建立后修改它。

修改连接串后按原有流程更新连接池，使新建的物理连接采用新设置；池里已有会话不会因为配置文件变化就自动重新发送启动参数。保留旧连接配置，复查新连接与复用连接上的完整路径，并用实际需要解析的表名验证顺序，避免只看一个参数字符串正确就结束。