shutil.disk_usage返回字节值，需用10243换算GiB或10003换算GB；应校验路径对应真实挂载点，避免虚拟文件系统；告警需加冷却时间或连续N次触发；Windows路径须规范为"C:"格式。
shutil.disk_usage 返回的是字节，别直接当GB用
调用 shutil.disk_usage 得到的 total、used、free 全是字节（int），不是 GB 或 MB。直接除以 1000 或硬写 / 1024 / 1024 / 1024 容易算错，尤其在 Linux 下部分工具按 1024 进制、部分按 1000 进制显示，导致预警阈值对不上。
实操建议：
- 统一用
1024 ** 3换算 GiB（二进制单位，和df -h默认一致） - 如果要和 Windows 资源管理器或某些监控系统对齐（显示为 GB），改用
1000 ** 3 - 预警逻辑建议基于「剩余空间占比」而非绝对值，避免小分区误报、大分区漏报
监控指定路径还是所有挂载点？选错路径会返回错误分区
shutil.disk_usage(path) 的 path 参数不一定要是根目录，但必须指向某个已挂载的文件系统。传入一个软链接、未挂载的挂载点、或跨 bind mount 的路径，可能返回上层文件系统的使用率，而不是你真正关心的分区。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
-
shutil.disk_usage("/mnt/data")返回的是/的数据（因为/mnt/data实际是 rootfs 的子目录，没独立挂载） -
shutil.disk_usage("/proc")报OSError: [Errno 75] Value too large for defined data type
实操建议：
- 先用
os.stat(path).st_dev和psutil.disk_partitions()匹配真实挂载点（需装psutil） - 更轻量的做法：只监控明确挂载的路径，比如
/、/home、/data，且确保这些路径在mount输出里单独成行 - 避免监控虚拟文件系统路径（
/proc、/sys、/dev/shm）
预警触发后怎么避免刷屏？加个冷却时间很关键
磁盘空间不会一秒涨一兆，但轮询脚本如果每 10 秒跑一次，一旦低于阈值，连续几分钟都在发告警，运维人员很快就会 mute 掉通知。
实操建议：
- 记录上次告警时间戳到本地文件（如
/tmp/disk_alert_last.txt），每次触发前检查间隔是否超过 30 分钟 - 用
time.time()+os.path.getmtime()判断，别依赖内存变量（脚本重启就丢） - 如果用 systemd timer 或 cron，直接控制执行频率（如每小时一次），但得接受“延迟发现”代价
- 可叠加“连续 N 次低于阈值”才告警，比单次判断更稳（适合日志盘缓慢增长场景）
Windows 下获取盘符信息要小心路径格式
在 Windows 上，shutil.disk_usage("C:") 会失败，报 FileNotFoundError；必须写成 "C:\" 或 r"C:" —— 少一个反斜杠或没转义，就找不到路径。
实操建议：
- 统一用
os.path.normpath("C:/")或pathlib.Path("C:/").resolve()标准化路径 - 遍历所有盘符时，用
string.ascii_uppercase拼接f"{d}:\"，再用os.path.isdir()过滤掉不存在的盘符 - 注意 U 盘/移动硬盘可能临时拔出，
disk_usage会抛FileNotFoundError，务必包try/except
真正难的不是取数，而是搞清你监控的那个 path 究竟属于哪个物理设备、有没有被 overlay 或 bind mount 隐形覆盖。很多“明明 df 显示还有 20%，脚本却报警”的问题，根源都在这里。
