macos日志可能膨胀至几十gb，需用du命令定位：先查/var/log和~/library/logs，重点关注asl/、install.log等；清理asl可删*.asl，用户级日志注意docker、vs code等；归档日志用find扫描，统一日志用log命令管理并sudo log erase --all清空。
在 macOS 上，日志文件可能悄无声息地膨胀到几十 GB，占满磁盘空间却难以察觉。用 du（disk usage）配合合理路径筛选和排序，能快速定位这些“隐形大户”。
从系统日志目录开始排查
macOS 的日志主要集中在 /var/log 和用户级的 ~/Library/Logs。系统日志受 SIP 保护，普通用户无法直接读取全部内容，但可先检查可访问部分：
- 运行
sudo du -sh /var/log/* 2>/dev/null | sort -hr | head -10，查看顶层日志子目录大小（需密码） - 重点关注
asl/（旧式 Apple System Log）、install.log、system.log、netboot/等目录，它们容易因错误循环或调试开启而暴增 - 若发现
/var/log/asl异常大（如 >5GB），大概率是 ASL 数据库未被轮转，可用sudo rm -rf /var/log/asl/*.asl清理（macOS 10.12+ 已逐步弃用 ASL，但残留仍常见）
扫描用户级日志与应用缓存
第三方应用（尤其开发工具、IDE、容器平台）常在用户目录下写大量调试日志，且不自动清理：
- 执行
du -sh ~/Library/Logs/**/* 2>/dev/null | sort -hr | head -15（需启用 globstar：shopt -s globstar，或改用find ~/Library/Logs -type f -size +50M -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr | head -10） - 常见“重灾区”：Docker（
~/Library/Containers/com.docker.docker/Data/logs/）、VS Code（~/Library/Application Support/Code/Logs/）、Unity、Xcode 的DerivedData日志子目录 - 注意
~/Library/Logs/DiagnosticReports/—— 崩溃报告本身不大，但数量极多时也会累积数 GB，可安全删除（系统会重建）
识别并过滤压缩/临时日志文件
有些日志以 .gz、.bz2 或 .old 形式存在，du 默认统计其压缩后大小，但解压后可能远超预期：
- 用
find /var/log -name "*.gz" -o -name "*.bz2" -o -name "*.old" -exec du -sh {} \; 2>/dev/null | sort -hr | head -5单独扫描归档日志 - 对可疑文件，用
gunzip -l filename.gz查看解压后预估大小（无需解压） - 警惕
system.log.0.bz2类滚动日志 —— 若保留了 10 个以上，建议调整/etc/asl.conf或使用log config控制保留策略（较新系统用 Unified Logging）
结合 unified logging 查看活跃日志源
macOS 10.12+ 默认使用 log 命令管理统一日志系统，du 看不到其底层数据库文件（/var/db/diagnostics/ 和 /var/db/uuidtext/），但可辅助判断：
- 运行
log show --last 24h --info --debug --predicate 'eventMessage contains "error"' | wc -l粗略评估错误频率 - 若返回数万行，说明某进程持续报错写日志，再用
log stats查看各子系统日志量分布 - 真正占用空间的大户可能是
/var/db/diagnostics，用sudo du -sh /var/db/diagnostics/* | sort -hr | head -5直接检查（需管理员权限）
清理前建议备份重要日志，删除后多数服务会在下次启动或轮转时自动生成新文件。统一日志可通过 sudo log erase --all 安全清空（会释放磁盘空间）。
