shutil.disk_usage返回字节值，需转换为GB并处理异常；Windows用盘符、Linux用挂载点；注意Linux预留空间导致free不准，建议用os.statvfs获取df一致的可用空间。
shutil.disk_usage 返回的是字节，不是GB或MB
直接打印 shutil.disk_usage(path) 的返回值会看到三个大整数，比如 (123456789012, 9876543210, 113580245802)，分别对应 total、used、free —— 全是字节。不转换就展示，用户根本没法直观判断是否快满了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
shutil.disk_usage(path).free获取空闲字节数，再除以1024**3转 GB（注意不是1000**3），保留 1 位小数更实用 - Windows 下路径必须带盘符，如
"C:\"；Linux/macOS 用挂载点如"/"或"/home"，传入不存在的路径会抛OSError - 别对文件调用，只支持目录或挂载点——传入
"./test.txt"会报FileNotFoundError
监控时要处理 PermissionError 和 OSError
在容器、受限环境或某些挂载点（如 /proc、/sys）上调用 shutil.disk_usage 可能触发 PermissionError 或 OSError: [Errno 75] Value too large for defined data type（尤其在旧内核或 NFS 挂载上）。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 必须用
try/except包裹，捕获OSError和PermissionError（后者是OSError子类，但显式写出来更清晰） - 不要静默吞掉错误——至少记录警告日志，比如用
logging.warning("skip path %s: %s", path, e) - 若需批量检查多个路径，单个失败不影响其余路径继续执行
定时检查别用 time.sleep() 硬等，优先考虑 schedule 或 threading.Timer
写个 while True + time.sleep(60) 最简单，但阻塞主线程、无法优雅退出、信号响应差（比如 Ctrl+C 可能卡住）。生产环境容易出问题。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 轻量需求用
schedule库：schedule.every(5).minutes.do(check_disk, path="/")，主循环里跑schedule.run_pending() - 需要并发或精确控制生命周期，用
threading.Timer实现可取消的周期任务 - 避免在循环里反复创建新线程或进程——资源泄漏风险高
- 检查间隔别设太短（如 1 秒），
disk_usage是系统调用，频繁触发无意义且增加负载
free 值不准？可能是 reserved space 或 df 显示差异
Linux 下 root 用户默认有 5% 的磁盘空间预留（可通过 tune2fs -l /dev/sda1 | grep "Reserved block count" 查），shutil.disk_usage 返回的 free 是普通用户可见空间，而 df 默认显示的是包括 reserved 的 available 字段（推荐对比这个）。所以你看到 Python 返回的 free 比 df -h 的 Avail 少，大概率是这个原因。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 监控阈值建议按
free / (total - reserved)算使用率，而不是used / total - 跨平台脚本中，Windows 没 reserved 概念，Linux 需注意：可用
os.statvfs(path).f_bavail * os.statvfs(path).f_frsize获取真正可用字节数（即df的 Avail） - 如果必须和运维看的
df对齐，优先用f_bavail，而非shutil.disk_usage的free
实际部署时最容易忽略的是 reserved space 导致的告警误触发，以及没做异常捕获导致整个监控进程崩溃。这两个点不处理，脚本上线第一天就可能失联。
