直接用os.remove()删旧日志易出错，因权限、文件占用、路径空格、时区差异或logrotate并发操作导致OSError；应优先解析文件名时间戳、加try/except捕获异常、跳过空文件，并用glob+datetime精准匹配日期，清理前检查进程占用，推荐空间阈值触发式清理。
为什么直接用 os.remove() 删除旧日志容易出错
很多脚本会遍历日志目录，按文件修改时间排序后删掉最老的几个——这看似合理，但实际运行中常因权限、占用、路径空格或时区差异导致 OSError: [Errno 13] Permission denied 或误删正在写入的文件。更隐蔽的问题是：某些日志轮转工具（如 logrotate）可能在 Python 脚本执行期间正重命名或压缩文件，此时 os.stat().st_mtime 可能反映的是原始文件时间，而非当前活跃日志的时间戳。
实操建议：
- 优先用日志文件名中的时间戳（如
app-20240520.log）做判断，比依赖st_mtime更可靠 - 删除前加
try/except OSError捕获，并记录失败原因，避免单个文件失败中断整个清理流程 - 对匹配到的日志文件，用
os.path.getsize(path) == 0快速跳过空文件（常见于轮转后残留的占位符）
用 glob + datetime 精确匹配带日期的日志文件
当你的日志按天生成（如 service-2024-05-20.log），硬编码字符串切片或正则容易漏匹配。用 glob 配合 datetime.strptime() 是最稳的组合。
示例逻辑：
立即学习“Python免费学习笔记（深入）”；
import glob
import os
from datetime import datetime, timedelta
<p>log_pattern = "logs/service-*.log"
cutoff_date = datetime.now() - timedelta(days=7)
for path in glob.glob(log_pattern):
basename = os.path.basename(path)</p><h1>提取日期部分：service-2024-05-20.log → 2024-05-20</h1><pre class="brush:php;toolbar:false;"><pre class="brush:php;toolbar:false;">date_str = basename.split("-", 2)[1].split(".", 1)[0]
try:
log_date = datetime.strptime(date_str, "%Y-%m-%d")
if log_date < cutoff_date:
os.remove(path)
except (ValueError, IndexError):
continue # 跳过命名不规范的文件，不报错中断</code></pre>注意：glob 不支持递归匹配子目录，如需处理 <code>logs/2024/05/ 这类结构，改用 pathlib.Path("logs").rglob("*.log") 更安全。
避免清理时干扰正在运行的服务
直接删日志文件，某些服务（如 supervisord 管理的进程）可能仍在往已删除的 inode 写数据，造成磁盘空间不释放；另一些服务（如用 logging.FileHandler 且未设 delay=True）会在下次写入时报 FileNotFoundError。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
安全做法：
- 确认服务是否支持日志 reopen（如 Nginx 的
nginx -s reopen、Supervisor 的supervisorctl restart），并在清理后触发一次 - 若无法重启服务，改用
os.truncate(path, 0)清空内容而非删除文件，保留文件句柄有效 - 对关键服务，清理前检查进程是否正在使用该文件：
lsof +D logs/（Linux/macOS）或handle.exe logs\（Windows）
用 shutil.disk_usage() 做空间阈值触发式清理
固定周期清理（比如每天删 7 天前）有时不够灵活：突发流量导致单日日志暴涨，7 天规则来不及响应；而长期低流量又可能让磁盘缓慢填满。更实用的是“空间不足时才清理”。
核心判断逻辑：
usage = shutil.disk_usage("/var/log")
if usage.free / usage.total < 0.1: # 剩余空间低于 10%
# 执行上面任一清理逻辑，但把保留天数从 7 改为 3
pass注意：shutil.disk_usage() 在 Windows 上返回的是所在驱动器根路径的用量，不是某个子目录；在 Linux/macOS 上也只反映挂载点整体情况。不要传入 "./logs" 期望获取该目录独占空间——它永远返回父挂载点的值。
真正需要目录级空间估算？只能靠 du -sh logs/ | awk '{print $1}'（Linux/macOS）或 PowerShell 的 Get-ChildItem logs -Recurse | Measure-Object -Property Length -Sum（Windows），再用 subprocess 调用，但跨平台维护成本陡增。多数场景，挂载点剩余空间已足够预警。
最后提醒一句：所有清理脚本必须加日志记录本身——哪怕只是写一行到 /tmp/cleaner.log，否则某天磁盘爆了却找不到是谁干的，就只能翻 crontab 和文件修改时间硬猜了。
