bg 提示“no current job”或失败的根本原因是当前 shell 会话中不存在已暂停（Stopped）且仍存活的作业；bg 仅能恢复被 Ctrl+Z 暂停、尚未退出且属于本会话的作业，对 & 启动的进程、已结束作业或非本会话进程均无效。
为什么 bg 有时提示 “no current job” 或直接失败
根本原因不是命令写错了，而是当前 shell 没有挂起（SIGTSTP）的作业——bg 只能重启已暂停、且仍属于当前 shell 会话的作业。
常见误操作包括：
- 用
&启动的进程默认是前台运行后立即转入后台，它从没被暂停过，所以bg对它无效 - 按
Ctrl+Z后没执行bg就又输了一条新命令，shell 会把刚挂起的作业标记为“非当前”，此时bg默认操作对象丢失 - 作业已在后台运行完毕或被
kill掉，jobs列表里看不见，自然不能bg
验证方式：先执行 jobs，确认看到类似 [1]+ Stopped vim test.txt 的输出，再运行 bg %1（注意带作业号和百分号）。
jobs 显示的 +、- 和数字编号到底代表什么
这些符号不是随机生成的，而是 shell 维护的一个**作业栈顺序标识**：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
+表示最近一次挂起或启动的作业（即默认操作对象，fg或bg不带参数时作用于此） -
-表示倒数第二次的作业，再往前的作业只显示编号（如[2]、[3]），不标符号 - 编号（如
%1、%2）是 shell 分配的唯一作业 ID，和 PID 不同，但可通过jobs -l查看对应 PID
例如：jobs -l 输出 [1]- 12345 Running sleep 100 &，说明该作业编号为 1，PID 是 12345，状态是 Running —— 此时对它执行 fg %1 会把它拉回前台并阻塞当前终端。
用 fg 切换作业时终端卡住或报 “No such job” 怎么办
卡住通常是因为目标作业本身在读取 stdin（比如 vim、read、交互式 python），而你又没给它输入；报错则多因作业已退出或编号记错。
- 先运行
jobs确认作业还在列表中，且状态不是Done或Exit - 如果作业是交互程序，
fg后要立刻按键（比如按Enter或Esc）唤醒它，否则看起来像“卡死” - 避免依赖记忆编号：用
fg %?（问号匹配名字）更安全，比如fg %?http会找到名字含 http 的最近作业 - 如果作业已退出但
jobs还残留（罕见），执行wait可清空已完成作业记录
后台作业和系统级守护进程（daemon）不是一回事
很多人以为 nohup cmd & 或 bg 启动的就是“服务”，其实它们仍依赖当前 shell 的生命周期：
- 关闭终端（或 ssh 断连）时，未加
nohup/disown的后台作业会收到SIGHUP并退出 -
disown %1可让作业脱离 shell 作业表，不再受SIGHUP影响，但它仍属于当前会话的进程组 - 真正长期运行的服务应使用
systemd、supervisord或至少nohup cmd > /dev/null 2>&1 &+disown
一个典型遗漏点：即使用了 nohup，如果忘了重定向 stdout/stderr，日志可能写入 nohup.out 并撑满磁盘 —— 生产环境务必显式指定输出路径。
