企业官网建设流程全解析

1. 为什么说 ps 是 Linux 进程管理的“第一把钥匙”

在 Linux 系统里，你刚打开终端，敲下ps，看到那一屏滚动的 PID、TTY、TIME、CMD——这不只是几行字符，而是整个系统此刻的“生命体征快照”。我带过不少刚从 Windows 转过来的运维新人，他们第一反应是找“任务管理器”，结果发现 Linux 没有图形界面也能实时掌握每个进程的 CPU 占用、内存消耗、启动用户、父进程关系，靠的就是这个看似简单、实则信息密度极高的ps命令。它不依赖 GUI、不占用额外资源、秒级响应，是排查服务卡顿、定位僵尸进程、验证脚本是否真正启动、甚至发现异常后台程序的最底层、最可靠的入口。你不需要先装监控平台，也不用等 Prometheus 抓取指标——只要能连上终端，ps就在那儿，像一把随身携带的万用表。热搜词里反复出现的“linux常用命令”“进程”“参数”，恰恰说明：这不是一个可学可不学的冷门工具，而是所有 Linux 使用者——无论是写 Python 脚本的开发者、部署 Nginx 的运维、调试嵌入式应用的工程师，还是只用 WSL 做开发的学生——每天都会触达的基础设施级能力。它不炫技，但一旦你真正吃透它的参数组合逻辑和输出字段含义，你会发现，90% 的进程类问题，根本不用查文档、不用翻博客，三秒内就能在终端里完成诊断。我见过太多人卡在“进程没起来”上，反复重启服务，最后发现只是ps aux | grep myapp里漏看了一个defunct状态；也见过有人为查某个 Java 进程的启动参数，硬是去翻/proc/12345/cmdline，其实ps -f -p 12345一行就搞定。这就是ps的价值：它不制造新功能，而是把系统已有的、最原始的进程信息，以最直接、最可控的方式交到你手上。

2. ps 的设计哲学与核心机制拆解

2.1 它不是“查询数据库”，而是“读取内核快照”

很多人误以为ps是像 SQL 查询一样，从某个进程数据库里捞数据。完全不是。ps的本质，是直接读取 Linux 内核的进程数据结构（task_struct）在内存中的实时副本。当你执行ps aux，它做的其实是：

1. 扫描/proc文件系统下的每一个数字目录（如/proc/1,/proc/1234），每个目录对应一个运行中的进程； 2.. 对每个目录，读取其中的关键文件：/proc/[pid]/stat（获取状态、CPU 时间、父 PID 等）、/proc/[pid]/status（获取内存、UID、GID 等）、/proc/[pid]/cmdline（获取启动命令行）；
2. 将这些原始二进制或文本数据，按预设规则解析、格式化，最终输出成我们看到的表格。

这个机制决定了ps的三个关键特性：

• 瞬时性：它抓取的是执行命令那一刹那的快照。进程可能在ps执行的 0.01 秒后就结束了，所以你看到的 PID 列表永远是“过去式”。这也是为什么ps无法替代top或htop做持续监控——它天生就是单次快照工具。
• 无侵入性：它不向目标进程发送任何信号，不修改其状态，不增加任何开销。哪怕你ps aux查上万进程，对系统负载的影响也微乎其微。这点在生产环境排查高负载问题时至关重要——你不能因为查问题，让问题更严重。
• 权限依赖性：普通用户只能看到自己启动的进程（以及部分系统进程），而root用户能看到全部。这是因为/proc/[pid]目录的读取权限由内核控制，ps只是忠实反映这个权限规则。当你看到ps aux输出里某行 UID 是root，而你又是普通用户，那这一行就是ps在告诉你：“这个进程你无权操作，但你可以看见它存在”。

提示：理解这个底层机制，能帮你避开很多误区。比如，有人问“为什么ps查不到刚&启动的后台进程？”，答案往往不是ps有问题，而是那个进程启动太快、结束太快，或者你的 shell 没来得及更新作业列表。ps只负责“看”，不负责“跟踪”。

2.2 为什么要有 BSD 风格和 System V 风格两套语法？

ps的参数设计是 Unix 哲学的典型体现：兼容并蓄，不强行统一。它同时支持两种完全不同的参数风格，不是设计混乱，而是历史演进和用户习惯妥协的结果。

• BSD 风格（无横杠）：ps aux,ps ax,ps ef。这里的a、u、x、e、f都是单字母选项，组合起来表示“显示所有用户的所有进程（a）、以用户友好的格式（u）、包括没有控制终端的进程（x）、显示环境变量（e）、显示进程树（f）”。这种风格简洁、易记，是大多数教程和老手的首选。它的逻辑是“叠加功能”，aux就是a+u+x的效果总和。

• System V 风格（带横杠）：ps -e -f,ps -U root -o pid,ppid,comm,%cpu。这种风格更接近现代命令行工具的通用规范，用-引导选项，支持长选项（如--forest），并且-o可以自定义输出字段。它的逻辑是“明确指定”，-e表示“所有进程”，-f表示“全格式”，-o表示“我要自己选列”。

这两套风格可以混用！比如ps -eo pid,ppid,comm,args是标准的 System V 写法，而ps aux --sort=-%cpu则是 BSD 风格加了一个 System V 的长选项。ps的开发者故意保留了这种“混乱”，因为：

1. 向后兼容：无数脚本、文档、教材都基于ps aux，强行废除会引发大规模故障；
2. 场景适配：快速查看用aux，精确筛选用-U和-o，复杂排序用--sort，不同场景用不同风格，效率最高；
3. 学习曲线平缓：新手从ps aux入门，熟练后再接触-o自定义，路径清晰。

我建议你把ps aux当作“普通话”，把ps -eo ...当作“专业方言”。日常排查，ps aux足够；写自动化脚本、做报表分析，必须掌握-o。

2.3 “进程”在 Linux 里到底是什么？——理解 ps 输出字段的基石

ps的输出字段，不是随意排列的。每一个字段，都对应着内核中task_struct结构体的一个成员。搞不清字段含义，再熟的参数也是空中楼阁。我们以ps aux最常见的 11 列为例，逐个拆解其背后的真实含义：

• USER：进程的有效用户 ID（EUID）。注意，不是启动用户，而是进程当前以哪个用户身份在运行。一个root启动的nginx，worker 进程的 USER 往往是www-data，这就是权限降级的体现。
• PID：进程 ID。内核分配的唯一整数标识。它是进程在系统内的“身份证号”，所有其他操作（kill、strace）都以此为索引。
• %CPU：该进程自上次更新以来，占用 CPU 时间的百分比。计算方式是(进程占用 CPU 时间 / 总系统 CPU 时间) * 100。注意，这是瞬时值，不是平均值。一个 CPU 密集型进程跑满一个核心，这里会显示接近 100%，而不是 25%（四核机器）。
• %MEM：进程使用的物理内存占总可用内存的百分比。计算基准是MemTotal - MemFree - Buffers - Cached（即实际可用内存），不是MemTotal。所以即使%MEM加起来超过 100%，也不代表内存溢出，只是计算口径不同。
• VSZ（Virtual Size）：进程使用的虚拟内存总量（KB）。包括代码段、数据段、堆、栈、以及所有 mmap 映射的内存（如共享库、文件映射）。它不代表真实物理内存占用，一个进程 VSZ 可能高达几个 GB，但 RSS 只有几十 MB。
• RSS（Resident Set Size）：进程当前实际驻留在物理内存中的字节数（KB）。这才是你该关心的“真实内存占用”。top默认显示的RES列，就是 RSS。
• TTY：进程关联的控制终端。?表示没有关联终端（守护进程），pts/0表示通过 SSH 登录的伪终端，console表示本地控制台。这是判断进程是前台交互还是后台服务的关键。
• STAT：进程状态码。这是最需要死记硬背的一列，因为它用单个字母组合表达复杂状态：
  • R：Running or Runnable（正在运行或等待 CPU）
  • S：Sleeping（可中断睡眠，等待事件如 I/O）
  • D：Uninterruptible Sleep（不可中断睡眠，通常在等待磁盘 I/O，kill -9也无法唤醒）
  • Z：Zombie（僵尸进程，子进程已退出，但父进程未调用wait()回收）
  • <：High-priority（高优先级，nice 值为负）
  • N：Low-priority（低优先级，nice 值为正）
  • s：Session leader（会话领导者）
  • +：Foreground process group（前台进程组）
• STARTED：进程启动的时间（月-日 或 HH:MM）。注意，它显示的是进程创建时间，不是你执行ps的时间。
• TIME：进程自启动以来，占用 CPU 的总时间（格式为MM:SS）。这是累计值，不是瞬时值。一个跑了三天的数据库进程，TIME 可能只有120:33，说明它大部分时间在等待 I/O，而非计算。
• COMMAND：启动该进程的完整命令行。但要注意，有些进程（尤其是 daemon）会主动修改自己的argv[0]，所以这里显示的可能是mysqld，而不是真实的/usr/bin/mysqld --defaults-file=/etc/mysql/my.cnf。

理解这些字段，你才能读懂ps的输出。比如，看到一个进程 STAT 是D，你就知道它卡在 I/O 上，不该kill；看到Z，你就知道要检查它的父进程是否健在；看到%CPU很高但TIME很小，说明这是个刚启动的短命进程，不是长期负载源。

3. 核心参数详解与实战组合技

3.1 必须掌握的“黄金六参数”及其底层逻辑

别被man ps里上百个参数吓住。90% 的日常需求，6 个参数就能覆盖。关键是理解它们的组合逻辑，而不是死记硬背。

1. a(all with tty)：显示所有与终端关联的进程。它不显示systemd、kthreadd这类内核线程，也不显示没有 TTY 的守护进程（如nginxmaster）。它的作用是“聚焦于你当前会话能看到的进程”。ps a输出通常很短，适合快速确认“我这个终端里有哪些后台作业”。

2. u(user-oriented)：启用用户友好的输出格式。它强制显示USER、%CPU、%MEM、VSZ、RSS、TTY、STAT、STARTED、TIME、COMMAND这 10 列，并且按USER排序。u的核心价值在于标准化视图。无论你用ps aux还是ps -ef，u都保证你看到的是同一套业务指标。没有u，ps ax只显示PID、TTY、TIME、CMD，对排查内存、CPU 问题毫无帮助。

3. x(without controlling tty)：显示所有没有控制终端的进程。这是ps区分“前台交互进程”和“后台服务进程”的关键开关。ps ax=ps a+ps x，合起来就是“所有进程”。x的存在，让你一眼识别出sshd、dockerd、crond这些真正的系统服务。ps aux中的x，正是让你看到nginxworker、redis-server这些守护进程的必要条件。

4. e(environment)：显示进程的环境变量。ps e会将每个进程的environ文件内容（通常是几百行）全部打印出来。这在调试“为什么我的脚本在 cron 里跑不通？”时是终极武器。cron 启动的进程，环境变量极其精简（几乎没有PATH、HOME），而你在终端里echo $PATH看到的是一长串。ps -p 12345 -e就能直接对比两者差异。

5. f(forest)：以 ASCII 树状图显示进程父子关系。ps f的输出，会让你瞬间理解systemd如何孵化sshd，sshd如何 fork 出你的bash，bash又如何启动vim或python。这对排查“为什么我 kill 了主进程，子进程还在？”至关重要。f的底层实现，是读取/proc/[pid]/stat中的PPID字段，然后递归构建树。ps auxf是最常用的组合，既全面又清晰。

6. -o(user-defined output)：自定义输出字段。这是ps从“查看工具”升级为“数据提取工具”的分水岭。-o后跟逗号分隔的字段名，如-o pid,ppid,comm,%cpu,%mem,vsz,rss,etime,args。etime（elapsed time）是进程启动至今的秒数，比STARTED更精确；args是完整的命令行参数，比comm（仅命令名）信息量大得多。-o的强大，在于它可以和--sort、--no-headers完美配合，生成可被awk、grep处理的纯数据流。

注意：ps aux中的a、u、x是互斥的吗？不是。它们是叠加的。a和x一起用，才构成“所有进程”；u是格式开关，和a、x无关。你可以ps u（只看自己的进程，用户格式），也可以ps x（只看无 TTY 进程，默认格式），ps aux是三者叠加的最优解。

3.2 实战场景驱动的参数组合与避坑指南

光知道参数没用，得知道在什么场景下用哪一组。以下是我在生产环境踩过坑、验证过的 7 个高频组合。

场景一：快速定位“吃 CPU”的罪魁祸首

错误做法：ps aux | sort -k3 -r | head -10
问题：sort是按字符串排序，%CPU列是文本，99.9会被排在100.0前面（因为1<9），结果错乱。

正确做法：ps -eo pid,ppid,%cpu,%mem,comm,args --sort=-%cpu | head -10
解析：

• -e：所有进程
• -o：自定义输出，只取关键字段，避免COMMAND列过长干扰
• --sort=-%cpu：按%cpu数值降序排列（-表示降序）
• head -10：取前 10 名

实操心得：--sort必须跟在-o后面，且字段名必须和-o中定义的一致。%cpu是数值字段，comm是字符串字段，--sort=-comm就是按字母倒序排。我试过用ps aux --sort=-%cpu，结果发现ps的 BSD 风格--sort支持有限，有时不生效，所以强烈推荐 System V 风格的-eo+--sort组合，稳定可靠。

场景二：查找特定名称的进程并获取其 PID

错误做法：ps aux | grep nginx | grep -v grep
问题：grep nginx本身也会出现在ps结果里，形成“自我匹配”，需要grep -v grep过滤，丑陋且易错。

正确做法：pgrep -f "nginx"或pidof nginx
但如果你坚持用ps：ps -eo pid,comm,args | awk '$3 ~ /nginx/ {print $1}'
解析：

• -eo pid,comm,args：只输出 PID、命令名、完整参数三列
• awk：$3是第三列（args），~ /nginx/是正则匹配，{print $1}打印第一列（PID）

避坑技巧：ps -C nginx -o pid=中的-C是按命令名精确匹配（comm字段），但comm通常只有nginx，没有路径和参数，所以ps -C nginx只能匹配 master 进程，匹配不到nginx: worker process。因此，用-eo args+awk正则匹配，才是最通用、最准确的方法。

场景三：监控一个进程的内存增长趋势

需求：一个 Java 应用疑似内存泄漏，需要每 5 秒记录一次 RSS。

命令：while true; do ps -p $(pgrep -f "java.*myapp") -o rss=; sleep 5; done
解析：

• pgrep -f "java.*myapp"：用正则找到包含java和myapp的进程 PID
• ps -p [PID] -o rss=：-p指定 PID，-o rss=中的=表示不输出列名，只输出数值，方便后续处理
• while true; do ...; sleep 5; done：无限循环，5 秒间隔

注意事项：rss=的=必须紧贴字段名，不能有空格。ps -p 12345 -o rss =会报错。另外，pgrep可能返回多个 PID，ps -p只接受一个，所以这个命令在多实例场景下会失败。更健壮的写法是for pid in $(pgrep -f "java.*myapp"); do ps -p $pid -o pid,rss=; done。

场景四：查看进程打开的文件和网络连接（需结合 lsof）

ps本身不显示文件描述符，但它能给你 PID，这是lsof的输入。ps和lsof是黄金搭档。

步骤：

1. ps aux | grep myapp找到 PID
2. lsof -p [PID]查看该进程打开的所有文件、socket
3. lsof -i -p [PID]只看网络连接

为什么不用ps直接看？因为ps的设计目标是轻量、快速、内核态。读取/proc/[pid]/fd目录并解析每个 fd 指向的文件，开销远大于读取stat和status。lsof就是为此而生的专业工具。ps的角色，是快速定位目标，lsof的角色，是深度剖析。

场景五：找出所有僵尸进程（Zombie）及其父进程

命令：ps aux | awk '$8 ~ /Z/ {print $2, $3, $8, $11}'
解析：

• $8是STAT列（ps aux的第 8 列）
• $2是PID，$3是%CPU（这里其实没用，但为了格式统一），$11是COMMAND
• awk筛选STAT包含Z的行

更进一步：ps -eo pid,ppid,stat,comm | awk '$3 ~ /Z/ {print "PID:", $1, "PPID:", $2, "CMD:", $4}'
关键点：Z状态的进程，其PPID就是它的父进程。如果父进程已退出，PPID会变成1（init或systemd），这时僵尸进程会被init自动回收。如果PPID是一个非 1 的数字，说明父进程还活着但没调用wait()，这就是需要修复的 bug。

场景六：查看进程的启动时间和运行时长

命令：ps -eo pid,comm,lstart,etime,args --sort=-etime | head -5
解析：

• lstart：进程启动的完整日期时间（YYYY-MM-DD HH:MM:SS）
• etime：进程启动至今的秒数（elapsed time），精度到秒
• --sort=-etime：按运行时长降序，最长的在最上面

对比STARTED：ps aux的STARTED列只显示月-日或 HH:MM，对于当天启动的进程，无法区分先后；lstart和etime则提供了精确到秒的依据。etime特别适合写监控脚本，比如“找出运行超过 3600 秒的进程”。

场景七：过滤特定用户的进程并按 CPU 排序

命令：ps -U www-data -o pid,%cpu,%mem,comm,args --sort=-%cpu
解析：

• -U www-data：只显示有效用户为www-data的进程（注意是-U，不是-u；-u是显示指定用户的进程，但格式是ps -u www-data，不带-o）
• -o：自定义输出
• --sort=-%cpu：按 CPU 降序

为什么用-U而不是grep USER？因为grep是文本匹配，ps -U是内核级过滤，效率更高，且不会因用户名出现在COMMAND里而误匹配。ps -U root永远只返回root用户的进程，绝对精准。

4. 深度实操：从零开始构建一个进程监控脚本

4.1 需求分析与脚本设计思路

假设你有一个 Web 服务mywebapp，部署在一台 4 核 8G 的服务器上。老板要求：“每天早上 9 点，邮件发一份报告，告诉我mywebapp进程的 CPU、内存使用率，以及它是否还在运行。” 这看起来简单，但涉及ps的核心能力：精确匹配、字段提取、数值计算、定时触发。

设计思路：

• 第一步：精准定位进程。不能用ps aux | grep mywebapp，因为grep会污染结果。要用pgrep或ps -C，但ps -C不可靠，所以用pgrep -f。
• 第二步：提取关键指标。%CPU和%MEM是百分比，但ps输出的是字符串，需要awk转换为数值。
• 第三步：判断进程状态。ps返回的行数为 0，说明进程不存在。
• 第四步：格式化输出并邮件发送。用echo拼接，用mail命令发送。

4.2 完整脚本与逐行注释

#!/bin/bash # 脚本名：check_mywebapp.sh # 功能：检查 mywebapp 进程状态，并发送邮件报告 # 1. 定义变量 APP_NAME="mywebapp" EMAIL="admin@example.com" HOSTNAME=$(hostname) DATE=$(date '+%Y-%m-%d %H:%M:%S') # 2. 获取进程 PID（使用 pgrep -f，确保匹配完整命令行） PIDS=$(pgrep -f "$APP_NAME" 2>/dev/null) # 3. 初始化指标 CPU_USAGE=0 MEM_USAGE=0 PROCESS_COUNT=0 # 4. 如果找到进程，则提取指标 if [ -n "$PIDS" ]; then # 将 PIDS 拆分成数组，遍历每个 PID for pid in $PIDS; do # 使用 ps -p 获取单个进程的 %cpu 和 %mem，-o 指定只输出数值，-n 表示不显示标题 # 注意：ps -p 的输出是 " 12.3" 这样的字符串，前面有空格，awk 会自动处理 cpu_val=$(ps -p "$pid" -o %cpu= 2>/dev/null | awk '{printf "%.1f", $1}') mem_val=$(ps -p "$pid" -o %mem= 2>/dev/null | awk '{printf "%.1f", $1}') # 累加（如果是多实例） CPU_USAGE=$(echo "$CPU_USAGE + $cpu_val" | bc -l) MEM_USAGE=$(echo "$MEM_USAGE + $mem_val" | bc -l) PROCESS_COUNT=$((PROCESS_COUNT + 1)) done # 计算平均值（如果有多实例） if [ "$PROCESS_COUNT" -gt 1 ]; then CPU_USAGE=$(echo "$CPU_USAGE / $PROCESS_COUNT" | bc -l | awk '{printf "%.1f", $1}') MEM_USAGE=$(echo "$MEM_USAGE / $PROCESS_COUNT" | bc -l | awk '{printf "%.1f", $1}') fi else # 进程未找到 CPU_USAGE="N/A" MEM_USAGE="N/A" PROCESS_COUNT=0 fi # 5. 构建邮件内容 MAIL_BODY="主机: $HOSTNAME 时间: $DATE 应用: $APP_NAME 进程数量: $PROCESS_COUNT CPU 使用率: $CPU_USAGE% 内存使用率: $MEM_USAGE% $(ps -eo pid,%cpu,%mem,comm,args --sort=-%cpu | grep "$APP_NAME" | head -5)" # 6. 发送邮件（使用 mail 命令，需提前配置好 sendmail 或 postfix） echo "$MAIL_BODY" | mail -s "【监控】$APP_NAME 进程状态报告 - $HOSTNAME" "$EMAIL" # 7. 日志记录（可选） echo "[$DATE] $APP_NAME: $PROCESS_COUNT processes, CPU=$CPU_USAGE%, MEM=$MEM_USAGE%" >> /var/log/mywebapp_monitor.log

关键细节解释：

• pgrep -f "$APP_NAME"：-f参数让pgrep匹配完整的命令行参数，比ps -C更可靠。2>/dev/null忽略pgrep找不到时的错误输出。
• ps -p "$pid" -o %cpu=：-p指定单个 PID，-o %cpu=中的=是精髓，它让ps只输出数值，不带列名和空格，awk处理起来干净利落。
• bc -l：Linux 下做浮点运算的命令。echo "12.3 + 45.6" | bc -l输出57.9。awk本身也支持浮点，但bc更通用。
• $(ps ... | grep ... | head -5)：这部分是“锦上添花”，在邮件正文里附上ps的原始 top5 数据，方便人工二次确认。grep "$APP_NAME"是安全的，因为此时ps输出已经不含grep进程了。

4.3 如何部署为定时任务

1. 赋予执行权限：chmod +x /path/to/check_mywebapp.sh
2. 测试脚本：手动运行./check_mywebapp.sh，检查邮件是否收到，日志是否写入。
3. 添加到 crontab：

   # 编辑当前用户的 crontab crontab -e # 添加以下行（每天早上 9:00 执行） 0 9 * * * /path/to/check_mywebapp.sh

4. 邮件配置：确保系统已安装并配置好mail命令。Ubuntu/Debian 上sudo apt install mailutils，CentOS/RHEL 上sudo yum install mailx。配置/etc/ssmtp/ssmtp.conf或使用postfix。

实操心得：我第一次部署类似脚本时，ps -p命令在cron环境下失败了。原因是cron的PATH环境变量非常精简，不包含/bin或/usr/bin。解决方案是在脚本开头加上PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin，或者在crontab里写绝对路径0 9 * * * /usr/bin/ps -p ...。永远不要假设cron环境和你的终端环境一致。

5. 常见问题、排查技巧与独家避坑经验

5.1 “ps aux” 为什么有时看不到某些进程？

这是一个高频困惑。原因有三：

1. 权限问题：你是普通用户，而目标进程是root启动的。ps aux会显示root进程，但如果你用ps -U nobody，就看不到root的。解决方法：sudo ps aux，或用ps -eo user,pid,comm | grep root。
2. 进程生命周期太短：ps是快照，ls /proc是瞬间。一个echo "hello" | wc -l进程，从启动到结束可能不到 1ms，ps aux几乎不可能捕获到。解决方法：用strace -f -e trace=execve your_command跟踪 exec 调用，或用while true; do ps aux | grep target; sleep 0.1; done高频轮询（仅调试用）。
3. 进程被隐藏（极少见）：某些 Rootkit 或安全加固工具（如grsecurity）会 patch 内核，让特定进程对ps不可见。这不是ps的 bug，而是内核行为被修改。此时ls /proc也看不到对应 PID 目录。解决方法：检查系统是否启用了特殊安全模块，或用cat /proc/sys/kernel/pid_max等基础命令交叉验证。

5.2 “STAT” 列里的 “<”、“N”、“+” 是什么意思？怎么影响进程？

• <（High-priority）：进程的nice值为负（如-5），意味着它比普通进程（nice=0）有更高的 CPU 调度优先级。ps用<标记，提醒你“这个进程很霸道，会抢 CPU”。renice -n -10 12345就能让 PID 12345 变成<状态。
• N（Low-priority）：nice值为正（如+10），调度优先级低，常用于ionice或nice启动的批处理任务，避免影响前台交互。ps用N标记，是善意的提醒：“这个进程很谦让”。
• +（Foreground process group）：表示该进程属于当前终端的前台进程组。Ctrl+C只会杀掉前台进程组里的进程。ps用+标记，是你理解job control（作业控制）的关键。fg、bg、jobs命令，都是在操作这个+组。

影响：这些标记本身不改变进程行为，但它们是内核调度器决策的依据。一个<进程在 CPU 竞争激烈时，会获得更多时间片；一个N进程，即使 CPU 空闲，也可能被延迟调度。ps显示它们，是为了让你“看见”调度策略。

5.3 为什么ps -p 12345有时返回空，但ls /proc/12345却存在？

这是ps和/proc文件系统的微妙差异。

• ls /proc/12345存在，只说明内核里还有一个task_struct对象，PID 12345 还“挂着”。
• ps -p 12345返回空，说明这个进程的状态是Z（Zombie）或者T（Stopped），而ps的默认行为（尤其在 BSD 风格下）可能不显示这些状态，或者显示但COMMAND列为空。

验证方法：

# 查看详细状态 cat /proc/12345