前阵子聊过 ToDesk 往 dumps 里不停写崩溃转储的事，那回占空间的是第三方软件自己的文件夹，找到它处理掉就完了。/private/var/db/diagnostics 不一样，它归 macOS 自己管，放的是统一日志系统（unified logging）的数据。它涨上去以后，该找的是谁在往系统日志里写这么多，而不是去删这个目录。
这个目录里是什么
Apple 在 WWDC 2016 的 Session 721（Unified Logging and Activity Tracing）幻灯片里讲过：日志以压缩的二进制格式存成 .tracev3 文件，放在 /var/db/diagnostics/ 下，配套数据在 /var/db/uuidtext。因为格式不是文本，必须用专门的工具读。Apple 资料里写的是 /var 开头的路径，一般就是你在 /private/var 下看到的这个目录。开发者文档 Viewing Log Messages 也是一个意思：读日志要用“控制台”App 或 log 命令行工具，文件本身没法直接解析。
空间怎么回收，开发者文档 Generating Log Messages from Your Code 有一段说明：debug 和 info 级别默认只放在内存里；notice（也就是 default）、error、fault 会压缩后写进磁盘，表里写的是 “Yes, up to a storage limit”。数据存储超过预设大小时，系统会清掉旧条目给新消息腾地方。这个上限具体是多少，文档没写。所以目录一直明显在涨的话，比较可疑的是有进程在高频写 default 及以上的日志，或者某个子系统的级别被人调高了。
看实时是谁在刷
最直接的是 log stream，它把实时日志打到终端。刷屏的通常很好认，同一个进程名会接连占满好几屏。想盯某段文字，可以用 WWDC 幻灯片里的写法加过滤：
log stream
log stream --predicate 'eventMessage contains "my message"'
把 my message 换成你在刷屏内容里看到的关键字。知道是哪个组件的话，它的记录一般带 subsystem，可以照 Apple 支持文档 View content caching logs 里的示例，按子系统去查已存下的日志：
log show --predicate 'subsystem == "com.apple.AssetCache"'
这是 Apple 讲内容缓存日志时给的例子，把子系统名换成你要查的就行。时间范围之类的参数，那页也是让大家去看 log(1) man page，在终端里 man log 就能看到本机版本对应的说明。
不想敲命令，控制台 App 也能做到：左边选这台 Mac，点工具栏的 Start（中文界面的按钮名以系统为准），日志就开始滚动。Type 一栏红点是 fault，黄点表示 error，不带圆点的属于 default。用普通账户登录的话，要输入管理员名称和密码才能看。
有没有谁把日志级别调高了
调试时可能有人，或者装过的哪款软件，给某个子系统开了 debug 级别。Apple 文档 Customizing Logging Behavior While Debugging 给的查看方式是：
sudo log config --status --subsystem com.your_company.your_subsystem_name
同一页还写了，日志配置描述文件可以放在 /Library/Preferences/Logging/Subsystems/ 下，用反向域名命名的 .plist，里面的 Persist 键决定消息是只留在内存，还是存进数据存储。去这个目录看一眼有没有陌生的文件：调试时自己放的，用完移走；来路不明的，先弄清是哪个软件装进来的，再去它的设置或卸载流程里处理。
找到以后
找到刷日志的进程，退出它，或者更新、卸载，然后观察一两天，看目录还涨不涨。有用户怀疑过某款清理工具被系统沙盒反复拒绝、不停记日志，可也有没装它的人目录照样不小，所以别急着给哪个软件定罪，以 log stream 里实际看到的为准。
至于手动删：Apple 现有资料只说了系统会在超出预设大小时清理旧消息，没看到哪份文档建议用户自己删这个目录，删了以后对诊断有什么影响也没有官方说明。空间真的紧张，更稳的是把源头停掉，让系统自己回收。
你们机器上这个目录一般多大？有没有抓到过哪个进程在疯狂写日志？