nohup的核心作用是忽略SIGHUP信号、重定向I/O并断开会话绑定，而非单纯后台运行；它默认忽略挂起信号、将stdin重定向至/dev/null、stdout/stderr追加写入nohup.out，配合&实现真正脱离终端的持久化运行。
直接用 nohup command & 就能让进程真正脱离终端运行，关键不在“加不加&”，而在于它是否忽略 SIGHUP 信号、重定向 I/O，并断开与终端的会话绑定。
核心机制：三件事必须处理
nohup 不是后台启动命令，而是信号+I/O 管理工具：
- 自动忽略 SIGHUP 信号——终端关闭时系统不再通知进程退出
- 默认将 stdin 重定向到 /dev/null（避免卡在 input() 或 read）
- 默认将 stdout 和 stderr 追加写入 nohup.out（若当前目录不可写，则 fallback 到 $HOME/nohup.out）
标准写法与输出控制
推荐始终显式重定向，避免日志混乱或写入失败：
-
基础可靠写法：
nohup python app.py > app.log 2>&1 &
→ 标准输出和错误都进 app.log，进程后台运行 -
丢弃全部输出（适合无日志需求的守护任务）：
nohup ./worker.sh >/dev/null 2>&1 & -
分文件记录（便于排查）：
nohup node server.js > out.log 2> err.log &
验证是否真“脱离”了终端
别只信提示，要用系统级方式确认：
- 执行后看终端是否返回类似
[1] 12345——这是 job ID 和 PID，说明已交由 shell 后台管理 - 立即运行
ps -o pid,ppid,sid,tty,comm -C python（替换为你的命令名）
→ 若 TTS 列显示 ?，且 SID（会话 ID）与当前终端不同，说明已脱离会话 - 关掉终端再 ssh 重新登录，运行
pgrep -f "app.py"或ps aux | grep app.py，仍能查到进程即成功
常见误区提醒
这些操作看似一样，但结果可能截然不同：
-
command &→ 后台运行，但没屏蔽 SIGHUP，终端一关就死 -
nohup command（不加 &）→ 忽略挂起信号，但仍在前台阻塞终端，你无法继续输入其他命令 -
nohup command > log &但漏了2>&1→ 错误信息仍打到终端，一旦断连，stderr 可能导致进程异常终止或卡住 - 在 tmux/screen 里跑 nohup → 多余。tmux 本身已管理会话生命周期，nohup 不起额外作用
