psutil.Process().memory_info() 返回包含rss和vms等字段的命名元组，是内存使用绝对值而非增量，需自行计算差值才能判断增长量，直接使用会导致误判内存泄漏。
psutil.Process().memory_info() 返回什么，为什么不能直接当内存增长值用
它返回的是一个命名元组，包含 rss（常驻集大小）和 vms（虚拟内存大小）等字段，但这些是**绝对值**，不是增量。直接记录 rss 看趋势没问题，但若想算“增长了多少 MB”，必须自己做差值计算——否则你会看到一条直线上升的曲线，其实只是进程启动后内存自然驻留的结果。
常见错误现象：每秒采集一次 rss，画图发现从 50MB 涨到 120MB 就报警，结果发现是加载配置、初始化缓存导致的正常行为，根本不是泄漏。
- 只看单次
rss值容易误判；要观察连续 10~30 秒的斜率或累计增幅 -
memory_info()在 Windows 和 Linux 下语义一致，但 macOS 的rss可能含压缩内存，数值偏低且波动大 - 如果进程 fork 了子进程，
rss不包含子进程内存，得用children(recursive=True)手动加总
怎么稳定采样而不拖慢被监控进程
psutil 的 Process.memory_info() 调用本身开销不大（微秒级），但高频轮询（比如 100ms 一次）会显著增加系统调用次数，在负载高的机器上反而干扰目标进程调度。
使用场景：你不是在压测，而是在长期观测服务稳定性，所以采样节奏比精度更重要。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 生产环境建议间隔 ≥ 2 秒；若需捕捉短时峰值，可配合突发采样策略（例如检测到 3 秒内增幅 >10MB，临时切到 500ms 采样 10 次）
- 避免在主线程里阻塞式轮询；用
threading.Timer或asyncio.call_later更轻量 - 别用
psutil.process_iter()全局扫描找进程——它每次遍历所有进程，开销远大于直接用psutil.Process(pid)
记录数据到文件时，时间戳和格式怎么选才方便后续分析
很多人用 time.time() 写浮点秒，看着精确，但 Python 默认 float 是双精度，写进 CSV 后可能变成 1718234567.1234567，用 pandas 读的时候类型推断出错，或者时区混乱。
性能影响：字符串格式化比直接写数字慢，但日志 IO 本身才是瓶颈，这点差异可忽略。
- 用
datetime.now().isoformat()，生成类似"2024-06-12T14:23:45.123"的字符串，无歧义、可排序、pandas 开箱即用 - 每行一条记录，字段用逗号分隔：
timestamp, pid, rss_bytes, vms_bytes；不要用 JSON 行，解析成本高且不易用 shell 工具快速查看 - 文件名带上日期，如
memlog_20240612.csv，避免单文件无限增长导致追加变慢或损坏后全丢
OSError: [Errno 3] No such process 错误怎么安静处理
这是最常遇到的异常：你拿到一个 pid 开始监控，但目标进程在下次采样前已退出。不捕获就崩，但全吞掉又会丢失“进程意外终止”的信号。
关键点在于区分“进程结束”和“暂时不可读”。Linux 下 /proc/PID 目录消失才真死了；Windows 上 pid 复用快，更易误判。
- 只对
OSError中errno == 3做静默处理，其他错误（如权限不足errno==13）仍要抛出 - 捕获后记录一行日志：
f"Process {pid} exited at {datetime.now().isoformat()}"，而不是啥也不做 - 别在 except 里重试 new Process(pid)——pid 可能已被复用，你会监控到另一个完全无关的进程
