使用&符号可在当前终端会话中将进程放入后台运行，但关闭终端时进程通常会因收到sighup信号而终止；2. 使用nohup命令可使进程忽略sighup信号，即使关闭终端或断开ssh连接，进程仍能持续运行，默认输出重定向至nohup.out文件；3. 对于短期或会话内任务，&符号足够使用，而对于需长期运行且不受终端状态影响的任务，应优先选择nohup；4. 若需更复杂的会话管理，可选用screen或tmux等工具，但仅就保障进程在终端关闭后继续运行而言，nohup是最简洁有效的解决方案。
让进程在后台运行，最常用的方法无非是使用
&符号和
nohup命令，它们都能让你把当前终端的控制权解放出来，但两者在进程的生命周期管理上有着本质的区别，尤其是当你关闭终端会话时，它们的表现会大相径庭。
让进程在后台运行，你可以简单地在命令末尾加上
&符号，例如
my_command &。如果希望进程在当前终端关闭后依然存活，通常会用到
nohup命令，像这样
nohup my_command &。对于已经启动但想转到后台的进程，可以先按
Ctrl+Z暂停，然后使用
bg命令让它在后台继续运行。
&
符号：它真的“后台”了吗？
当你敲下
my_script.sh &并回车，你会发现命令提示符立刻就回来了，感觉就像脚本已经在后台跑起来了。从表面上看，确实如此，你的终端可以继续输入其他命令了。但这里有个很关键的细节，也是我个人觉得很多人容易忽略的地方：这个“后台”是相对于你当前shell会话而言的。
这意味着什么呢？简单来说，你的脚本虽然在后台运行，但它仍然是当前终端会话的子进程。一旦你关闭这个终端窗口，或者会话因为网络断开等原因“挂断”（hang up），你的脚本很大概率也会跟着一起“挂掉”。这是因为当会话结束时，操作系统会向其所有子进程发送一个
SIGHUP（挂断）信号，默认情况下，收到这个信号的进程就会终止。我以前就吃过这个亏，跑个耗时比较长的脚本，以为加个
&就万事大吉了，结果笔记本一合盖或者网络一波动，回来一看，进程没了，真是欲哭无泪。
你可以用
jobs命令查看当前shell会话中所有后台运行的进程。它能告诉你进程的ID、状态等信息，但一旦会话结束，这些信息也就不复存在了。所以，
&更适合那些你确定在当前会话存活期间就能完成的任务，或者你压根不介意它随会话一起终结的短时任务。
nohup
命令：告别SIGHUP的烦恼
nohup命令，顾名思义，就是“no hang up”的缩写，它存在的目的就是为了解决
SIGHUP信号带来的困扰。当你使用
nohup command &这种组合时，
nohup会做两件事：一是让
command忽略
SIGHUP信号，二是如果
command没有指定输出重定向，它会将标准输出和标准错误重定向到当前目录下的
nohup.out文件（如果没有则创建）。
这个重定向非常重要。试想一下，如果你的后台进程还在往一个已经关闭的终端输出内容，那会是什么情况？很可能导致进程卡住或者异常。所以，
nohup的默认行为是非常贴心的。当然，你也可以手动指定输出文件，比如
nohup python my_server.py > server.log 2>&1 &，这样就能把所有输出都写入
server.log，同时
2>&1确保了标准错误也重定向到同一个文件，这在排查问题时非常有用。
使用
nohup后，你的进程就真正地脱离了终端会话的束缚。你可以放心地关闭终端，甚至断开SSH连接，进程依然会在服务器上默默地运行。对于需要长时间运行的服务、后台任务或者批处理脚本，
nohup几乎是必选项。
选择困境：我该用哪个？
到底是用
&还是
nohup，这其实不是一个非此即彼的问题，而是根据你的具体需求来定。我个人会这样考量：
如果你只是想让一个命令在当前终端的后台跑，你还可能随时用
fg把它切回前台交互，或者这个命令本身执行时间很短，短到你根本不担心终端关闭的问题，那
&就足够了。比如，我可能只是想编译一个项目，或者复制一大堆文件，这些操作可能需要几分钟，但我人还在电脑前，终端不会关，用
make &或
cp -r large_dir /dest &就很方便。
但如果你的任务是那种需要“不间断”运行的，比如一个Web服务、一个数据处理脚本、一个定时任务的守护进程，或者任何你希望即使你下班关电脑、服务器重启（当然重启后需要其他机制来恢复）也能持续运行的程序，那么
nohup就是你的首选。它提供的是一种更强的“会话独立性”。
当然，除了
&和
nohup，还有更强大的工具，比如
screen或
tmux，它们能创建持久化的虚拟终端会话，让你在其中运行多个程序，随时可以“附着”或“分离”，这对于复杂的远程工作流来说是神器。但如果仅仅是让一个进程在后台“活下来”，
nohup的简洁和有效性是无可替代的。所以，简单来说，如果你关心终端关闭后进程的命运，那就用
nohup；如果只是想立即拿回终端控制权，且不介意进程随终端关闭，
&就够了。
