最近我在 Mac 上发现，刚开机没多久活动监视器里的 kernel_task 已经写入了五百多 MB。过了一会儿，这个数字涨到七百多 MB。更早之前，我有几周没有关机，累计写入还曾经达到 1.4 TB。
难道我的电脑硬盘即将英年早逝了？
于是开始借助 AI 工具开始判断问题，供大家参考。
活动监视器里的“写入字节”，表示进程从启动以来参与了多少磁盘写入 I/O。它不是文件大小，也不是磁盘空间的减少量。
比如，覆盖一个旧文件、写入日志后删除、更新数据库，都会增加写入统计，但不一定让可用空间减少同样多。文件系统的日志、元数据和缓存，也会被计入 I/O。
kernel_task 是 macOS 的内核进程。很多程序的文件操作最终都要经过内核，所以它更像一个 I/O 汇聚点，而不是“有一个程序叫 kernel_task，自己创建了 500 MB 文件”。
刚开机时，系统还会集中做一些事情：恢复应用状态、更新缓存、建立 Spotlight 索引，以及处理常驻应用的日志和数据库。这解释了为什么数字在开机后涨得比较快。
为了知道罪魁祸首是谁，还得继续往下查。
macOS 自带的 fs_usage 可以观察文件系统活动。我先采集 60 秒内的写入：
sudo fs_usage -w -f filesys -t 60 | grep "WrData" > ~/Desktop/fs_wrdata_60s.txt
这几份日志里，写入来源比我预想的复杂，首先是飞书。日志路径中多次出现：
com.bytedance.macos.feishu
LarkShell/sdk_storage/log
退出飞书后，Feishu 和 Lark Helper 的写入就消失了。至少可以确认，飞书的 SDK 日志是其中一个来源。
关闭这些应用后，系统服务的写入就比较明显了：
/System/Volumes/Data/.Spotlight-V100/
~/Library/Metadata/CoreSpotlight/
/private/var/db/biome/
这些路径分别与 Spotlight、CoreSpotlight 和 macOS 的系统数据服务有关。刚开机、系统升级，或者最近增加了很多文件时，索引服务写一阵子并不奇怪。
Chrome 和微信也会写缓存、会话数据、IndexedDB 和 GPU 缓存。它们单独看都不算异常，但飞书、浏览器和系统服务同时运行，累计起来就很容易让 kernel_task 的数字持续增加。
网络上另一种说法是因为内存不足，系统会频繁使用 swap，也会产生大量磁盘写入。
执行：
看这几项：
当时没有发生明显的 swap 进出。也就是说，这次的写入主要不是内存不够，把内存页面不断换到 SSD 上造成的。这个问题也可以排除掉。
最后我又检查了 Mac 的内置 SSD：
sudo smartctl -a /dev/disk0
结果如下：
Model Number: APPLE
SMART overall-health: PASSED
Available Spare: 100%
Percentage Used: 0%
Data Units Written: 4,705,286 [2.40 TB]
Media and Data Integrity Errors: 0
这块 256 GB SSD 的健康检查通过，备用空间为 100%，磨损百分比为 0%，也没有介质和数据完整性错误。至少从这次检查来看，SSD 没有表现出故障迹象。
我理解这次写入的过程大概是这样：
飞书日志、浏览器缓存、Spotlight 索引
↓
macOS 文件系统
↓
kernel_task
↓
活动监视器的累计写入统计
所以，刚开机后 kernel_task 增加几百 MB，不足以说明系统或 SSD 有问题。即使几周不关机，多个常驻应用和系统服务累计写入 TB 级，也不能只凭这个数字判断 SSD 快要坏了。
现在我会先看“单位时间写了多少”，不再盯着累计数字发愁。如果电脑空闲半小时后还在高速写入，同时可用空间快速减少，或者出现持续卡顿、异常发热，再用 fs_usage 去找具体文件和进程。没有这些现象的话，先观察一段时间就够了。
参考资料：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。