ps -al 能看到 PRI 和 NI，但需确保终端宽度足够；更稳妥的是用 ps -o pid,ni,pri,comm -p 显式指定字段，其中 PRI=80+NI（仅限普通进程），NI 才是可调的 nice 值。
ps -al 能看到真实 PRI 和 NI 吗
能，但默认列不全，ps -al 输出里确实包含 PRI 和 NI 两列，不过得确认终端宽度够、没被截断。更稳妥的做法是显式指定字段：ps -o pid,ni,pri,comm -p <pid></pid>，这样只输出你要的列，避免歧义。
注意：PRI 列显示的是“当前生效的优先级值”，即 80 + NI 的结果，不是原始默认值；NI 才是你能修改的那个 nice 值。
- 如果只查自己启动的进程，
ps -l就够用，但它只显示当前 shell 下的进程（含 bash 自身） - 查所有用户进程用
ps -el或ps -eo pid,uid,ni,pri,comm,args -
top默认显示的是NI（叫 “NI” 列），而 “PR” 列才是最终优先级（等价于PRI），别把这两个搞混
top 里 PR 和 NI 列哪个是真实优先级
PR 是真实优先级，NI 是 nice 值。top 启动后按 f 可以切换显示字段，确保勾选了 PR 和 NI —— 它们数值关系始终满足：PR == 80 + NI（普通用户进程）。
常见误解：看到 PR 是 90 就以为系统把优先级“调高”了，其实只是 NI=10 导致的，本质是降权；NI=-5 才真让 PR=75，提升调度权重。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- root 用户可设
NI为 -20，此时PR=60，是最高调度优先级 - 普通用户只能调高
NI（降低优先级），不能设负值，除非加sudo -
top里按r修改的是NI，不是直接改PR
getpriority() 系统调用返回什么值
getpriority() 返回的是 nice 值（NI），不是 PRI。它底层读取的就是 task_struct 里的 static_prio 经过偏移计算后的 nice 值，范围 [-20, 19]。
调用示例：int ni = getpriority(PRIO_PROCESS, pid); —— 如果返回 -1，得用 errno 判断是否真出错（比如权限不足或 pid 不存在），不能直接当成 NI=-1。
-
setpriority()同样操作的是 nice 值，不是 PRI - 内核中真正参与调度的是
static_prio字段，它 = 120 + nice（用于 CFS 调度器），但用户空间看到的PRI=80+NI是历史兼容映射 - 不要试图用
getpriority()反推 PRI：硬编码 80 是错的，实时优先级进程（如 SCHED_FIFO）走另一套逻辑
为什么 ps 显示的 PRI 有时不是 80+NI
因为有些进程不是普通分时调度类（SCHED_OTHER），比如实时进程（SCHED_FIFO 或 SCHED_RR）的 PRI 显示的是实时优先级（1–99），和 nice 无关。这时 NI 恒为 0，PRI 列显示的也不是 80+NI。
判断方法：ps -o pid,cls,pri,ni,comm，看 CLS 列 —— 若是 FF 或 RR，说明是实时进程，PRI 直接对应其调度优先级，nice 不起作用。
- 普通用户几乎接触不到实时进程，除非显式用
chrt设置 -
ps的PRI列是“调度器视角的优先级值”，不同调度类含义不同，不能一概套用 80+NI - 想确认某个进程是否受 nice 影响，先看
ps -o pid,cls,ni,comm，CLS是TS（time-sharing）才适用 nice 规则
ps -o pid,cls,ni,pri,comm -p <pid></pid> 看分类和数值，再结合 top -p <pid></pid> 动态观察 PR/NI 是否变化，最后用 cat /proc/<pid>/stat</pid> 查第 18 字段（priority）和第 19 字段（nice）—— 这两个才是内核实际存的值，绕过所有显示层换算。 
