这里要读的是/proc/[pid]/stat里的第10个字段（minflt）和第12个字段（majflt）来拿累计值，不是第15、16个字段。原因也不复杂：第2个字段是用括号包起来的进程名，解析时很容易把后面的字段位置带偏，所以需要先跳过前9个字段再提取目标值。更稳妥的做法，是优先用std::istringstream来解析，或者直接使用getrusage(RUSAGE_SELF, &ru)，可靠性会更高。
直接读 /proc/[pid]/stat 获取累计值
Linux内核把每个进程的软缺页（minor）和硬缺页（major）次数，实时记录在 /proc/[pid]/stat 文件里，不是靠日志或命令临时计算出来的。关键字段是第10个（min_flt）和第12个（maj_flt），注意不是第15、16——因为第2个字段是括号包裹的进程名（如 (bash)），它会吃掉一个空格，导致后续字段整体右移。
真正上手时，前9个字段一定要先跳过去，然后再去拿第10项和第12项。更稳妥的做法，是用 std::istringstream 配合 >> 做提取：它会自动略过多余空白，处理起来省心不少。相反，strtok 或者简单的 split(' ') 看着省事，实际很容易踩坑；一旦碰到 (ja va -jar app.jar) 这种内部带空格的 comm 字段，后面的字段位置立刻就乱了。
min_flt：软缺页累计次数，页已在内存（如共享库、已缓存文件），只需建立映射maj_flt：硬缺页累计次数，页不在内存，必须从磁盘加载（触发I/O）- 字段值是
unsigned long，运行数月也不会溢出，但做差值时要用无符号减法，避免回绕误判负增长
用 getrusage(RUSAGE_SELF, &ru) 更轻量可靠
比解析文本文件更推荐的方式是调用 POSIX 接口 getrusage，它直接返回结构体字段，无需字符串处理，也不依赖 /proc 是否挂载或权限。
头文件是 struct rusage ru 后检查返回值是否为 0；ru.ru_minflt 和 ru.ru_majflt 就是你要的两个计数，类型为 long。
- 该调用只反映“调用时刻之前”的累计值，不能替代采样差值——想算每秒速率，仍需自己缓存上一次值
- 查子进程要用
RUSAGE_CHILDREN，但仅对已wait()过的子进程有效 - 在容器或严格限制
/proc访问的环境中，getrusage是唯一可行路径
为什么不能只看一次读数？
所有这些接口返回的都是自进程启动以来的累计值，不是“每秒次数”。常见错误是读一次就除以1秒，以为得到速率——这是无效操作，数值毫无意义。
要获得真实每秒缺页频率，必须至少两次采样，并用单调时钟（如 clock_gettime(CLOCK_MONOTONIC)）精确计算时间差 dt，再做除法：(current - previous) / dt_sec。
- 别用
sleep(1)或std::this_thread::sleep_for(1s)控制间隔——调度延迟会导致实际间隔远超1秒，速率失真严重 - 字段变化可能极快（比如刚
mmap大文件），也可能长时间为 0；单次读数无法区分“安静”和“卡死” - 若两次读数相同，且
dt极小（如因调度卡顿落在同一时钟滴答），结果为 0 是合理行为，不是 bug
别被 /proc/meminfo 或 vmstat 带偏
/proc/meminfo 里的 Pgpgin/Pgpgout 是页输入/输出总量，和缺页中断无关；vmstat 的 si/so 是交换区换入/换出页数，只覆盖硬缺页中涉及 swap 的部分，漏掉文件映射、匿名页分配等大量场景。
它们适合系统级粗略观察，但定位具体进程的缺页行为时，精度和归属都不可靠——vmstat 不告诉你哪个 PID 在触发，/proc/meminfo 更不区分 minor/major。
- 想确认某进程是否频繁缺页，必须绑定到它的 PID，走
/proc/[pid]/stat或getrusage - 如果看到
min_flt暴涨而maj_flt几乎不动，大概率是堆分配、JIT 编译或 mmap 匿名页；maj_flt显著上升才真正提示 I/O 压力 - 字段偏移、括号解析、单调时钟、无符号差值——这四个点任何一个出错，数据就废了，不是“差不多”，而是完全不可信
