sudo -u postgres psql 报 command not found，切换用户登录后却能运行

当前用户直接执行 psql 能找到程序，sudo -u postgres psql 却报 sudo: psql: command not found；登录到 postgres 的 shell 后又能运行。先核对 sudo 的命令搜索路径与客户端实际位置。这个错误发生在启动客户端之前，调整数据库密码或认证规则无法让 sudo 找到程序。

以下适用于 Linux 上通过 sudo 切换身份、客户端安装在版本目录或其他非标准位置的场景。secure_path 是否启用由本机策略决定，不能假设所有发行版都使用同一配置。

不要用 sudo echo $PATH 判断

下面这种检查会在原 shell 中先展开变量：

sudo echo "$PATH"

sudo 收到的已经是原用户的路径文本，输出看起来正确也不能说明 sudo 用它搜索 psql。登录到另一个 shell 的路径也可能来自那个 shell 的启动配置，不能代表直接执行 sudo -u postgres psql 的行为。

先在普通 shell 中定位实际可执行文件：

command -v psql

如果输出是 alias 或函数，应继续确认它最终调用的真实二进制，而不是把别名文字直接传给 sudo。下面是用受信任的系统 shell 查看目标命令环境的示例：

sudo -u postgres /bin/sh -c 'printf "%s\n" "$PATH"'

外层单引号使变量交给目标 shell 展开。/bin/sh 应替换为目标系统实际存在、由管理员管理的 shell。输出的是子进程环境；若 sudo 策略未启用 secure_path，命令查找与子进程的环境路径还可能不同，因此应同时核对实际 sudoers 策略。

使用确定的客户端路径

若客户端确实安装在版本目录，可以显式指定完整路径。以下是 PostgreSQL 15 客户端的一种路径示例，不代表所有系统都这样安装：

sudo -u postgres /usr/pgsql-15/bin/psql --version

这条命令只显示所选客户端版本。确认是需要的客户端后，实际连接命令也使用同一路径。客户端版本与服务器版本是两件事，不要只因路径带 15 就认定服务器也是 15。

sudo 启用 secure_path 时，可以用固定的管理员管理路径搜索命令。给 root 的 .bashrc 增加目录不保证会改变直接 sudo 调用，sudo -E 也不能保证覆盖已有的安全路径策略。

长期需要用短命令时，由管理员通过 visudo 在合适范围调整路径，只加入可信且不被普通用户写入的目录。不要为了一个客户端取消全局 secure_path，也不要把普通用户可修改的安装目录放进高权限命令搜索路径。编辑前保存原策略并保留可恢复的管理员会话，验证语法和授权范围；失败时恢复原文件。

找到程序后出现其他错误

显式路径仍报文件不存在时，检查路径、安装情况和目录访问权限。客户端成功启动但提示 could not change directory ... Permission denied 时，应区分当前工作目录不可访问与数据库认证失败；从目标身份可访问的目录发起连接，避免误改数据库权限。

成功标准是实际任务入口能启动预期版本的客户端，随后连接到正确数据库。出现角色、密码或连接错误说明已经进入客户端的另一层检查，不应继续扩大 sudo 权限来处理。