Linux 后台任务三件套：&、nohup 与 systemctl 的使用场景辨析

在 Linux 服务器上让一个程序"持续跑着"，看似简单，实际有很多细节值得说清楚。很多初学者会用最直觉的方式：在命令后面加一个 &，关掉终端后发现程序也没了，于是开始怀疑人生。

先说 &。它只是把任务放到后台执行，但任务仍然挂在当前会话下。终端关闭时，会话收到 SIGHUP，后台任务往往随之终止。所以 & 适合短期任务：比如临时压缩一个大文件、跑几分钟的脚本，跑完就结束，不需要跨会话存活。

如果希望程序在终端关闭后继续运行，就要用 nohup。nohup 让进程忽略 SIGHUP 信号，配合 & 使用可以做到"关掉终端程序照跑"。它的输出默认写入当前目录的 nohup.out。典型用法是 nohup python3 app.py > app.log 2>&1 &。这里有个细节值得注意：重定向一定要写完整，否则 stdout 和 stderr 的归属会很混乱，排查问题时容易踩坑。nohup 适合"一次性长任务"，比如数据迁移、模型推理批处理，跑完就功成身退。

但如果你要的是一个"服务"——开机自启、崩溃自动重启、能用统一的命令启停管理，那 nohup 就不够了，正确答案是 systemd。写一个简单的 unit 文件放到 /etc/systemd/system/ 下，用 systemctl enable --now 启动，进程就纳入了系统服务管理。systemd 提供 Restart=on-failure 自动拉起、journalctl 统一日志、依赖排序等能力，是生产环境的标准做法。

简单总结选择逻辑：临时跑一下，用 &；要跨终端存活的一次性任务，用 nohup；要长期稳定运行、需要自愈和日志的服务，用 systemd。很多人在 nohup 上堆各种技巧（setsid、disown、screen、tmux）来解决"为什么我的程序又被杀了"，其实问对问题更重要：这到底是一个任务，还是一个服务？

另一个常被忽略的点是日志。无论用哪种方式，都要想清楚输出去哪：& 的输出混在终端里，nohup 落到文件，systemd 进 journald。日志无归属，是线上排查问题最常见的障碍之一。

三种方式没有优劣之分，只有场景之分。理解它们背后的信号机制与会话模型，比记住命令本身更有价值。