nohup 把 APP_MODE=test 当作命令，报 No such file or directory

把环境变量加到 nohup 后面，命令还没真正启动就报错：

nohup: failed to run command 'APP_MODE=test': No such file or directory

如果实际写的是 nohup APP_MODE=test ./worker &，nohup 正在把 APP_MODE=test 当作程序名执行。这里找不到的不是应用的配置文件；给 worker 反复加执行权限不会修复参数位置。

下面针对 Linux 上 Bash 与 GNU coreutils 的外部 nohup、env。其他 shell 可能有内建版本，应先用 type -a nohup env 确认实际使用的命令。

让 env 接收赋值，再运行应用

假定 ./worker 是当前目录下已确认可以运行的程序，可以写成：

nohup env APP_MODE=test ./worker >./worker.log 2>&1 </dev/null &

env 支持在命令前接收 NAME=VALUE，设置目标程序的环境后再执行它。nohup 此时执行的是 env，不会把赋值字符串误当作文件名。

worker、变量名和值都是占位示例。程序路径、参数以及日志目录必须按实际环境替换；> 会截断已有日志，需先保留原文件，或在确实需要追加时使用 >>。& 才是把命令放到后台的 shell 语法，nohup 本身不会自动完成这个动作。

这里显式指定标准输入和输出，便于确定日志位置。没有重定向时，GNU nohup 会根据终端连接情况处理输入，并可能把输出追加到 nohup.out；不能只去应用原来的日志目录寻找启动错误。

把赋值放在 nohup 前面也可以，但作用范围不同

Bash 允许在简单命令前放临时环境赋值：

APP_MODE=test nohup ./worker >./worker.log 2>&1 </dev/null &

这会把变量传给 nohup，并由后续程序继承。对于普通应用配置，两种写法通常都能传递值；如果变量会影响程序加载或运行环境，就要考虑它也会影响 nohup 本身。使用 nohup env ... 时，赋值由 env 处理，更适合把这次设置留给后面的目标命令。

例如涉及 LD_PRELOAD 时，修正这条命令的排列顺序，只能解决“把赋值当程序名”的错误，不能证明共享库已成功加载。库格式、依赖、目标进程的加载规则仍需按实际错误另查。不要根据程序运行时间变长或变短，单独判断变量是否传入。

变量值包含空格时，保持一个完整参数，例如 APP_LABEL='test worker'。不要把整条命令塞进一个字符串，再用 eval 试图恢复 shell 语法；这里不需要增加一层命令解释。

先验证一个无敏感内容的变量

可以在隔离目录用下面的短命令检查传递结果。它只打印专门设置的测试变量，不输出整份环境：

nohup env APP_MODE=test sh -c 'printf "%s\n" "$APP_MODE"' \
  >./nohup-env-check.log 2>&1 </dev/null &
check_pid=$!
wait "$check_pid"
cat ./nohup-env-check.log

预期日志是 test，wait 应反映这次短命令的完成状态。示例日志名应选未被使用的位置，避免覆盖已有文件。这段检查验证的是变量传递与命令启动，不是业务程序健康，也没有测试断开会话后的运行情况。

实际应用还需要核对启动日志、退出状态和自身的健康检查。后台提示一个 PID 不代表应用已经初始化成功。nohup 主要处理挂断信号，不能代替服务管理器的重启、健康检查或日志管理。

若错误中已经变成 ./worker 而不再是 APP_MODE=test，应转向程序路径、工作目录、解释器或可执行文件的检查；不要把所有 No such file or directory 都归为赋值位置问题。

回退只改这次启动方式

修改前保存原启动命令和必要日志。以上临时赋值不会永久改写当前 shell 的环境；需要回退时恢复原来的有效启动方式，并按应用自己的流程停止或替换进程。配置回退不会撤销程序已经写入的数据，也不要用宽泛的进程名匹配去终止其他任务。