Linux 环境变量与 PATH：交互终端、sudo 和服务为何不同
本文适用于 Ubuntu 24.04、Bash 和 systemd 服务。排查“找不到命令”时，先确认程序是否存在，再看当前进程怎样查找它。不要因为一个后台任务失败，就把程序复制到多个系统目录，或把所有 Shell 配置文件都修改一遍。
PATH 决定搜索顺序，不决定安装状态
# 服务器：在发生问题的用户终端中只读检查
printf '%s\n' "$PATH"
command -v python3
type -a python3
PATH 是以冒号分隔的目录列表，Shell 依次寻找可执行程序。command -v 显示当前环境中命令如何解析，type -a 可帮助发现同名别名、函数或多个可执行文件。命令存在但找到的版本不对，与程序根本未安装是两种问题。
优先使用已经核实的程序绝对路径进行对照测试。不要把当前目录 . 放在管理员 PATH 的前部，也不要加入普通用户可随意写入的目录作为特权程序搜索位置，否则可能误执行同名文件。Bash 的命令查找规则见 Bash 手册。
export 只影响后续子进程
在当前 Shell 设置普通变量，并不保证启动的程序能够读取；使用 export 才将其放入后续子进程继承的环境。例如：
# 服务器：仅修改当前会话及其之后启动的子进程
export DEMO_MODE=check
printenv DEMO_MODE
unset DEMO_MODE
unset 可撤销当前会话中的变量，但已经启动的子进程通常仍保留启动时获得的值。反过来，子进程也不能通过修改自己的环境来直接改变父 Shell。理解这一点，就能解释为什么编辑配置后正在运行的服务不会自动读取新值。
一次性测试可用 DEMO_MODE=check /usr/bin/printenv DEMO_MODE。这类写法将变量提供给该次命令，不必先改持久配置。敏感变量不要通过完整环境转储公开分享，也不要把密码误写进可读脚本和终端历史。
登录 Shell 与交互 Shell 读取不同文件
Bash 登录启动与普通交互启动的配置读取规则不同。登录 Shell 会按规定顺序寻找用户配置文件，常见涉及 ~/.bash_profile、~/.bash_login 和 ~/.profile，并非三个都会依次执行；非登录交互 Bash 通常读取 ~/.bashrc。
Ubuntu 的用户文件可能再相互引用，具体应查看当前账号实际内容。不能看到一个文件存在，就认定所有会话都读取它。某些非交互场景还有额外规则，应结合启动方式检查，而不是把环境设置复制到每个文件。
修改持久文件前保存原内容，只添加该用户确实需要的设置。先开新会话验证，再关闭旧会话；若新设置有问题，利用保留的会话恢复。执行 source 会运行文件中的命令，因此只应加载已经审查过的配置。
sudo 和 systemd 各有环境规则
sudo 可以根据策略清理环境或使用单独的安全 PATH，因此普通用户找到的命令，提升权限后未必相同。不要为了一个脚本直接关闭环境清理或保留全部用户变量。先检查脚本是否可改为使用明确路径，再按最小范围处理所需变量。相关策略见 sudoers 手册。
systemd 的 ExecStart 默认也不是一个登录 Shell，不会自动读取你的 ~/.bashrc。把环境设置写在个人终端配置里，不能保证系统服务能够获得。需要时使用服务单元支持的 Environment= 或 EnvironmentFile=，其解析规则并不等于直接运行一段 Shell 脚本。
服务环境说明见 systemd.exec 手册。包含凭据时还要评估适合的凭据管理机制，不能简单认为放在环境变量中就保密。
按实际执行入口完成验证
调整服务单元或其覆盖配置后，应按变更范围重新加载单元，并在可接受的窗口重启受影响服务。单纯重新加载 systemd 单元定义，不会自动改变已运行进程的环境；重启带来的业务影响需要提前确认。
验证时从真正失败的入口启动：服务用服务方式、计划任务用调度方式、sudo 脚本用相同身份。检查程序路径、实际版本、配置读取和业务结果，不要只看交互终端成功。若改动无效，恢复本次配置后继续定位，避免不断扩大 PATH。涉及 SSH 用户环境时，可结合SSH 登录排查确认登录身份与会话类型。