后台运行需区分场景：临时用&即可，但断连会终止；长期运行须用nohup+&或screen/tmux，并务必重定向输出，否则日志丢失或干扰终端。
直接加 & 最快，但关终端就死；真要长期跑，必须用 nohup 或 screen，否则一断 SSH 进程就没了。
命令末尾加 & 就能后台运行？
能，但只解决“不卡终端”这一个问题。它把进程扔进后台，立刻返回 shell，你接着打别的命令。但这个进程仍和当前 shell 会话绑定，一旦终端关闭（比如 SSH 断开、本地终端退出），系统会发 SIGHUP 信号把它干掉。
-
python script.py &：启动快，适合秒级任务或临时测试 - 输出默认还在终端上刷，可能干扰你后续输入 —— 要避免，得手动重定向：
python script.py > log.txt 2>&1 & -
jobs能看到它，fg %1或kill %1可操作，但仅限当前 shell 生命周期内
nohup 真的能抗断连？
能，但它不是“自动后台”，而是“忽略挂起信号”。你必须搭配 & 才真正后台运行，否则它会在前台阻塞等待你按回车。
- 正确写法：
nohup python long_task.py > out.log 2>&1 & - 不写重定向时，
nohup默认往当前目录写nohup.out；如果没权限写，会 fallback 到$HOME/nohup.out—— 但若两者都不可写，命令直接失败 -
2>&1必须写在>后面，顺序错了（比如2>&1 > log）会导致 stderr 仍打到终端 - 启动后看不到 job 编号，
jobs也查不到它 —— 因为nohup已让它脱离当前 shell 作业控制
已经前台跑了，怎么救回来？
别关终端，用 Ctrl+Z 暂停，再用 bg 推后台。这是唯一能抢救正在运行但没加 & 的命令的办法。
- 按
Ctrl+Z后，终端显示类似[1]+ 已停止 python running.py—— 这里的[1]就是 job 编号 - 执行
bg %1让它继续在后台跑；如果忘了编号，先jobs看一眼 - 想以后续操作更稳，立刻补上
disown %1：它从作业表里删掉这条记录，避免终端关闭时被顺带 kill - 注意：
disown之后不能再用fg或bg操作它了
远程服务器上跑 overnight 任务，该选 screen 还是 tmux？
二者本质一样，但 tmux 的脚本化支持更好，screen 更轻量、老系统自带。关键不是哪个“高级”，而是你是否需要中途 reconnect 并继续交互。
-
screen -S myjob启动后，运行命令，再按Ctrl+A然后D分离（detach）—— 此时会话仍在后台，SSH 断了也不影响 -
tmux new-session -d -s myjob 'python task.py'：-d参数直接后台启动，适合写进 cron 或自动化脚本 - 重连时：
screen -r myjob或tmux attach-session -t myjob，就能回到原来终端画面，看到实时输出 - 它们都不依赖
nohup，但建议仍重定向输出：screen -S logjob bash -c 'python app.py > run.log 2>&1'
最常被忽略的点：所有后台方案都绕不开输出重定向。不加 > file 2>&1，日志要么丢、要么混进终端、要么写进不可控位置。哪怕只是临时测试，也该养成重定向的习惯。
