psutil.cpu_percent() 首次调用返回0.0是因无前序基准，需至少调用两次且间隔≥0.1秒；推荐用interval=1阻塞采集或预热后正式采集。
psutil.cpu_percent() 为什么第一次调用总是返回 0.0？
因为 psutil.cpu_percent() 是基于采样间隔的差值计算，首次调用时没有前序基准，只能返回 0。这不是 bug，是设计使然。
实操建议：
- 必须至少调用两次，且间隔 ≥ 0.1 秒（官方建议最小 0.1s），第二次才开始有真实数值
- 常见错误：在单次循环里反复调用
psutil.cpu_percent(interval=0)，结果全是 0 或异常抖动 - 正确做法是固定间隔采集，例如：
psutil.cpu_percent(interval=1)—— 这会阻塞 1 秒并返回该秒内平均占用率 - 若想非阻塞采集，需先调用一次“预热”，等几秒后再正式采集，否则数据不可信
如何用 psutil 快速抓取高内存进程快照？
别遍历所有进程再排序——太慢，且可能漏掉瞬时峰值。直接按 memory_info().rss 取 top N 最稳。
实操建议：
- 用
psutil.process_iter(['pid', 'name', 'memory_info', 'cpu_percent'])指定字段，避免默认加载全部信息拖慢速度 - 过滤掉系统空闲进程（如
systemd、kthreadd）和已僵死进程（p.status() == psutil.STATUS_ZOMBIE） - 按
p.memory_info().rss排序后取前 5，比按 %mem 更反映真实内存压力（RSS 是实际物理内存占用） - 注意：Linux 下
memory_percent()基于总内存计算，容器环境可能不准；优先信rss字节数
飞书机器人发告警时，JSON payload 哪些字段容易被忽略？
飞书 Webhook 对 msg_type 和 content 结构极其敏感，错一个 key 就 400，但错误提示极不明确。
实操建议：
- 必须设
"msg_type": "post"，不是"text"（后者不支持加粗/列表） -
content里要嵌套"zh_cn"，再包"title"和"content"；漏掉zh_cn层直接报错 - 进程列表要用
"tag": "text"+"text"包裹每行，不能直接放数组——飞书不认 Python list - 示例关键段：
{"msg_type": "post", "content": {"zh_cn": {"title": "内存超限告警", "content": [[{"tag": "text", "text": "PID: 1234 | python3 | RSS: 1.2G"}]]}}}
定时监控脚本跑着跑着就卡住或漏告警？检查这三点
不是代码逻辑问题，大概率是资源或权限卡点。
实操建议：
- 检查
/proc权限：容器中运行时，若没加--privileged或cap_add: [SYS_PTRACE]，psutil.Process().memory_info()会静默失败（返回空或抛AccessDenied） - 避免用
time.sleep()硬等——Python 的 GIL 在高 CPU 场景下可能导致 sleep 实际延迟远超预期；改用psutil.cpu_percent()自带的 interval 更可靠 - 日志别只打屏：漏掉异常时根本不知道哪崩了。至少把
except Exception as e:写进文件，路径用绝对路径如/var/log/memwatcher.log，避免相对路径在 crond 下失效
ps aux --sort=-%mem 手动核对过才敢信——不同统计口径（比如是否含共享内存页）会导致数字差 10%～30%，线上定位问题时这个偏差很致命。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
