bg命令用于将已挂起（suspended）的作业恢复并在后台运行，必须先用ctrl+z暂停前台进程使其进入stopped状态，否则bg无效；它操作的是shell作业号（如%1），非pid，且后台进程默认仍关联终端，关闭终端会触发sighup终止进程。
直接按 Ctrl + Z 暂停，再用 bg 恢复到后台继续运行——这是最常用、最可靠的方式。不需要改命令、不依赖额外工具，所有标准 shell 都支持。
为什么不能直接用 bg？必须先 Ctrl + Z
bg 只能作用于「已挂起（suspended）」的作业，不是正在前台运行的进程。如果你跳过暂停步骤，直接输 bg，它会报错：bash: bg: current: no such job 或静默失败。
- 前台运行的程序独占终端控制权，shell 无法对其发信号或调度
-
Ctrl + Z实际发送的是SIGTSTP信号，让进程进入Stopped状态，并交还终端控制权 - 此时
jobs才能看见它，bg才有目标可操作
jobs 显示的 %1 和 PID 不是一回事
执行 jobs -l 时，输出类似：[1]+ 12345 Stopped python script.py。这里的 %1 是 shell 内部作业编号（job number），而 12345 是真实 PID。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
bg %1和fg %1必须用%加作业号，不能用 PID - 如果误写成
bg 12345，shell 会提示：bash: bg: 12345: no such job - 想查某个 PID 对应哪个作业号？只能靠
jobs -l | grep 12345反向匹配
输出还在终端刷屏？你得重定向
用 Ctrl + Z + bg 转到后台后，stdout 和 stderr 默认仍连着原终端。如果程序持续打印日志，会干扰你后续输入。
- 补救方法：立刻执行
disown %1，然后手动重定向输出（但已输出的内容无法收回） - 更稳妥的做法是提前预防——在
bg后立即重定向：bg %1 > /tmp/output.log 2>&1（部分 shell 支持，但非全部；zsh 支持，bash 4.4+ 有限支持） - 真正可靠的方案是：暂停前就重定向，比如
python script.py > log 2>&1，再Ctrl + Z→bg
关掉终端后进程还会死？那是因为没断开 SIGHUP 关联
bg 后的进程仍属于当前 shell 的会话，终端关闭时会收到 SIGHUP 并退出。这不是 bug，是设计如此。
- 补救：运行
disown %1，它会从 shell 作业表中移除该任务，不再发送SIGHUP - 验证是否生效：退出终端再
ps -p 12345（用之前jobs -l查到的 PID），如果还在，说明成功 - 注意：
disown不影响进程本身，只是解除终端生命周期绑定；它不能替代nohup或screen的完整守护能力
真正容易被忽略的点是：作业编号 %1 是会话级的，换一个终端或新开 shell 就失效；而 disown 后的进程虽然脱离了 SIGHUP，但如果它依赖终端输入（比如读 stdin），可能卡住或行为异常——这种情况下，别硬转后台，改用 screen 或 tmux 更稳妥。
