ps -al 显示的 pri 是已含 ni 影响的动态优先级，越小越先执行；ni 范围 -20~19，普通用户只能调高；top 修改需先启用 nice 列，renice 适合脚本化但不作用于线程。
ps -al 能看到 PRI 和 NI 两列
直接运行 ps -al 就能列出所有进程的完整属性，其中关键两列是：PRI（优先级）和 NI（nice 值）。注意：ps -l 只显示当前终端相关进程，通常看不到你刚启动的后台程序；ps -al 才是真正“全量”的查看方式。
常见误区是以为 PRI 就是最终优先级——其实不是。PRI 列显示的是内核调度用的“动态优先级”，它已经包含了 NI 的影响。Linux 实际调度时用的就是这个值，越小越早被 CPU 执行。
-
PRI默认基线是 80，但你看到的数字已经是80 + NI的结果（比如NI = 5→PRI = 85） -
NI是你能手动调整的部分，范围固定为-20到19，普通用户只能调高（即让NI变大、PRI变大、优先级变低） - 想快速过滤某个进程，比如叫
myapp，可用：ps -al | grep myapp
top 里按 r 修改前先确认当前值
进入 top 后按 r 修改 nice 值之前，务必先看清楚目标进程当前的 NI 和 PRI。因为 top 界面默认只显示部分列，可能没展开 NI —— 按 f 进入字段管理，用方向键选中 NICE（对应 NI），按空格启用，再按 q 返回。
否则你输完 PID 和新 NI 值后，根本没法验证是否生效，尤其当权限不足时（比如普通用户尝试设 NI = -5），top 会静默失败，界面无提示，NI 值也不变。
- 修改后立刻按
R（大写）刷新排序，让高优先级（低PRI）进程排到顶部 - 如果
NI没变，大概率是权限不够或输入了非法值（如-25或25，会被自动截断为-20或19） -
top中的PRI是实时计算值，不等于静态基线 80，别拿它反推原始NI
getpriority() 和 setpriority() 是系统调用级操作
如果你在写 C 程序并需要从代码里读写优先级，别依赖 shell 命令解析输出，直接用系统调用更可靠：
getpriority(PRIO_PROCESS, pid) 返回当前进程的 nice 值（不是 PRI）；setpriority(PRIO_PROCESS, pid, new_nice) 设置它。注意返回值：成功时 getpriority 返回 nice 值，失败返回 -1 并设置 errno；setpriority 成功返回 0，失败返回 -1。
- 普通进程调用
setpriority只能增大 nice 值（降低优先级），减小会失败（EPERM） -
pid = 0表示当前进程，不用查 PID - 这两个函数在
<sys></sys>里声明，链接时无需额外库
renice 命令适合批量或脚本化调整
比起 top 交互式修改，renice 更适合自动化场景。例如把所有属于用户 alice 的进程 nice 值统一设为 10：renice 10 -u alice。或者按进程名调整：renice 5 -n 5 -p $(pgrep nginx)（把 nginx 进程 nice 值设为 5，最多匹配 5 个）。
容易忽略的一点：renice 不会改变已运行线程的 nice 值——它只作用于指定的 PID 对应的主线程。多线程程序若需整体调整，得对每个线程 PID 单独调用，或改用 chrt 设置实时调度策略（那又是另一套机制了）。
另外，renice 的错误输出很安静：权限不足时只返回非零退出码，stdout/stderr 都不打印任何信息，脚本里必须检查 $? 才能发现失败。
