应使用shutil.disk_usage()而非os.statvfs()，因其跨平台、字段清晰（total/used/free均为字节值），且避免Linux reserved blocks导致的误报；需传入真实路径、前置校验存在性，并配合异常处理与动态阈值预警。
磁盘空间检查用 shutil.disk_usage() 而不是 os.statvfs()
Linux/macOS 下很多人直接用 os.statvfs()，但它在 Windows 上不可用，且返回单位不直观；shutil.disk_usage() 跨平台、字段清晰（total/used/free 都是字节数），推荐作为统一入口。
注意：它只接受路径字符串，不能传文件对象或符号链接目标——如果传了软链接，默认检查的是链接所在目录的挂载点，不是目标路径所在磁盘。实际使用前建议先用 os.path.realpath() 归一化路径：
import shutil import os <p>path = "/var/log" real_path = os.path.realpath(path) usage = shutil.disk_usage(real_path)
常见错误是传了不存在的路径，会抛 FileNotFoundError；建议包裹 try/except 并 fallback 到根路径检查。
清理策略要区分“可删”和“不可删”，别硬删 /var/log/journal 以外的日志
自动清理最危险的点不是脚本没跑，而是删错了东西。系统日志（如 journald）、应用临时文件、缓存目录（/tmp、~/.cache）可以设规则清理；但 /var/lib/docker、/home/*/data 这类必须人工确认，脚本里应默认跳过。
立即学习“Python免费学习笔记（深入）”；
实操建议用白名单机制，只处理明确知道结构的目录：
-
/var/log/*.log：按修改时间 + 文件大小双条件删除（例如：>7 天且 >10MB） -
/tmp/*：只删 3 天前且非正在被进程打开的文件（用lsof或psutil检查） -
/var/cache/apt/archives/*.deb（Debian/Ubuntu）：apt 清理专用命令更安全，调用apt-get clean而非直接 rm
别写 rm -rf /var/log 这种通配，logrotate 已在运行时再干预，容易冲突。
预警触发阈值设成“已用率 >90%”比“剩余
固定剩余空间阈值（比如 free < 5 * 1024**3）在大磁盘（如 10TB）上会严重滞后——95% 已用时还剩 500GB，但可能只剩 1 小时就写满；而百分比阈值能提前暴露趋势。
但要注意：某些挂载点（如 /boot）容量小（通常 512MB–2GB），用百分比反而太敏感。稳妥做法是分场景设置：
- 根分区（
/）、数据盘（/data）：用usage.used / usage.total > 0.9 -
/boot：用绝对剩余usage.free < 200 * 1024**2（200MB） - 所有检查都加 5% 缓冲——达到阈值后只发预警，真正清理动作等下一个周期再执行，避免抖动误触发
发邮件预警必须配置 SMTP 认证，别用本地 sendmail
很多脚本直接调 subprocess.run(["mail", ...])，但在 Docker 容器或最小化系统里 sendmail 根本不存在，且无法携带认证信息。Python 自带 smtplib 更可控。
关键点：
- SMTP 服务器地址、端口、账号密码必须从环境变量读（
os.getenv("ALERT_SMTP_HOST")），别硬编码 - 使用 TLS（端口 587）而非 SSL（465），后者在新版 Python 中需额外参数
context=ssl.create_default_context() - 邮件正文必须包含具体路径、当前已用率、最近清理时间戳——方便运维快速定位，而不是只写“磁盘快满了”
容易漏的是：没设超时（timeout=10），网络卡顿时脚本阻塞；也没做重试（最多 2 次），一次发信失败就静默丢弃。
磁盘清理逻辑本身不复杂，难的是边界判断——哪个目录真能删、删到什么程度不影响服务、预警信息是否足够让值班人立刻响应。这些没法靠通用库解决，得贴着你的实际部署结构一条条对齐。
