psutil.cpu_percent(interval=1)是获取实时CPU使用率的跨平台首选，返回0.0–100.0浮点数，首次调用需等待interval时长，生产推荐interval=2或3，避免设为0或过小过大。
用 psutil 获取实时 CPU 使用率，别碰 os.system("top")
直接调系统命令解析文本既慢又不稳定，psutil 是跨平台、轻量、线程安全的首选。它返回的是浮点数（0.0–100.0），不是百分比字符串，也不需要自己除以核数——psutil.cpu_percent(interval=1) 默认就是全核平均值。
常见错误是把 interval 设成 0：那会立刻返回上次调用后的增量，几乎总是 0.0；设太小（如 0.1）会导致采样不准；设太大（如 5）则告警延迟严重。生产环境建议固定用 interval=2 或 interval=3，兼顾响应与平滑性。
- 首次调用必须等满 interval 才有有效值，所以脚本启动后需先 sleep 一次再采集
- 多进程环境下注意不要在子进程中重复调用，避免资源竞争
- 容器中运行时，
psutil能正确读取 cgroup 限制后的 CPU 使用率，无需额外适配
配置 SMTP 发邮件前，先验证 smtp.gmail.com 这类地址是否被防火墙拦截
很多内网服务器默认禁 outbound SMTP（端口 25/465/587），连不上就会卡住或超时。别急着写 smtplib.SMTP_SSL，先手动 telnet 测试：
telnet smtp.gmail.com 587
如果连接失败，优先换企业邮箱（如 smtp.qiye.qq.com）或启用本地 ssmtp 转发，而不是硬改 timeout 参数。
立即学习“Python免费学习笔记（深入）”；
- Gmail 需开启「App Password」，不能用账号密码直连；QQ 企业邮箱支持普通密码但要求开启 SMTP 服务
-
smtplib.SMTP+starttls()比SMTP_SSL更通用，兼容更多服务商 - 邮件正文用纯文本即可，避免 MIME 多层封装——监控告警不需要 HTML 渲染
判断超限逻辑要防抖，避免每秒都发一封邮件
CPU 短时冲高（比如 10 秒内到 95%）很常见，直接触发就等于告警轰炸。得加「持续 N 次超过阈值」才发：
比如每 3 秒采一次，连续 3 次 ≥ 85%，才算真正异常。用一个长度为 3 的 list 记录最近值，每次 append 后 pop 左边旧值，然后 all(x >= 85 for x in history) 判断。
- 别用全局变量存历史，多线程下会错乱；封装成类或传参维护状态
- 阈值别写死，从环境变量读取（
os.getenv("CPU_ALERT_THRESHOLD", "85")），方便不同机器差异化配置 - 发完邮件后重置计数器，否则一次触发后永远满足条件
守护进程跑脚本时，nohup python monitor.py & 不够，得处理信号和日志轮转
后台运行后，标准输出默认写入 nohup.out，几天就几十 MB，且 Ctrl+C 无法优雅退出。至少加两件事：
捕获 SIGTERM 关闭循环；用 logging.handlers.RotatingFileHandler 控制日志大小。否则某天发现磁盘满了，根本查不到是谁写的日志。
- 别在循环里反复 open/close 日志文件，初始化时配好 logger 就行
- 邮件发送失败（如网络抖动）要记录 error 日志，但不抛异常中断主循环
- 加个
time.sleep(1)在采样间隔之后，避免空转吃光 CPU
最麻烦的其实是权限和路径：脚本里用相对路径读配置，放到 systemd 里跑就找不到文件；cron 启动时环境变量缺失导致 SMTP 认证失败。这些细节比逻辑本身更常导致上线失败。
